How to make a perfect bug report

How to make a perfect bug report

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.

Pressing the clear button doesn’t clear the website contact form
Whenever I input my name on http://mysite.com/contact-form and click the clear button 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.

It is possible to take over accounts by manipulating POST requests

  1. Make sure that Fiddler is running and capturing all requests.
  2. Open http://mysite.com/account-management/ and enter current and new password.
  3. Click the submit button.
  4. In Fiddler find the POST request that contains the password and drag it to compose tab.
  5. Change the userId parameter value to 1 and click the execute button.

This manipulation allows changing passwords of other users. It is also possible to change the email address which allows taking over other accounts.

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.

Leave a reply