Bug Trackers: Do They Really All Suck?by Matt Doar, author of Practical Development Environments
The most complained-about development tool is often the bug tracking system. This fact prompted a friend to suggest the title for this article. To be fair, while they don't all suck, they are annoying. I've listed some of the most common frustrations with tracking bugs; you may have others to share, or even suggestions for fixing some of these annoyances.
More than most tools, bug trackers serve lots of different groups of people. Developers want to know which bugs need to be fixed. Testers want to know which bugs have been fixed in each build. Managers want answers to very different questions: "What kinds of bugs are there?" "Who should work on this bug?" and, "Is the number of critical bugs increasing or decreasing?"
There is some overlap between these different groups, but not that much. So one tool tries to please everyone and ends up never quite making anyone happy. Even so, some specific frustrations with most bug trackers pop up frequently enough to be worth describing:
Different releases of a product typically use branches in the source control system. Often, there's a branch for each released version of a product (and its associated patch releases), and a mainline for developing the next release. This is shown in the figure below. Other kinds of graphs exist, but this seems to be the most common one.
When a bug is found in one version of the product, it may well exist both in earlier and later versions of the product. Code inspection and testing can confirm when the bug was introduced and whether it has been unintentionally fixed later on. The figure also shows a bug that exists only in some parts of the tree of releases.
Names for Bugs
It's hard work to sell products that have known bugs, faults, or failures, but products with "unresolved issues," "anomalies," "artifacts," or even "potential defects" somehow sound better. You may even come across products that contain "design side effects." Be careful what you term you use, because the terms "defect" and "incident" can have unforeseen legal consequences.
Many bug tracking systems use the word "issue" because it can refer to feature requests or support tickets as well as bugs. Colloquially, "bug" still seems to be the most common way to refer to all of these things, so that's what this article uses.
The problem is how to keep track of all of the releases that a bug exists in. Bugs often have a field named something like
Found In, to record which release the bug was originally found in. The three most common approaches to tracking multiple releases are:
Multiple values: The
Found Infield can contain multiple releases, whether it's a drop-down list or just a plain text field.
Multiple bugs: Create a clone of the original bug and change the cloned
Found Infield to record a different release. This leads to lots more bugs, and some uncertainty about which bug to record new information in. Customers may also be confused by bugs having different numbers in different releases.
Multiple fields: Create three different
Found Infields in each bug. Then record a different release in each one of the fields. For instance,
Found In #1could contain
Release 2.0, while
Found In #2could contain
Release 2.1. This makes generating reports much more complicated, and if you want to record more than three releases, you have to add more fields. Tracking which release the bug is fixed in, or the state of the bug in each release, leads to yet more fields.
It seems to me that some tool, maybe the bug tracker, needs to keep track of releases and how the source file that were used build them are related to each other. Then the information about exactly where the bug has been confirmed as existing, or confirmed as fixed, can be added. The key benefit of storing this information is that the answer to the question "Which bugs exist in release 2.0?" can include releases where the existence of the bug is only implied, not confirmed. The opposite question, "Which releases does this bug exist in?" can also be answered with greater confidence.
Pages: 1, 2