In the high-flying fast-paced world of web development it seems like the current “hot” technologies change every day. Luckily there some things that never change… bugs. While we are trying to improve our method of logging, assigning, tracking and resolving bugs, I’d like to share an article that gives general pointers on good bug logging. Although this article was written in ancient times (2000) it’s tips are still useful:
Every good bug report needs exactly three things.
1. Steps to reproduce
2. What you expected to see, and
3. What you saw instead.
Additionally here are the most relevant of the top ten tips for bug tracking:
1. 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.
5. 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 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.
10. Avoid the temptation to add new fields to the bug database. 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 % 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, your new bug entry screen will end up with a thousand fields that you need to supply, 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 the bug database.
I’m also going to add my own 11th top ten tip for bug tracking:
For more info check out the article here
No related posts.