Summary: Defect tracking procedures help to create a better end product. What goes into the bug report will have a big impact on the end result.

What Makes a Good Bug Report

Making a bug report is not as straightforward as it seems. To simply issue a report that says, "This feature doesn't work," does not provide much to the developer in the way of useful information. The report should be as specific as possible, and should include the specific steps that can be taken to reproduce the occurrence of the defect. In other words, a more useful report would say, "when I do X, Y, and then Z, then this happens." To be even more useful, the report should include details about what the expected result would have been had the flaw not occurred.

It is especially important to stress to testers, beta users, end users anybody else that may be issuing a defect report that it is absolutely essential to include details on how to make the defect occur again. Without specific details, it may be difficult or impossible to replicate the incidence of the defect in the lab. And if the defect cannot be reproduced, then it cannot be fixed. This is why the software testers on the other side of the lab keep very careful and precise logs of every single action they take.

When configuring your reporting interface, it would be useful to provide users with multiple fields to allow input of all these factors. In the first field, ask the user to describe the defect. Then, add another field to allow the user to state specifically what they did to cause the defect to appear. Still another field could allow the user to state what they expected to happen—in other words, what was the user trying to do when the defect occurred? And lastly, the user should have a space to enter what happened instead.

Getting good feedback from users and obtaining accurate and precise defect reports is one of the most important aspects of good defect tracking. Also, it is vitally important to maintain a formalized system for defect tracking. Some programmers may attempt to keep track of defects informally, through handwritten notes, spreadsheets, or just by assuming they will remember everything—but none of these will work very well. A formal defect tracking tool, with a searchable database, reporting function, and an interface for reporting, is the only way to provide the consistency that the development team needs.

Once the bugs are reported, then they must be managed. A project manager must have stated authority over the bug tracking function, and authority to delegate work. Each bug can therefore be assigned to a specific individual, who will take ownership of it until it is fixed. The management of defects also involves avoiding duplicated efforts by searching a new bug report against the existing database, to make sure it is not a bug that has already been reported. Lastly, follow-through is essential as a tool of good reporting. When a bug report is issued, is must also be closed when the problem has been resolved.