by Damon Poole
There are some who recommend against using a defect tracking system. Instead, it is recommended that when a bug is found, it is fixed immediately. While that is certainly one way of preventing an ever growing inventory of defects, the tracking of an inventory of defects is one of the smallest benefits of a defect tracking system. Overall, a defect tracking system serves as a facilitator. It simplifies the collection of defect reports from all sources. It isn’t just the developers responsible for fixing the defects that find problems. Customers, developers working on dependent systems, and testers also find defects. Even if you have a policy of fixing defects as soon as they are found, it isn’t always logistically possible to do so. For instance, if you are currently working on fixing a defect and in the process of doing so you find another one, you don’t want to lose track of it. Thus, a defect tracking system coordinates the collection of defect reports in a standard way and collects them in a well known location, insuring that important information about the functioning of your system is not lost. The problem of creating a defect inventory is completely orthogonal to the user of a defect tracking system.
A defect tracking system also manages the progress of work through the development life cycle from reporting, to triaging, to assignment, to test development, to completion, to test, to integration, to delivery. It simplifies the answering of customer questions such as “what is fixed in this release” and “what release will the fix appear in.” A defect tracking system also allows for the collection of metrics which aids in the spotting of trends. I have heard from multiple sources that metrics collected from an issue tracking system are worthless because developers will just game the system. That may be true in an unhealthy environment. However, in an environment where developers are actively participating in the improvement of the process, they will want this information in order to help to find and fix problems, including the root cause of individual problems.
I’ve heard of folks say the same… from my experience, it’s often only when multiple reports in the issue tracking system come in that we have enough information to actually reproduce the problem and fix it. If we were to just dive right into the code on the first report of a problem, it would take multiple times the effort to fix the problem than if we were armed with a handful of scenarios that can be used to reproduce and isolate the problem.
So, lets see… A bug gets reported, a programmer starts working on it. Then another bug is reported. The programmer writes it down on a piece of paper so he won’t forget it. Then another one is reported. The programmer, says to himself “Ya know, instead of writing all these bugs down on a piece of paper, I’ll put them in a database somewhere. And I’ll write a web interface to it so I can get the bugs at home too.” Thus a Defect Tracking System is born into an Agile World.