Common practice at the Order of Code is to show the product we are working on as quickly as possible to the client. While the application is far from ready it allows us to receive valuable feedback.
Such feedback comes in a form of bug and feature reports. No software is perfect and requirements changes are, to an extent, welcome.
Which brings me to the subject of this post. What should a good bug report actually contain? The quick answer is simple: what developers need to do to see the error that you are seeing.
Let’s have a look at an example bug report. Typical use case: user clicks the button and nothing happens.
Alright, alright… Some might say that I picked an easy example so let’s try something more complex. This time it is possible to change password of other people due to bad system design.
Testers and developers would consider such bug reports as well written and informational. While there are no strict rules, a set of guidelines is helpful. Lets call it: Radek’s recipes for robust bug reporting and retesting.
- Subject should briefly explain what’s wrong with the product.
- Avoid generic subjects such as The website is broken or An error is displayed.
- Description is to explain what is wrong and how to get there (reproduction steps). Nothing else.
- When testing websites provide a link to pages that are causing problems.
- If possible, try to find less demanding reproduction steps.
- Use simple and understandable sentences.
- Set a priority to the issue. Low for minor low-impact things and highest when the error makes you lose money. If it’s yet another bug stick with default.
- Provide a screenshot whenever possible.
- Important! Watch out for apps that automatically publish screenshots online. You don’t want to share something personal such as password or awesome UI design.