Four Tips to Write Better Bug Reports

This is a guest post by Nishi Grover Garg.

Writing defect reports is a constant part of a tester’s daily life, and an important one too! How you report the bugs you find plays a key role in the fate of the bug and whether it’s understood and resolved or ends up being deferred or rejected.

It is imperative for every tester to communicate the defects they find well. Here are four tips to help you write better bug reports.

Study past bug reports

If you are new to your team or new to testing itself, the best way to learn about good bug reporting is to read the team’s past bug reports. Try to understand the bugs and see if you could reproduce them. Do you understand what the report is saying? Are you able to reproduce the bug with only the information included? Do you need any additional steps or details to be able to reach the same stage?

By doing this exercise you learn the best way to present bugs so that the team can understand them. You’ll get a feel for the business language and the project’s jargon to be able to describe features and modules.

You may also see some imperfections in the past reports, so you can think about how to improve them and what other information would be useful to include.

Create your own game plan

A tester needs to accept the constant need for documenting the bugs they find. Even if the team is agile and works with minimal or leaner documentation, testers still need to document their bugs in some way to be able to clearly communicate and act on them. Once you understand the importance of writing good bug reports, you can get creative with them.

You can create a shortcut for yourself, like writing down a summary or title of each bug you find as you go about testing and saving the screenshot. When you get down to reporting, you can quickly fill out the steps, as well as expected and actual results, and attach the saved screenshots. Doing this could be faster and save you the effort of repeating steps just to get the needed screenshots and logs.

Keep a checklist

Most defect tracking tools require a certain number of fields to be filled out when submitting a defect report, which is a good way to know if you added enough information. It is typical to include some kind of “proof” of the bug, like a screenshot of the erroneous stage, a video screen recording or a failure log.

You could also keep a track of your previous bug reports to know what additional information the developers asked you for later, like some additional log files or stack traces to help them fix the issues. You can then make those items a part of your bug reports as a norm.

Including this additional information not only makes more sense to the developers reading the bugs, but also makes you look further and perform a more detailed analysis. Sometimes, you may end up identifying the root cause of the bug itself!

Mind your language

Writing anything requires certain communication skills. When writing defect reports, you need to focus on not only the content, but also the language you use in order to clearly communicate the problem and create the right impact.

• Use short sentences
• Write in a crisp and meaningful way, eliminating unnecessary back story or information
• Do not use personal nouns or direct personal references
• Write clear, numbered steps to reproduce the bug (even if you feel they are obvious, they may not be for someone new reading the report for the first time, or after a number of years when the application has changed)
• Keep the report unambiguous. If the bug is inconsistent, let it be clearly known
• Write an expected result. If it is not obviously known, express an option you think could be a valid result. Leave the decision to the team and the product owner

In the end, my main advice would be to give each bug report your best shot and all due effort. But do not get personally attached to them. Many bugs may go unnoticed or be rejected for business reasons, even despite your giving all the information and writing a great report for them. It is just part of a tester’s life. Keep doing a good job, and move on to the next one!

Nishi is a corporate trainer, an agile enthusiast, and a tester at heart! With 11+ years of industry experience, she currently works with Sahi Pro as an Evangelist and Trainings Head. She is passionate about training, organizing testing community events and meetups, and has been a speaker at numerous testing events and conferences. Check out her blog where she writes about the latest topics in Agile and Testing domains.