Ten Tips for Bug Tracking

Note: This article describes the standard FogBugz bug tracking workflow. If you'd like to modify it, or create your own workflow, you can use the Workflow Plugin.

1. A good tester always tries to reduce the repro steps to the minimal steps to reproduce; this is extremely helpful for the programmer who has to find the bug.
2. Remember that the only person who should close a bug is the person who opened it in the first place. Anyone can resolve it, but only the person who saw the bug can really be sure that what they saw is fixed.
3. Not Reproducible means that the programmer couldn't reproduce the bug. Programmers often use this to send a bug back to the tester when the report is missing critical steps. Good testers see this is a challenge, not an excuse to close the case.
4. Keep careful track of versions. Every build of the software that you give to testers should have a build ID number somewhere which you can enter into the Version field in FogBugz. When a programmer fixes the bug, they should indicate what version the fix will appear in, so that the poor tester doesn't have to retest the bug on a version of the software where it wasn't even supposed to be fixed.
5. If you're a programmer, and you're having trouble getting testers to use FogBugz, just don't accept bug reports by any other method. If your testers are used to sending you email with bug reports, just bounce the emails back to them with a brief message: "Please put this in the bug database. I can't keep track of email."
6. If you're a tester, and you're having trouble getting programmers to use FogBugz, just don't tell them about bugs—put them into FogBugz and let FogBugz notify them.
7. If you're a programmer, and only some of your colleagues use FogBugz, just start assigning them bugs. Eventually they'll get the hint.
8. If you're a manager, assign new features to your team using FogBugz. Eventually they'll realize that instead of coming into your office every few days saying "what should I do next?" they can just see what's assigned to them in FogBugz.
9. Get into the habit of writing all your bug reports with three sections: steps to repro, the bug itself, and what was expected.
10. Avoid the temptation to add new fields to FogBugz. Every month or so, somebody will come up with a great idea for a new field, for example, keeping track of the file where the bug was found, or how often the bug is reproducible, or which exact versions of which DLLs were installed on the machine where the bug happened. Don't add fields. If you do, your new bug entry screen will end up with a thousand fields that you need to fill out. Suddenly, you have a high ceremony bug tracker that nobody wants to use because there are so many required fields. For FogBugz to work, everybody needs to use it, and if entering bugs "formally" is too much work, people will start sending emails on the side, and issues will get lost.
11. (Free bonus) Don't take bugs personally! If a bug is assigned to you, it's not a personal criticism, it's just a way to make the software better. After you get your first three thousand bugs or so, you'll stop feeling dejected and start feeling like a fun puzzle has appeared for you to solve. Some people pay cash money for these fun puzzles, printed up in books, which they solve at the beach or on a hammock. You get to solve them at work and get paid for it! What can be more fun than that?