|
|
|
[ Help Index ] Top Ten Tips for Successful Bug Tracking 10 A good tester will always try to reduce the repro steps to the minimal steps to reproduce; this is extremely helpful for the programmer who has to find the bug. 9 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. 8 There are many ways to resolve a bug. FogBUGZ allows you to resolve a bug as fixed, won't fix, postponed, not repro, duplicate, or by design. 7 Not Repro means that nobody could ever reproduce the bug. It's usually used when you have one of those once-in-a-blue-moon bugs and nobody can figure out how to find it or fix it. Programmers often use as a shorthand to indicate to the tester that there were not enough repro steps in the bug report. 6 You'll want to keep careful track of versions. Every build of the software that you give to testers should have a build ID number; when a bug is found, put the exact version number in the Version field. When a developer fixes a bug, they can include in their description something like "fixed in build 2019" or "will be fixed in tonight's build" 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. FogBUGZ also includes a "Fix For" field. This is used to indicate the shipping release of the product for which the bug must be fixed. That way, when you've got a beta coming up, it's easy to create a filter of all the bugs that must be fixed for the beta. When you fix a bug, set the "Fix For" field to the release version in which it was first fixed. Then it's easy to create a filter listing all bugs fixed for a particular release, which your customers can use to see if you've fixed their favorite bug. 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 FogBUGZ. I can't keep track of emails." Often testers are trying to be diplomatic: they don't want to "accuse" the programmer of a bug until they are 100% sure, so they end up trying to find the programmer in person and confirm it before they put it in FogBUGZ. This is a waste of everybody's time and a good way to accidentally forget bugs. If you find something that you're not sure is a bug and don't want to offend anyone, use the "inquiry" category instead of the "bug" category, and let the programmer decide whether to promote it to a "bug." 4 If you're a tester, and you're having trouble getting programmers to use FogBUGZ, just don't tell them about bugs - put them in FogBUGZ and let FogBUGZ send them a notification email. 3 If you're a programmer, and only some of your colleagues use the bug database, just start using FogBUGZ to assign them bugs that you find in their code. Eventually they'll get the hint. 2 If you're a manager, and nobody seems to be using FogBUGZ, start assigning new features to people using FogBUGZ. Use the category "Feature" instead of "Bug." 1 Avoid the temptation to add new bureaucracy around FogBUGZ. Every month or so, somebody will come up with a great idea for a new field to put in the database. You get all kinds of clever ideas, for example, keeping track of the file where the bug was found; keeping track of what percent of the time the bug is reproducible; keeping track of how many times the bug occurred; keeping track of which exact versions of which DLLs were installed on the machine where the bug happened. It's very important not to give in to these ideas. If you do, you'll end up with one of those bug tracking systems with a thousand required fields, and nobody will want to input bug reports any more. For the bug database to work, everybody needs to use it, and if entering bugs "formally" is too much work, people will go around FogBUGZ. One of the great strengths of FogBUGZ is that it is a low-ceremony system: there are no required fields in bug reports.
|
