Section 2.5. Tracking Bugs

2.5. Tracking Bugs

Testing a product provides information about which parts of it are working and which are not. This information needs to be made available to developers, other testers, managers, the people that decide when a product is ready for release, and also to those who support a product. Bug tracking tools are commonly used to do this. Bugs are sometimes referred to as issues, because they are often requests for changes or some other category; some other terms, particularly defect and incident, can have legal implications and are best avoided if possible. The term bug is used colloquially throughout this book to refer to all these categories.

Bug tracking tools often store information about bugs in a database and then provide convenient GUIs and command-line interfaces (CLIs) for adding information about bugs to the database, changing the information recorded about bugs, and creating reports about different kinds of bugs. At a minimum, a recorded bug has a description of the bug (what happened, what should have happened) and an identifier that is unique for each different bug. Other information that is frequently recorded with each bug includes who found it, the steps to reproduce it, who is working on it now, which releases the bug exists in, and which releases it has been fixed in.

Many bug tracking systems define a number of states and allow each bug to be in just one state at a time. This is intended to help guide the workflow of the team when they are working on different bugs. For instance, a new bug may be in the Open state, then move to an Accepted state, then to a Fixed state, and then to a Closed state. This is part of applying a change management process (see Section 4.2) to how you want bugs to be fixed.

Tracking bugs is a lot more than just not forgetting what still needs fixing in a product. For good and bad, it becomes a way to measure development and testing progress toward the next version. Observing the numbers of bugs in different states over time can play a part in deciding when a product is stable enough to ship. It is also a rather simplistic way to measure how busy individuals arefor instance, by the number of bugs they have assigned to them. As such, bug totals often take on a meaning far beyond a simple record of the problems in a project. Bug tracking tools can even become a way to avoid communicating directly with other project members, as described in Section 12.4.

Chapter 7 discusses many more aspects of bug tracking and examines some of the more commonly used bug tracking systems: spreadsheets, Bugzilla, GNATS, FogBugz, JIRA, and TestTrack.