Lately after some bad experience, I tried to find a solution on how to report bugs better.
Whenever me or my team sent a simple email with some explanation about the issue, it took about 2 minutes until it backfired and the email sender got bombed with questions (per email or just in person).
Emails that were too detailed backfired as well. Not sure why, but I assume that a lot of developers don’t want to be treated like they are personal “slaves” (even if they are the slaves. It comes with the job :-)).
Long story short: Here my ideas of coming up with some Bug reporting guidlines:
1. Name the bug. Be precise about the bug and give it a good synopsis.
This means a descriptive name “xy resulted in xyz”
2. Describe the bug and where it appeared (URL if possible).
Make it easy for the developer to re-produce the bug.
3. Add screenshots
Always important and a great help. When you make a screenshot, don’t forget to clear your tabs/Google search field!
4. Use software if your development team is ready for that.
There are a bunch of bug tracking software possibilities. You can use Basecamp, Goplan.info, BugAware, Netresultstracker…. At my place unfortunately not possible.
5. Assign bug to one developer (or CTO) or one engineering group
Depending on the size of your company, assign the issue to one developer or team. This way you have a person/group to chase down if something goes wrong or takes too long.
6. Prioritize issue and assign a severity
If you have more than one issue, prioritize the issues.
7. Archive bugs
It always makes sense to me to record and archive issues. From my experience I noticed that some issues come up again.
8. Add a date / Issue number to each problem
This should be self-explaining
9. Make sure you add your operation system and browser
This should be self-explaining as well.
10. Report only one bug at once.
More than one bug just confuses developers and won’t help getting it resolved.
Any other things, that I forgot?
October 2nd, 2007 at 8:58 am
Good post! At point 2, you should stress out that it’s not only describing the bug (”I got an error saying this & that”) but the steps that led to the problem (”I came on the site from Google search XYZ, clicked on the promo item, and when I tried to do the checkout I got error this & that”). Give as much detail as possible about the clicks and the values put in forms at each step of your visit. When describing a problem, avoid stating what “you” think is the issue and focus on facts.
Stephane Hamel
http://blog.immeria.net
October 2nd, 2007 at 3:49 pm
Great tutorial.
Sometimes, it takes less time to record a short video of you reproducing the bug rather than taking several screenshots. I use Camtasia to do that and it is a real time saver.
Also, if we are dealing with web applications, it is nice to ask our developers to include a custom error page that automatically sends an email to the developer every time there’s a bug, usually with the line of code that causes the problem, etc.
And for client-side applications, a log file is of great help to the developer that needs to find out what caused the bug.
October 2nd, 2007 at 5:49 pm
Agree! All the points you mention above are true. A video is actually a great idea. Thanks for the input!