One difficult thing that can happen sometimes during the coding process is how we identify/report/fix/verify bugs in the system.

I’ve seen situations where a bug is reported without enough informations to make everything else go painlessly. The following notes come from observations and mainly from an article by Joel Spolsky, cofounder of StackOverflow.

The 3 parts we should follow for every good bug report are the following:

1. Steps to reproduce
2. What you expected to see, and
3. What you saw instead.

Here is what Joel says:

If  you don’t tell me how to reproduce the bug, I probably will have no idea what you are talking about.
If you don’t specify what you expected to see, I may not understand why this is a bug.
If you don’t tell me what you saw instead, I don’t know what the bug is. That one is kind of obvious.

Here are Top Ten tips for bug tracking from Joel:

1. A good tester will always try to reduce the repro steps 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 can close a bug is the person who opened it in the first place.

3. There are many ways to solve a bug. Fixed/Won’t Fix/Postponed/Not Repro/Duplicate…etc…

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

5. You’ll want to keep careful track of versions so that the tester doesn’t have to retest the bug on a version of the software where it wasn’t even supposed to be fixed.

6. If you’re a programmer and you’re having trouble getting testers to use the bug database, just don’t accept bug reports by any other method.

7. If you’re a tester, put the bugs in the database and let the database email the programmer. No need to email him yourself. You can also talk to him if you want to, but using the bugs database system is a must.

8. If you’re a programmer, and only some of your colleagues use 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 bug database that you installed at great expense, start assigning new features 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 bug database.

If you are developing code, even on a team of one, without an organized database siting all known bugs in the code, you are simply going to ship low quality code.

Get Joel’s post here.