|
|
Every conceivable piece of meta-information about a bug is potentially useful. Someday, the project leader will want a graph of which components have the most bugs filed against them, so that's an argument in favor of adding a field called "component" to each PR. Bugs that occur only with a particular Windows service pack are rare, but they do happen, so now you ask for a field where users can input their OS information. When designing what meta-information should be listed on a PR, you'll think of dozens of other fields and you'll try to add them all. But here's an important point: For the person who files a bug, all fields except for the repro steps must be optional.
Requiring users to input fields that they don't know or care about will discourage them from entering PRs. You'll still get PRs for the complicated issues since the tester has to spend a long time on those, anyway. But few people will spend the effort to report smaller, nice-to-have issues such as "The back button is enabled on the first page of a wizard, even though there's nowhere for it to go back to." The "component" and "OS version" fields don't matter for that bug, and requiring users to enter those fields will just annoy them. Then they either won't report the bug at all, or else they'll bypass the PR system and e-mail the developer. Make sure it's easy for a user to file a quick bug report. Make sure no fields are required of the user except for the repro steps.
Now, it's fine to have required fields that normal users don't have to enter. The system can automatically fill in the creator of the PR, the date, and the status. And there may be fields that are required when the lead developer reviews the PR, such as who the PR is assigned to, what the priority is, and so on. That information is crucial and the lead developer can be expected to take care of it. But don't require everyone else to fill out every single field of your PR. You'll get much better results by letting them fill in just whatever they think is necessary.
I hope the benefits of storing all bugs and meta-information in one place rather than in the minds and Post-it Notes of a dozen different programmers are obvious. It eliminates the worry that someone might forget about a bug or that people might misunderstand when a bug was fixed—the tracking system becomes the authoritative source where all questions can be answered. If one engineer unexpectedly leaves the project, all the bugs he was working on can be easily discovered and reassigned to another engineer. Project leaders can get a feel for how buggy the product is without having to quiz every member of the team. And you can throw away all those Post-it Notes on the edges of your monitor.
That's the full extent to which many teams use defect tracking systems—to summarize all their bugs in a single place. Somewhat less obvious, though, are the other benefits of defect tracking. In the rest of this chapter, we'll look at ways to get more value out of your defect tracking system with techniques such as searching, reporting, status checking, and workflow enforcement.
| Note |
If you decide to build rather than buy a defect tracking system, consider basing it on a groupware program such as Lotus Notes or Microsoft Exchange's public folders. Back-end details like storage, searching, and workflow management are already implemented, freeing you to concentrate on creating an efficient GUI front end. |
|
|