How to write a good bug report?
This is the first article in the series on Bug Reports. Click here to read the next article on: Tips for Writing the Steps to Reproduce a Bug.
One of the most important skills that you need to have in your tester’s tool box is the ability to write a good bug report. Finding defects is only part of the job. If developers can’t reproduce the bugs you find, they’re going to have a very tough time fixing them. Your bug tracking software should include a number of mandatory fields to ensure that testers give a complete account of the defect they encountered. And testers should hone their descriptive skills.
A good bug report contains:
A descriptive title
Everything starts with a title. It must be clear and descriptive so that you can get an idea of what the report is about at a glance. It also has to be clearly differentiated from all other bugs in the database. A good way to think about bug titles are to use the PAL system: [P]roblem [A]ction [L]ocation.
This means that a title must answer 3 questions:
1. What is the problem?
2. What action must the user perform to trigger the problem?
3. Where does the problem occur?
And keep in mind, these 3 questions must be answered in less than 140 characters!
A concise description
A good bug report has a clear and concise description. This is an opportunity to explain the defect and put across all the pertinent details. Developers don’t want to read a novel. Describing something accurately and concisely is a skill that develops with practice. Remember that the person reading your description has not seen the bug, so avoid assumptions.
Clear, expected results
You have to make it clear what you expected to happen and how the defect diverged from that expectation. This field helps to prevent any misunderstandings, and it gives the developer a clear idea of what went wrong.
Details about the project and version
It’s not unusual for testers to work on multiple projects at the same time. Sometimes they’ll even share a database, so ensuring that your bug is listed in the correct project and section within that project is vital. You also need to get the software version right. Sometimes a bug will be fixed when a different defect is addressed, or simply by some change in the newest version of the software. If the version is wrong, developers may be embarking on a wild goose chase.
Any background information you can provide about your environment will help developers track that bug down. It helps to list the device you were using, the operating system, the model and the browser you used. Every detail you can give about the platform will make for a good bug report.
If you want to take things further, include your device’s processor, screen resolution, etc.
Type and severity
These fields go hand-in-hand. A functional bug will generally be treated more seriously than a suggestion. Developers also need to know how severe the bug is. No product ships with zero defects, so having bugs categorized correctly in terms of type and severity helps the decision-making process with regards to what gets fixed and what doesn’t. If you don’t understand these fields, ask for instruction. It also helps to review other bug entries in the database.
Steps to reproduce (this is very important!)
One of the most important steps in a good bug report is providing a step-by-step account of exactly what you did to find the defect. You can use software tools that catch your key strokes, or record screenshots or video files as you test. Other times you’ll be writing from memory, so take notes as you go. Make sure that you test your own steps again before submitting the bug.
Give an indication of the ability to reproduce as well. At times, you’ll be confident about your steps but, upon repeating them, the bug might not occur. If it happens every time, at random or only once, then the developer needs to know that.
A visual attachment
Supporting material is always gratefully received by those tasked with fixing defects. Usually this will be screenshots, but it can include audio and video files. You’ll want to annotate your screenshots to highlight problems.
Keep in mind this is often what developers look at first prior to reading the text you provided. If you can convey the issue in a single screenshot, you’re helping save precious time and proving a good bug report.
Tags and links
It can be a good idea to use descriptive tags that enable you to filter the database and find groups of related bugs. You’ll want to include another bug ID or a link within your defect report to something that you feel is strongly related or similar, but not similar enough to be a duplicate.
It’s usually going to be up to the lead developer or management to assign bugs. However, on occasion you might receive instructions about who to assign to. Leaving unassigned or wrongly assigned bugs in the database is a dangerous thing. They can potentially slip through the cracks. Make sure you’re clear on the expectations for assigning.
Put it all together
Bring all of this together and you should produce a good bug report. If you’re uncertain about the quality of your bug reports, ask for feedback. A quick chat with the developers can really help you understand what they need. Additionally, you can also read the bug reports entered by experienced testers to get more pointers.
How can Lean Testing Help?
Lean Testing is a free, user-friendly bug tracker which can help both beginner and professional testers organize their bug reports and communicate with their team. Our professional, standardized bug reports ensure that no important aspect of the testing process is left behind. Gone are the days where developers would have to call testers to understand every other bug. We expect great quality from our bug reports, why shouldn’t you?
If you’d like to try Lean Testing out for yourself, you can register for free at: https://leantesting.com/.
This was the first article in the series on Bug Reports. Click here to read the next article on Tips for Writing the Steps to Reproduce a Bug.
ABOUT THE AUTHOR:
Simon is an experienced freelance technology journalist covering mobile technology, software, and videogames for a wide variety of clients in print and online. He regularly contributes to Digital Trends, Tech Radar, and Android Authority, and he ghostwrites for CEOs in the technology space. After completing a Masters in Scottish History at Edinburgh University, he began his career as a games tester, progressing to lead tester, game designer, and finally producer, before leaving the industry to write full time. He is passionate about the potential for good software and hardware to improve our lives, and strongly believes that thorough testing is a vital prerequisite for greatness.