Blog / Testing basics

Bug report basics: how to write one developers can act on

A bug report is a message to someone who was not there when you found the problem. If they cannot repeat it, they cannot fix it. Good reports save everyone time.

The parts of a bug report

1. Title. One line that says what is wrong and where. "Login button does nothing after entering a valid password" beats "Login not working".
2. Environment. Browser and version, device, operating system, and the build or page address.
3. Steps to reproduce. Numbered, short, in order, starting from a clean state.
4. Expected result. What should happen.
5. Actual result. What happened instead.
6. Evidence. A screenshot, a short screen recording, or an error message copied exactly.

An example

Title: Error message not shown when email field is left empty on signup

Steps: 1. Open the signup page. 2. Leave the email field empty. 3. Enter a valid password. 4. Click Sign up.

Expected: A message asks the user to enter an email.
Actual: The page reloads and no message appears.

Severity and priority

Severity is how badly the bug affects the product. Priority is how soon it should be fixed. A typo on the home page is low severity but may be high priority if it is the company name. Suggest a severity, and let the team decide priority.

Common mistakes

• Putting several problems in one report. One bug, one report.
• Writing steps that skip a click.
• Blaming the developer. Describe the behaviour, not the person.
• Not checking whether the bug is already reported.

Practise it

Pick any free website, find something small that looks wrong, and write it up using the list above. Then ask a friend to follow your steps. If they see the same thing, your report works.