How To Write A Fantastic Bug Report

We would argue that bug reports might be the most important part of software testing. You can test the software, but if you cannot communicate your findings to the development team then you are in trouble. Here is where an amazing bug report can make all the difference and lead to a smooth testing experience. 

‍

What is a bug report?

First, how do we define a bug report? A bug report is a documentation that testers will write for the development team to understand which parts of their code do not work or what parts of their software could use improvement. With high-quality bug reports, developers can go directly to the issue and solve it without spending their time trying to locate and reproduce the bugs. 

A fantastic bug report should only be focused on one bug and should have all the information that the developers need. It should be concise and contain the minute details that allow developers to pinpoint the issue. Without a detailed bug report, the developers will end up searching for bugs and wasting their time which can end up with some pretty unhappy team members. A good bug report is not difficult to write, but you need to remember some key points to include.

‍

Bug Number

Including a bug number in the report makes it much easier for the developer to find the report later and check if the bug has been fixed or not. If you can also make it link back to the ticket that was created for that bug, even better.

‍

Bug Title

The bug title should be able to tell the developer exactly what the issue is as it will be the first thing that they read. It needs to be concise, but reflect the problem at hand. It should contain the category of the bug and where it is located. Although these will be included later, it is important to have this in the title. Try and create a title that when searching would be easily identifiable. If the title is well-written, the developers may not even need to check the rest of the report. 

‍

Priority

Set the priority of the bug in the report. There can be different priorities based on the client, but usually, it follows the pattern of: Blocker, Critical, High, Medium, or Low. 

• Blocker: something in the program that makes the tester unable to test the issue
• Critical: a bug that makes the software unusable 
• High: when the bug affects a main feature and there is no way around it
• Medium: the bug affects a small feature or the workaround is easy enough to fix
• Low: minor visual issues, typos, etc.
  

Other times, clients could use a rating system of 1-5 for their priorities or different descriptors. By including the priority of the bug, it helps the developers understand the severity of the bug and adjust their work accordingly. 

‍

Platform/Environment

Platform and environment NEED to be included. Without this, the developers will not be able to find and fix the issue. Oftentimes bugs only occur in specific environments and not others. Include the operating system and browser that you were using and before you report the bug, try and check it out in other environments to see if it is a larger issue. For a fantastic environment description include the following:

• Device
• OS
• Account used
• Testing environment (which software platform)
• Connection type
• # of times reproduced
  

Including these can go a long way with developers figuring out the problem and fixing it. 

‍

Description

Descriptions are not long-winded. Write the summary of the bug and keep it short and succinct, if it is longer than three sentences it will not be read. Include the keywords of the bug so that it is easy to find when searching. 

‍

Steps to Reproduce

So. Important. If you do not show the developer how to get to the bug, they will not be able to fix it. We like to write the steps to recreate the bug in number format. For example:

1. Log in as a user with Total Access to a folder but Limited Access without the ability to edit 
2. Navigate to folder with total access
3. Right-click → select Create Folder
4. Enter folder name and select save
5. Loads forever and never saves

Do you see how it creates easy steps to reproduce that clearly lets the developers know what to do each step of the way? That’s critical. It would be awesome if the steps were short and to the point, yet encourage testers to be detailed so that the developers don't end up wasting a bunch of time and get angry at the testers for not telling them how to find the bug. When you first start writing your bug reports, send your steps to reproduce to someone on the team who isn’t working on the same issue as you. If they can recreate it from your directions, then you are in good shape.

‍

Expected Outcome 

The expected outcome is what the software should be doing. Write what you think should be happening when testing that particular software feature i.e. when I click the login button, I would expect a modal to appear prompting me to enter my username and password. Including this will help the developer to understand the intended functionality of the feature and where the bug is messing things up.

‍

Observed Outcome

The observed outcome is what the tester has actually seen happening in the software. This is the result of the bug. Do not be vague here, that will not help anyone. Instead of saying something like “Login modal does not work”, be specific. Try “Login modal opens when clicked, but as a user, I am unable to enter in my password”. Being specific allows the developers to have a better understanding of the bug and can be useful in their investigation. 

‍

Documentation (Screenshots, Videos)

We cannot stress this enough, always include documentation. Bugs are finicky, little creatures, and sometimes just disappear on their own or cannot be reproduced in different environments. The visual proof allows developers to see that the bug did occur and they can understand the problem more quickly. Including visual media can do a lot of explaining. 

‍

Tips

We are not finished yet, we have some extra tips and techniques that will help you craft some of the best bug reports out there. 

Reproduce the bug three times before writing the report: This is a good rule of thumb as it ensures that there is an actual bug and not just a weird fault with the operating system or you. 

Test the bug on other modules: if you are encountering what you think is a bug, check it on other modules before reporting it so the developers know how large of a problem it is. 

‍

Read the bug report: before you submit the bug report, read over it, preferably out loud. This will help you check for any mistakes and ensure a clear report is delivered. 

One bug=one ticket: Do not include multiple bugs into one report or ticket, just don’t. Each bug should have its own separate ticket or report even if they seem to be closely linked. 

Check if the bug already exists: search through already existing reports and tickets to see if the bug is already there, it makes no sense to have it copied again and developers will get annoyed if they see the bug reported twice.

Final Thoughts

There you have it folks, the best way to write a fantastic bug report. Write it up like this and you will have the developers be singing your praise!