Why Writing a GOOD Bug Report is Important


While it may be tempting to write a 10-page report on what you discover. Creating a straight forward and concise report will make it easier for others to solve the problem in the long run. A good bug report can decrease the time required in fixing a bug, but a bad bug report will cause at least one, if not all, of the following scenarios:

  • Reporting bugs hastily and incorrectly will increase your work as you will have to explain it to the developers, and in some cases, rewrite the entire report, or need to re-test and fix your bug report.
  • If the report is not clear and informative, developers will not be able to make sense of what you wrote when reviewing the bug.
  • Documenting the bug incorrectly can harm your reputation as a QA Professional.

Things to keep in mind

The Problem - Focus on your goals and the reasons you’re writing a bug report in the first place. Make sure the title and description are about the problem, and not the less important details.

  • Length - Details are appreciated, but walls of text can make it hard to follow and understand. Keep your report short, simple, and to the point.
  • Proof - Some bugs only exist on one platform or OS; some you cannot reproduce. Make sure to include screenshots, videos, and logs to help others confirm and analyze what happened.
  • Related Issues - Are there any other actions that could cause the same problem? Are they relevant to mention in your report?

Is there a standard template for reporting bugs?

Generally, a good bug report will outline the steps taken to reproduce the bug, the environment(s) in which the bug was seen, the observed behavior compared to what was expected, and a decent “executive summary” that succinctly details the problem. However, there is no one standard template and varying best practices will depend on your company and its needs.

Why are the titles of my bug reports so important?

A clear bug title can summarize the core problem as well as the environment affected by hooking an observer into opening the bug and reading the details. A title can also serve as a reminder of the bug content when you are viewing reports or lists of bugs. Remember, someone will be trialing the bugs you log and deciding where they fit in the development plan. As a tester, you have the responsibility of searching for bugs to avoid logging duplicates. It seems only fair that we should all set a good example in our bug titles to ensure they’ll captivate an external observer. The title should not be generic (e.g., Error on Application), neither should it be too long. A good length would be one sentence that provides the highlights of the issue, as well as a way for a user to understand how they could run into it.

Examples of good and bad titles

  • Good: “Unable to log into the system when username contains foreign characters”
  • Bad: “User cannot authenticate in Japanese”
  • Good: “Log rotation doesn’t work, grows until the disc runs out of space”
  • Bad: “Server crashes due to log size”


Why should the description be concise, but also complete?

The description is the area where you can add all the extra details needed to support the bug report. At the same time, don’t write too much, or include irrelevant information and expect people to read it.  3 to 10 lines should be enough in 80% of cases. A bug report description should always include the steps needed to reproduce it, the consequences of the bug, and the suggested/expected behavior:

  • Steps to reproduce - Outline all of the steps necessary to ensure that people who need to fix the bug can understand it correctly. Include the data required to reproduce it (e.g., account names, strings, links, etc.). Make sure the steps to reproduce are numbered from beginning to end so that developers can easily follow through and repeat the process. We should keep the number of steps whittled down, as reproducing a bug that has 99 steps can be incredibly hard to follow. Using the “>” symbol is usually an excellent way to explain your steps.
  • For example: a) Go to settings > Profile b) Tap on More Options > Delete Account
  • Consequences of the bug - Include what the user will experience when and if the bug occurs in the application. Again, sometimes this can be trivial, but other times it won’t be, and you’ll need to make sure the reader understands the consequences.
  • Suggested/expected behavior – Include the differing behavior, especially when you are reporting a bug that doesn’t create data-loss, but on the other hand, makes the application uncomfortable or unusable to the end-user.

Setting the correct severity

One of the biggest and most common testing problems is to overestimate the severity of your bugs.

You may be happy you have found a bug, and you want it fixed, but giving it the wrong level of seriousness will only make the others lose valuable time. They may prioritize poorly, finding out that a bug report is not as severe as was indicated, leading to a “boy that cried wolf” scenario. When in doubt, it’s always a good idea to consult your fellow QA peers about the severity of the bug report.

Make use of the categorizing fields

When working with a structured bug tracking system, we have fields that categorize our issues. Examples of these fields are modules, infrastructure, browser, OS, etc. Make use of these fields as they will help your team categorize (and in some cases reproduce) the bug correctly.

How useful is it to name attachments logically and consistently?

Naming attachments logically and consistently is incredibly useful. At a basic level, labeling screenshots as ‘before’ and ‘after’ takes away any potential confusion for the recipient of the report. When you’re dealing with more complicated bugs, you can both name your screenshots logically and reference the names of the screenshots accordingly. Anything you can do to minimize confusion and communication errors is invaluable. Examples of useful screenshots:

  • Before/after
  • With a certain setting/without a certain setting
  • Numbered annotations attachments suggestive titles
  • Drag and drop attachments so they’ll show up as thumbnails

Follow-up and comment

You should continue following up on your bug reports and provide comments when necessary. Comments are especially important when a developer or other stakeholder does not understand the bug, and either rejects it or delays it. You are the owner of your bugs, and certainly have a say on them, so you should make sure that they hear what you say. This behavior will always add value and make your clients understand that their project is being taken care of with great attention.



This is some text inside of a div block.
This is some text inside of a div block.
A Simple Way to Confirm Your Code is Live