Friday, May 13, 2016

A No Jira Experiment

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:
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. 


  1. Wow, that's a lot of time.
    But this reminds me of a question I'm dealing with - when is it OK not to open a Jira?
    In more details - Jira is, for us, bot a task management utility and a place to look for information (since every commit is attached to a Jira, and most of the time, the Jira will have some information that will be useful 3 years later). Each time I decide not to open a jira but rather just ping someone to fix it I do save a lot of time on the actual fix, but I will have less information in the future. Also, not all of the bugs I find should be fixed right away - some of them are fine to wait 3 more months until the current pressing issues are done.
    Currently, I'm sort of winging it by feel - I will open a Jira if the developer asks me to, or if I think it has something that might be interesting in the future, or if we are closing the current release and need to better watch what we are doing, or, frankly, if it feels right to open a Jira. I wonder if you have some similar rule of thumb you use to decide what should be just fixed and forgotten (typos and stupid mistakes are good examples) and what should be documented?

    1. Reading through the ramblings in future is not more information for me, it is more waste for me. The bits that I find informational I take elsewhere (I have test documentation even if not test cases and a lot of stuff you can document in test automation).

      The bugs that don't need to be fixed now will come back again without Jira. Putting things on a long list just takes energy into list maintenance.

      A lot of my views on this are based on lean and ideas of waste such as inventory: long list reading is time away from something that could provide value.

    2. Remember however, that the context of my answers is living with daily releases. The stuff goes live that does not get fixed. It will come back if it is important. I can bring it back too.