Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing

4.5. Putting the Tracking in Bug Tracking: Adding Dynamic Information

So far, you have a database that is fine for reporting bugs but not for tracking them. It still lacks a way to include dynamic information, a mechanism to trace the steps through which a bug must move on its way to resolution. Having this information available would allow you to answer questions such as these: Who is currently responsible for pushing the bug toward closure? Is the resolution process "stuck" or moving forward smoothly? When will the bug be fixed?

4.5.1. Using States to Manage Bug Life Cycles

The aim of reporting problems is to bring them to the attention of the appropriate people, who will then cause the most important bugs to be fixed—or will at least attempt to have them fixed. The test organization then must either confirm or rebut the possible fixes. Other possible outcomes for a particular bug report include its cancellation as a nonproblem, its closure as redundant, or its indefinite dormancy because of a lack of interest. In other words, a bug report should go through an identifiable lifecycle, with clear ownership at each phase or state in its life cycle.

While the appropriate life cycle for your organization might vary, here's one life cycle I've used:

Review.

When a tester enters a new bug report in the bug tracking database, the bug tracking database holds it for review before it becomes visible outside the test team. (If nontesters can report bugs directly into the system, then ...