How to write a good bug report?

A good bug report is crucial for fixing the code error effectively. Although we all know that, it is not uncommon for a developer to get a notice like: » X doesn’t work, application crashes after the login, etc.«

This kind of report is unclear, not specified enough, and in some cases even offensive to the developers. They will be asking additional questions like “What exactly doesn’t work, what did you do to get this result, in which environment were you testing”?

That is annoying, time-consuming, frustrating, and damaging to QA’s reputation as well.

An effective bug report has the following elements:

• Bug ID
• Bug title
• Environment/Platform
• Description
• Steps to reproduce a bug
• Expected result
• Actual result
• Visual proof (screenshots, videos, text) of bug
• Severity/Priority

Let’s dive into the details:

Bug ID:

This is usually a combination of the first letters of the project’s title and a serial number. Most bug tracking tools assign an ID for each bug.

Bug title:

Bug title is a short description of the problem, which helps you to navigate the issue quickly. It’s helpful to include the name of the feature where you found an issue.

Environment/Platform:

An application can behave differently from one environment to another. It depends on the operating system, browser, screen size, etc. Make sure your developers know your technical environment.

Steps to reproduce a bug:

 your bug must be reproducible; otherwise, there is no chance it will be fixed. So be sure not to skip any step. And before you send a report, reproduce the bug yourself, following the exact steps you have written!

Expected result:

What should happen after the last step (according to requirements)? You have to describe what the right outcome is.

Actual result:

What actually happened? Be specific.

Visual Proof:

A screenshot (or, in some cases, a short video) is worth more than a thousand words. It saves time, and it is easier to follow. You can highlight the part of the image with red color to draw attention to the right area.

Severity/Priority:

Bug Severity is the degree of impact a defect has on the system.

There are different levels of severity (which is by the way determined by QA):

• Low: Bug won’t result in any noticeable system breakdown.
• Minor: Results in unexpected or undesired behavior, but not enough to disrupt system function.
• Major: Bug capable of collapsing large parts of the system.
• Critical/Blocker: a bug that breaks a function/feature; therefore, it must be fixed by the developer before further testing can be done on that functionality.

Bug priority defines defect priority value by the level of urgency to be resolved for the defect.

• Priority 1 – Critical: a critical bug that needs an immediate fix without which the application can’t continue functioning. P1 bug needs immediate attention.
• Priority 2 – High: it’s still a very important issue
• Priority 3 – Medium: defects are fixed during regular work
• Priority 4 – Low: a cosmetic issue, which is to be scheduled when time is available

The product manager or client is the one who determines bug priority.

Conclusion:

As we can see, just funding a bug is not enough – a good report is essential to fix it properly. Luckily, there are a lot of bug tracking tools that can guide you through the reporting process.

Want more? Read Tips to follow when writing a bug report.