Clean Up Your Bug Tracker and Keep Numbers Manageable
By: Timothy Western
A good team likely is trained to consistently report defects as accurately and promptly as possible. This means that over time the bug backlog builds up, and looking for what bugs to fix starts to seem like searching for a needle in a haystack. The best way to keep your tracker under control is to improve the quality curve earlier.
The United States Postal Service has long been the carrier for the majority of US mail. Last year it handled more than 155 billion pieces of mail. A staggering number of valuable papers and packages fail to reach their intended recipients due to improper addressing, violation of postal shipping regulations, or some other reason. In 2011, the most recent year for which figures were available, 53.4 million articles were sent to the Mail Recovery Center in Atlanta, Georgia. The facility eventually was able to deliver 43 percent of that mail, but the rest had to be recycled or auctioned off.
To put it simply: The USPS feels an obligation to its customers to spend a lot of time and energy looking through undeliverable mail, and that time is often invested without return.
For some, this sounds an awful lot like a defect tracking system on a large, mature product. After all, what is a defect tracker but a storehouse of defect or enhancement information that can’t be used at this moment so is archived for future value that we hope will come later? (Notice the word hope.)
What’s Logged in a Defect Item?
A documented defect—what I’ll called a “defect item”—usually contains several pieces of information about the failure. That can include steps to reproduce the defect, screen captures, and recordings. It may include debugging information; some testers track the problem down using the source code library or even lines of code. Severity, which is a human’s appraisal of the bug’s seriousness, and priority—the best-guess appraisal of the relative importance of the defect compared to other bugs—are common things to add. Most bug trackers include a unique identifier and a summary, description, or title that gives a brief synopsis of the issue. (I am using the terms bug and defect interchangeably here.)
Let’s spend a moment talking about what happens to these reports.
A Common Pattern
A good team likely will be trained to consistently report defects as accurately and promptly as possible. This means the list of bugs begins to increase as the project grows under the heat of change. In fact, it is possible that hundreds, perhaps thousands of bugs could be reported in a short amount of time.
On more agile teams, some bugs may be fixed in a matter of minutes, whereas on a more traditional, “structured” team, the testing that leads to the bug reports may lag weeks or even months behind when the defects were introduced—and that’s not counting the time a developer has to wait to begin an investigation. This understandably has an impact on the speed at which teams can deliver, and it increases the amount of time between a defect being created and introduced into a branch of code, its eventual discovery and reporting by a stakeholder, and the duration of time needed to implement a fix and then verify it each time a bug is introduced and discovered. Thus, this process has a compounding effect on the timeline of fixing a product, and for many teams, time is of the essence.
Over time the bug backlog builds up; looking for what bugs to fix starts to seem like searching for a needle in a haystack. The team stops caring about new bugs, because what is five more added to a pile of five thousand?
Then, one day, you realize: Unresolved bugs are like the undeliverable mail of our day—a one-way communication without a recipient.
... to read more articles, visit http://sqa.fyicenter.com/art/