|
|
The most important reason to have a defect tracking system is to enforce a process workflow. Anyone who wants a bug fixed must enter a bug report (usually called a PR for Problem Report) into a central repository, and developers are held accountable for fixing only those bugs in the repository. One benefit of this is that all bugs are listed in a single place that is viewable by the entire team—bugs can no longer slip through the cracks. But an equally important benefit is that each PR can be tracked, can be assigned to exactly one person, can be prioritized with respect to other bugs, and can be included in project status reports. Each PR can serve as a historical record of when the bug was found, what the problem was, whether the bug has been fixed yet, and if so, how long the fix took.
A development workflow doesn't end with the developer writing code to fix a bug. Next, the tester needs to verify the fix works, the project manager needs to decide whether the fix will be immediately released as a hotfix or deferred until the next version, the tech support representative may need to notify a customer that the fix is now ready, and the documentation writer may need to post a knowledge base article about the bug on the company's web site. A defect tracking system can enforce a workflow so that each person is reminded of his or her role at the appropriate time.
Large development teams have too much going on at a time for any one person to keep track of it all. Let's look at some of the issues that may be brewing underneath the surface of your project.
Right now on your project, a developer is noticing somebody else's function returning a bad result. One of your testers is discovering a problem that occurs only with the latest Windows service pack installed. Your tech support representative is getting a call from a customer who says the program crashes when she inputs certain data. The program manager is trying out the new GUI and realizing some aspects aren't nearly as usable as they looked in the prototype mockup. One of your executives is playing with the program on his laptop during a 5-hour flight and will soon prepare a laundry list of things he wants changed.
That's just the beginning. Another of your testers is e-mailing a developer about an extremely important bug, but that developer is away on a 3-week vacation. By the time she returns, the e-mail will be buried under a pile of unread messages and no one will remember this bug. Last week, a different bug was traced to a piece of common code and the common code team promised to fix it soon—but your team is already forgetting about it and who knows if the common code team will deliver on their promise? One of your developers is swamped with work while another is free, so they agree to split the work evenly… but a miscommunication results in a particular issue falling through the cracks because both developers think the other will take care of it.
At the same time, both of those programmers think they are responsible for the other bug, so they're duplicating effort by debugging the same problem separately. Meanwhile, your tech support rep is telling an irate customer that a particular bug will be fixed in the next service pack, even though the project manager is unaware of the bug's importance and is now deferring that bug to a later version. Your documentation person is trying to put together a master list of all the bugs that will be fixed in the service pack—but the only way for him to do this is to pester all the developers. That not only takes away valuable coding time, but also results in flawed answers since the developers don't even remember all the bugs they've fixed over the past month.
Now factor in your team's efforts to release a new version of the product as well as hotfix the current bugs. Oops, now there are even more details to keep track of. And the number of interaction points grows exponentially with the size of your team, so multiply your expected headaches accordingly. Chances are, you're so swamped keeping track of it all that you don't even have time to ask the larger questions like "How fast is my team fixing the average customer bug?", "At our current rate of bug fixing, when will we be done?", or "What are the ten most important bugs we need to work on right now?"
No person can coordinate so many details at once. That's why you need defect tracking software to keep the process running smoothly.
A defect tracking program is just a database and a GUI on top. A description of each bug is entered in the database along with some additional information to help the developers track down the problem. There's nothing technically impressive about the tracking program itself. Dozens of pre-built tracking systems exist for sale on the market, or your company could easily build its own with only a few weeks of work. Instead, the system's value comes from the fact that all your bugs, and their associated meta-information, are stored in a single, centrally located, searchable place. You can see one typical tracking program in Figure 9-1.
Each PR stores more than just a description of a bug. It also stores meta-information about that bug, too. Who discovered the bug? When? Which developer was assigned responsibility for fixing it? Is this bug a high priority or a low priority? Is it targeted for an immediate hotfix, for the next service pack, or for a distant future version? Is the bug fixed yet? If so, has a tester confirmed the fix works yet? How did the developer fix the bug? What source files were affected? Most PR systems are configurable and allow you to choose what meta-information should be stored about each bug, so you can tailor the system to record everything you need. Each piece of meta-information is just another field in the database, and it's all in one place for easy reference.
|
|
