How to Use a Bug Tracker

Whether you call them bugs, defects, or even design side effects, there is no getting away from them. Knowing how to submit a good bug report and also what to look for in one are key skills for keeping a project moving along nicely.

A good bug report needs three things:

• How to reproduce the bug, as precisely as possible, and how often this will make the bug appear.

• What should have happened, at least in your opinion.

• What actually happened, or at least as much information as you have recorded.

The amount and quality of information reported in a bug says as muchabout the reporter as it does about the bug. Angry, terse bugs ("Thisfunction sucks!") tell the developers that you were having a bad time,but not much else. A bug with plenty of context to make it easier toreproduce earns the respect of everyone, even if it stops a release.

Bugs are like a conversation, with all the history right there infront of everyone. Don't blame others or deny the bug's veryexistence. Instead ask for more information or consider what you couldhave missed.

Changing the status of a bug, e.g., Open to Closed, is a publicstatement of what you think of the bug. Taking the time to explain whyyou think the bug should be closed will save tedious hours later onjustifying it to frustrated managers and customers. Changing thepriority of a bug is a similar public statement, and just because it'strivial to you doesn't mean it isn't stopping someone else from usingthe product.

Don't overload a bug's fields for your own purposes. Adding "VITAL:"to a bug's subject field may make it easier for you to sort theresults of some report, but it will eventually be copied by others andinevitably mistyped, or will need to be removed for use in some otherreport. Use a new value or a new field instead, and document how thefield is supposed to be used so other people don't have to repeatthemselves.

Make sure that everyone knows how to find the bugs that the team issupposed to be working on. This can usually be done using a public querywith an obvious name. Make sure everyone is using the same query, and don't update this query without first informing the team thatyou're changing what everyone is working on.

Finally, remember that a bug is not a standard unit of work any morethan a line of code is a precise measurement of effort.

By Matt Doar

This work is licensed under a Creative Commons Attribution 3