Here are just a few things that will make a developers life that little bit easier, when it comes to reporting a bug. Saying that “X is broken, please fix it” doesn’t really help all that much, as your developer will still need to reproduce the bug in some manner before trying to tackle it. Giving them so much information might sound a little over the top, but they will appreciated it and will know what to filter out or in.
Reporting a bug
These are the requirements I use when asking people to submit bugs to me. Even if it’s not my code, but they still want help putting together a report, I will send them these 6 points.
- Description : details of what you think is wrong, or what you expect to happen when you do X.
- Screenshot : If it’s a web application make sure you include the full browser screen and the URL bar.
- Steps : What were the steps you did to get this error happen ? Does it happen every time you do the steps ?
- Frequency : How long have you been noticing this issue ? Has it always worked like this or is it only since the last release you’ve noticed it ?
- Importance : how critical is this issue, is this nice to have fixed or something that’s critical that’s stopping something major ?
- Environment : have you tried it in more than one browser or OS ? Have you disabled browser plugins that might interfere with the pages’ code ?
In some cases you might need to have a field for business case impact for the change/fix. But this could be done in second round of analysis once the developer has investigated the issue. If a potential change has subsequent impacts on other parts of the system then these decisions are generally discussed with the product owner and the lead developer or even at a higher level.
Standardised reporting
This also introduces a lay person into the world of standarised reporting. Getting a report in a particular manner means that the extra steps they take will save you and the person reporting time. Avoiding this back and forth between, is one of the major benefits, but it’s also severs as a good way for categorising these issues. Is the bug report really one of the following :
- a bug report
- a feature request
- a change request
- a user operational issue
- rights / permissions based issue
- etc.
Do you have any other things you’d like to know when people are submitting bug reports ?
8.20.2012
If it’s not a webapp, the version or build number is a must-have… you’ll often get bug reports from people using an outdated version of your app and that’ll help you avoid looking for bugs you’ve already fixed.
If you use a submission form for bugs, you can make the version number a drop-down option and explain to users how to update if they select an older version.
8.20.2012
That’s a fair point Adrian !
We can’t expect people to know what details we may want, but once they are told, then they don’t have any more excuses
Finding version number is sometimes difficult on an app, as many people don’t know about the Settings screen. One tip I heard was to have it on your launch image. But then again they might have to be quick to see that…