I'm a tester and I like finding bugs. I like finding things I can praise too, but there is still something almost magical in the power of touching a software, bringing all our illusions of how well it works crumbling down, only to raise again stronger having addressed the problems.
Early 2014, I was trying to figure out how I could find a job in San Diego and one of the activities I did was to update my CV. I completely changed it from a list of jobs I've had to emphasize my achievements, and one achievement in particular left me thinking:
I could also talk about the type of the problems, but let me emphasize: I calculated bugs that got fixed, not ones I found. I worked like crazy to find better ways of targeting the information I would deliver, just the right time so that it would get fixed and cause least amount of damage.
You could look at the numbers and say that our software must be buggy. It was when I joined. It has transformed since, and some of that transformation is already visible in the number being only 2,5 bugs per day.
When I looked at the number, I quickly did the math. 2261 issues written down. That is 47,10 of my full working days (with 10 minutes time to write a report) used into just writing one-time documentation. 10 minutes is little, I've probably used on bug report writing a lot more time.
You know, I was trained as a tester. There was an amazing theme from Cem Kaner (my big testing idol) starting from his book Testing Computer Software (still the best testing book out there, Elisabeth's Explore IT comes close) called bug advocacy. It emphasized good reporting. Reports are our signature. So I've learned to write some pretty good bug reports. And often thinking of a neutral wording, the most representative example of the problem and clear steps to reproduce easy and complicated problems just takes time. This is time I often spent alone. Shared time with developer started when the report was done.
I decided to try an experiment. I would give up on knowing how amazingly good a tester I am, through numbers. I would stop writing my bug reports in Jira. I would scribble on post-it notes. I would use the time I often use in isolation in collaboration, dragging a developer to look at the bug (and fix it under my eyes, but these bugs were already getting fixed before). I would, when working remotely, favor personal messages or screenshots on the team channel when I saw bugs over writing a task. I would do everything in my power to use the time on bug reporting as time with developers.
You probably guess what happened: I started having to find less bugs. The developers started to be more amazing. I started to feel less alone and different.
If there was a manager looking at how I'm doing, they'd say that she finds, logs and gets fixed less bugs now. But the true interpretation is that now I'm not creating bug reports, but the end result is better.
None of us misses the dead documentation that holds us down. That energy, into keeping Jira true to facts, can be used elsewhere. Another lesson from Cem Kaner: Opportunity cost. It's not just what the accounting cost is, but also, what you don't get to do with the time you used here. Let's try to make good choices.
Early 2014, I was trying to figure out how I could find a job in San Diego and one of the activities I did was to update my CV. I completely changed it from a list of jobs I've had to emphasize my achievements, and one achievement in particular left me thinking:
Personally reporting and getting fixed 2261 issues over a period of 2,5 years on Granlund projects.That's 2,5 bugs a day. Every day of the year. Even weekends. Even holidays. Even days when I'm out of office at conferences. Even days when I do other stuff than hunt for bugs.
I could also talk about the type of the problems, but let me emphasize: I calculated bugs that got fixed, not ones I found. I worked like crazy to find better ways of targeting the information I would deliver, just the right time so that it would get fixed and cause least amount of damage.
You could look at the numbers and say that our software must be buggy. It was when I joined. It has transformed since, and some of that transformation is already visible in the number being only 2,5 bugs per day.
When I looked at the number, I quickly did the math. 2261 issues written down. That is 47,10 of my full working days (with 10 minutes time to write a report) used into just writing one-time documentation. 10 minutes is little, I've probably used on bug report writing a lot more time.
You know, I was trained as a tester. There was an amazing theme from Cem Kaner (my big testing idol) starting from his book Testing Computer Software (still the best testing book out there, Elisabeth's Explore IT comes close) called bug advocacy. It emphasized good reporting. Reports are our signature. So I've learned to write some pretty good bug reports. And often thinking of a neutral wording, the most representative example of the problem and clear steps to reproduce easy and complicated problems just takes time. This is time I often spent alone. Shared time with developer started when the report was done.
I decided to try an experiment. I would give up on knowing how amazingly good a tester I am, through numbers. I would stop writing my bug reports in Jira. I would scribble on post-it notes. I would use the time I often use in isolation in collaboration, dragging a developer to look at the bug (and fix it under my eyes, but these bugs were already getting fixed before). I would, when working remotely, favor personal messages or screenshots on the team channel when I saw bugs over writing a task. I would do everything in my power to use the time on bug reporting as time with developers.
You probably guess what happened: I started having to find less bugs. The developers started to be more amazing. I started to feel less alone and different.
If there was a manager looking at how I'm doing, they'd say that she finds, logs and gets fixed less bugs now. But the true interpretation is that now I'm not creating bug reports, but the end result is better.
None of us misses the dead documentation that holds us down. That energy, into keeping Jira true to facts, can be used elsewhere. Another lesson from Cem Kaner: Opportunity cost. It's not just what the accounting cost is, but also, what you don't get to do with the time you used here. Let's try to make good choices.
