How to create a bug report? Best practice

It doesn’t matter what position you occupy in IT, you can be a software developer or DBA, but you need to know how a good bug report looks like. If you are from the QA department, you need to pay extra attention to this post. The theme of the article is the creation of bug reports. In this short article I will explain what is a bug report, from what parts it should consist and what is the purpose of each field in the report.

What is a bug report

I don’t want to quote some books or other information resources to define a bug report. Formalized definition isn’t so important as understanding of the term. I always give the following explanation for QA beginners: a bug report is a document where you as a software tester describe a problem which has occured in a program. I think such approach gives the most essential thing for QA Engineer – understanding of domain area.

Target of a bug report

Bug report has just one aim to inform developer about some problem in the software. This is one of the ways available for communication between the development team and the testing team. Any type of communication requires some set of rules. Bug report is not an exception.

Bug report structure

Independently of bug report system any bug report should contain some required fields. Here is a list of the required items:

• Title – this is a field for the bug name. In ideal it should be as short as possible. It answers on the question: What? and Where?
• Version – here you specify version of the software.
• Environment – this is a field where you specify the environment in which the bug is reproducible.
• Steps to reproduce – here you write sequence of actions, which developer needs to perform in order to reproduce the bug.
• Actual result – this is a field where you specify real behavior of the system.
• Expected result – here you specify behavior of the system according to the documentation.
• Reporter – here you should write your contacts.

In general this set of fields is an optimal to provide quality communication between QAs and Developers. You can add additional fields e.g. priority, severity, date of creation, etc. These extra fields in some cases can be helpful, but only if they are really required from the project’s perspective.

Attachments

Depending on the nature of the bug you might need to attach some screenshots or logs. In those cases when screenshots will help developer with bug fixing, you need to take a screenshot illustrating the bug and highlight the problem zone. If the software being tested implies some logging system you can attach the log which was generated while reproducing the bug.

Summary

In order to create a good bug report, you have to write your thoughts briefly and informatively. Try to find out the nature of the bug and describe it in the appropriate section. Remember – clarity of your description will affect the speed of the fix