A 7 point checklist to improve your bug tracking process

Let’s clear up the jargon first. A ‘bug’ in software engineering is an unexpected behavior from software. Fixing a bug involves locating the source of the misfire, rectifying it, and updating the software to reflect the changes. However, the seeming duck soup of a task gets overwhelmingly tricky with the size of the product and the team involved. Firstly, a lot of decision-making is involved in the process, and often the authority to make those decisions doesn’t lie with a single person. This requires every stakeholder to be informed at each step of the process, which calls for a lot of communication in a large team.

Secondly, with more than one developer/designer/tester working on a product, there is a possibility of redundant overlap of work that needs to be checked. Two developers working on the same aspect of a bug, unaware of each other, leads to waste of resources and impedes productivity.

Thirdly, the number of bugs reported in a large organization is huge and often crushingly disproportionate to the number of resources available. So, dealing with the bugs in the same sequence as they are reported is not always a great idea.

As Joel Spolsky points out — One of the biggest incorrect facts that programmers consistently seem to believe is that they can remember all their bugs or keep them on post-it notes, it is still very valid. Overall, fixing a bug in a sizeable piece of software needs a well-coordinated team of developers, designers, testers, and product managers synced into a strategic debugging drill. This article touches on the underlying heuristics of effective bug tracking.

Let us quickly review how the whole process of defect management works. Right from when a bug is discovered to when it is finally closed, it changes several states and hands. A typical bug goes through these steps:

1. Bug discovered and filed by user or tester
2. The bug is assigned to the appropriate developer by the project manager with applicable priority
3. Once the developer fixes it or gives a workaround for it, it is re-assigned to a tester for verification
4. The tester verifies, if it is the bug and closes it, or can re-open it if it still exists. If reopened, it goes the entire cycle again.

If the entire development process is eating a Twix bar, debugging is disposing of the wrapper in the litter bin part of it. Essential, but not much fun. Going by the adage of ripping the Band-Aid off in one go, it is best done fast and smooth. Following are a few pointers, compiled from various sources, to keep it simple and seamless.

Provide sufficient information in minimum possible words when reporting the bug — Start by justifying the label ‘bug’ by specifying two aspects — the expected behavior and the observed behavior. The observed output can be described in terms of error messages, screenshots in case of graphics and design-related problems, URLs in case of web-based applications, etc. As a next step, provide details of the setup and environment in which the bug was encountered, with the aim of making it reproducible. List down the simplest sequence of steps to reproduce the bug. Meticulously include the version of the software you are using and any other context-specific parameter that may vary upon testing, like browsers. Lastly, make an effort to check if the bug has been reported before.

Assign a priority to the bug — This step is especially important when handling a large-sized software with a busy bug log — it makes a quick decision for the problem solver, one step safer from decision paralysis. To state the obvious, a cosmetic flutter in the software is far more tolerable than one that causes a system crash. Assigning a priority ensures that the bulk of resources go into mending the most critical flaws. Again, other aspects like profitability and long term necessity can play into the decision

Keep feature requests separate from bug — A feature request is a relatively more engaging and desirable task for the programmer. So, keeping it away from bug reports will in general yield more productive results. Further, bug reports form part of the statistics that determine the quality of software. Counting feature requests along with bugs dilute the metrics. Here is an interesting paper on how misclassification of a feature request as a bug impacts bug prediction too. One of the frequent dilemmas that the team would face would be while classifying a report as a bug or a feature request. Like Jeff Atwood says, “ There’s no difference between a bug and a feature request from the user’s perspective. “ That is where the product manager plays an important role of balancing resources vs priorities and makes decisions accordingly.

Decide on the collaborators — Bug reports come in through either the Quality Assurance team or are directly reported by the end-users. The product manager attributes a priority to it and assigns it to developers and designers. It can take quite a few hits and misses, as you scan through various parts of the code in search of the source of the bug before you are able to determine the complete collaborating team. The crucial thing is to not skip a step though. Always maintain the communication on a one-to-one level and sequentially go about ruling out the suspected sources of error.

Communicate — Higher-level decisions like priority of a bug, based on various parameters like business aspects and available resources, and classification into bug or feature request needs discussions between managers and owners. At a lower level, practical issues like reproducibility and solvability of the bug calls for discussions between developers/designers and managers. At the most basic level, with multiple programmers and designers on the team, it is necessary to communicate enough to clarify the sub-areas each member would be working on and the expected results from individual members. As a rule of thumb, be specific with your comments & directives and avoid generic chatter. The bug reporting and assigning can call for some serious discipline!

Resolve — It is just as critical to resolving a bug that has been dealt with to declutter the log and make progress. At the very least, it indicates that the required action has been taken regarding the bug. The QA team should test for the bug in different environments and platforms before marking it as resolved. Ideally, the bug report should be closed by the one who initiated it.

Choosing the right bug tracking tool –The right bug tracking tool depends on factors like technology, the composition of the team, desired accuracy, etc. Going by the number of features available, the more the better, is not always a great idea. Like this blog on agile development reads, “Software project management tools sound great in theory, but in practice are too complicated to use with non-tech savvy clients. With these tools, time and money are wasted on training and the bugs are lost or forgotten.” Choosing the right bug tracker can go a long way in easing up the otherwise demanding process.

As Alessandro points out, better-designed issue trackers can go a long way in reducing the possibilities for misuse. We have developed zipBoard trying to keep things as simple as possible and only focus on details that would make the collaboration process easier.

What are the things that make your bug tracking process easier, do share your thoughts.