What should we consider when writing a bug report?

Writing a good bug report saves us time to quickly resolve issues. It is important not only for the developer but also for the product manager because prioritization is adjusted according to the bug reports.

Let’s examine what the bug reports should contain, respectively.

Title

In title should be a short explanation of what the issue is. A good title should have information about product name or error message or steps you were doing when it failed.
For example:

• How not to do: “Crash”, “Looking an error”, “Bug”
• How to do: “Error 5C79 when confirming request”

Description

Try to briefly describe what you were trying to do before you find the bug and how to react to this your application. Try to use simple natural language and write all simple sentences.

• How not to do: “XXXX doesn’t work”
• How to do: “Clicked on ‘File / Save As…’ and the ‘Save’ dialog came up → Clicked on the ‘OK’ button but the file did not save.”

Steps to Reproduce

The description should explain exactly the steps to take to reproduce the defect, along with what the expected results were and what the outcome of the test step was. The report should say at what step the failure was observed.

Platform

Will be a big plus to determine what you are using to run the software, particularly operating system name and version, in the case of Web Application, should tell web browser name and version. There are a lot of different versions of systems and browsers, which important to developers to know.

• How not to do: “ Windows ”
• How to do: “ Windows 10, Chrome 84.0.9 ”

Expected Result

What should happen when you make an action?

• How not to do: “I tried to print, but it didn’t work”
• How to do: “From the ‘Shop’ screen, click on the ‘Print’ button”

Actual Result

Here’s the result of the bug. As usual, testers are a little bit indefinite in this part of the bug report. So, try to be concise.

• How not to do: “Button does not work as expected”
• How to do: “Button closes app”

Severity

The severity of the defect shows how to sever the defect is in terms of damaging to other systems, businesses, environment, and lives of people, depending on the nature of the application system.

Types of Severity:

• Blocker: No further testing work can be done.
• Critical: Application crash, Loss of data.
• Major: Major loss of function.
• Minor: Minor loss of function.
• Trivial: Some UI enhancements.
• Enhancement: Request for a new feature or some enhancement in the existing one.

Attachments

Any evidence of the failure should be captured and submitted with the defect report. This is a visual explanation of the description of the defect and helps the reviewer, developer to better understand the defect.

Reported by

Again, this is important, because if we may need to refer to the person who raised the defect, we have to know who to contact.