Top Ten Tips for Bug Tracking

1. A good tester will always try to reduce the repro steps to theminimal steps to reproduce; this is extremely helpful for theprogrammer who has to find the bug.

2. Remember that the only person who can close a bug is theperson who opened it in the first place. Anyone can resolve it, butonly the person who saw the bug can really be sure that what they sawis fixed.

3. There are many ways to resolve a bug. FogBUGZ allows you toresolve a bug as fixed, won't fix, postponed, not repro, duplicate, orby design.

4. Not Repro means that nobody could ever reproduce the bug.Programmers often use this when the bug report is missing the reprosteps.

5. You'll want to keep careful track of versions. Every buildof the software that you give to testers should have a build ID numberso that the poor tester doesn't have to retest the bug on a version ofthe software where it wasn't even supposed to be fixed.

6. If you're a programmer, and you're having trouble gettingtesters to use the bug database, just don't accept bug reports by anyother method. If your testers are used to sending you email with bugreports, just bounce the emails back to them with a brief message:"please put this in the bug database. I can't keep track of emails."

7. If you're a tester, and you're having trouble gettingprogrammers to use the bug database, just don't tell them about bugs -put them in the database and let the database email them.

8. If you're a programmer, and only some of your colleaguesuse the bug database, just start assigning them bugs in the database.Eventually they'll get the hint.

9. If you're a manager, and nobody seems to be using the bugdatabase that you installed at great expense, start assigning newfeatures to people using bugs. A bug database is also a great"unimplemented feature" database, too.

10. Avoid the temptation to add new fields to the bugdatabase. Every month or so, somebody will come up with a great ideafor a new field to put in the database. You get all kinds of cleverideas, for example, keeping track of the file where the bug was found;keeping track of what % of the time the bug is reproducible; keepingtrack of how many times the bug occurred; keeping track of which exactversions of which DLLs were installed on the machine where the bughappened. It's very important not to give in to these ideas. If you do,your new bug entry screen will end up with a thousand fields that youneed to supply, and nobody will want to input bug reports any more. Forthe bug database to work, everybody needs to use it, and if enteringbugs "formally" is too much work, people will go around the bugdatabase.