A lot of people treat bug tracking systems like that one junk closet in their house. New stuff is continuously jammed in till the pile reaches the ceiling. Eventually, the stuff in the back and the corners is completely hidden and forgotten. That closet could be cleaned out of course, but what if something gets thrown away and no one realizes it was needed till it’s gone?
Being a bug hoarder with a closet of smelly old, useless software bugs is a time consuming hobby. Which is why we put together a few strategies to figure out whether bugs stored in a test case management tracking system, like JIRA, are useful, and ideas on keeping your bug closet clean and neat.
Understanding Bug Reports
When a new tester looks around on Google for advice on bug reports, they find bland templates with instructions on exactly what information they need — titles, expected results, severity, priority, release version. Unfortunately, half of the time, people don’t agree on what those things mean, who should be filling them out, or if they are even useful. Priority and severity are two common offenders here.
If a browser crashes when a customer updates the number items they want in the shopping cart, that is a severe failure. If that happens to every single person that tries to update their shopping cart, the problem is even more severe. Severity is how bad the failure is, often related to how much money the company is loosing. This is where it gets weird. A bug can be low in severity, like a misspelling, but at the same time be high in priority. If the CEO finds a small problem during a demo, she is going to want it fixed right away.
The easiest way to manage test case priority and severity is to keep things simple in JIRA. A high, medium, low rating for both of these will do the trick. A low severity bug is annoying but doesn’t slow anyone down, medium slows people down but there are workarounds, and a high severity bug means people can’t get work done. Similarly for severity, low means “fix eventually” and high means “fix today”.
Demonstration of Bug Reports
The second part of better bug reports, after making the the bugs you identify more useful, is getting fewer bugs in JIRA test case management.
Method 1: Monthly Pruning
One way to approach this is to have a monthly pruning session. When these happen, the team builds a query to find all of the bugs entered in JIRA in the last month or so. Every bug is reviewed, one at a time, and the ones that people either can’t reproduce or don’t care about anymore are closed. Think of this as a junk closet cleaning. This works, at the end of each session the bug tracker is a little bit cleaner. But, it is a drain on people’s time.
Method 2: Developer + Tester Collaboration
The faster option, is to avoid the bug tracking system all together. Imagine a tester finds a bug that is difficult to describe. The tester has to spend time researching and digging through log files, gathering screenshots and videos so nothing is missed, and then getting all of that in the tracking system. All of that takes time, and before they know it an hour is gone and there are still other bugs waiting to be found.
Consider this alternative. Instead of the tester and developer working separately, when the tester finds a bug, they go over to the developer and demonstrate the problem. That tester can walk through what they found, step by step, while the developer observes. Seeing how the software was used will sometimes remind the developer of something important. “Ah! I forgot to prevent the user from submitting numbers in that field”. Instead of spending an hour documenting, the programmer will have a good idea of what went wrong and be able to fix it right away. One popular objection to this tactic is that it takes up the programmer’s time, and interrupts their train of thought. But, if having bugs fixed is part of what it means to have a feature done, and done well, what else should they be doing?
When the team uses demonstration, most bugs get fixed before the bug tracker enters the equation. Documenting problems are then reserved for the important bugs — that are complicated and need a lot of information gathered in one place, that can’t be fixed right away, or that need input from other people.
There are a few ways to get better bug reports. One part of this approach is to get the right information in the bug tracker to begin with. Simplify the options that are available, and get rid of everything in the template that isn’t useful. The other part is keeping the junk out in the first place. Start by demonstrating bugs to a programmer when they are found, and then move to the bug tracker as a last resort. Happy reporting!