How To Make A Good Bug Report & Why Are Users Negligent At Providing Them

I must confess that it is to my surprise how often I get poor bug reports. I receive partial bug reports every now and then, compelling me to sit down and ponder why there is such a gap between what information users provide when reporting bugs and what information developers require when they receive a bug report.

After a lot of research, I have reached the conclusion that a good bug report requires context and it is something users are unable to provide. There are no hard and fast rules that users can follow to precisely define the context of a good bug report. However, you can ask yourself one important question that works wonders for me. What piece of information should be included in a screenshot to increase the value of a bug report?

What Are Bug Reports?

Without any doubt, we know bug reports are important for any software development project. Users inform developers about the problems that occurred while using an application with the help of bug reports. It typically contains a detailed description of an issue and where it was spotted in the code. However, bug reports vary in terms of quality content and they might lack complete information. They need to be complete in order to achieve effective testing results. Testers utilize issue tracking tools to record, track, and resolve issues efficiently. 

Bug reporting assists developers to locate problems and additional information about these problems in an application to fix the issues during the development process. Although users may be tempted to write a lengthy report on what they have discovered, yet keeping a report concise will make it easier for the developers to resolve issues. Bug reports are usually considered as the currency of quality assurance. They are a product of the efforts put in by developers and they can be considered as the sole exchange of information between the developer and the tester. Thus, it is really important to get them right. A bad bug can be costly for a business and can cause other issues like:

• They can misguide developers, and waste their time
• They can leave developers frustrated, reducing their confidence in QA
• They provide a false impression of the status of a build
• They hamper the rest of the QA team who need to correct them
• They disrupt modelling tools designed to ascertain completion dates

Instant Comprehension

A developer opens a bug report, scans it for a while, and immediately understands the exact problem it describes. If a bug needs to be read multiple times while the developers go through it, it means it’s a failure. It can be a disaster if it has to be returned to QA for requesting additional information. 

Uniformity Gives Birth To Anonymity

There is a data field within each bug report displaying the name of the tester who reported the bug. This should be the only way to identify testers. Bugs should be written in a uniform style that follows a common standard. If a developer identifies testers by their style in which a bug has been reported, then either the testers are doing something wrong or all the other testers are.

Everyone who reads the bug report should be able to view the content with ease, irrespective of their role in the organization.  It can be a difficult situation when a subset of bugs is seen that were not submitted by QA, or they cannot be triaged by production, translated, reassigned, regressed, and closed by QA.

A Screenshot With Written Bug Descriptions

If the manifestation of a bug is visible, then it needs a screenshot, a video, or both. They can also be expressed by using a graph, chart, audio file, etc. When reproducing a bug, the bug is so evident because you are directly looking at it, which leads to the temptation to skip capturing it on video as it is obvious. 

Conclusion

Writing a bug report is not an art, it is a science. One of the most commonly asked questions is what makes a good bug report may seem like an easy question to answer. However, if this question is approached from a developer’s perspective the answer is something like ‘a good report is something that we developers failed to spot and is easy to fix’. Testers have a very different perspective, they need to evaluate the quality of the data within the report itself rather than the bug it describes. Testers can report bugs with the help of the right issue tracking tools to make the most of their testing efforts.