How to Create a Good Bug Report

Wednesday, 14 May 2014 18:38

The template of the bug report depends on the bug tracking system you use. Usually the bug report should contain the following fields:

  • unique identifier;
  • build version;
  • summary;
  • description;
  • step to reproduction;
  • reproduction (always, sometimes);
  • result;
  • expected result;
  • severity;
  • priority;
  • symptom.

As soon as a bug has been found, it must be reported because you can forget about the bug. Do not prepare the report on a paper (you can lose it) and log the report to the bug tracking system. These are simple rules but many testers neglect them and many bugs have been left unfixed.

Summary should be short and capacious. When everyone looks at the summary first time, he should understand what the bug is. It is an ideal, you have to strive for such summary. It needs to make a full description of the uncovered bug including OS, DB, browser, flash player version, etc. You should describe the steps for reproducing the bug and their result in detail. The bug has to be repeated a few times. In this way you will ensure that it is the defect of the tested application but not a fault of yours (unfortunately tester’s faults occur often enough).

The report text should be simple and easy to understand. It is useless to write long stories with a lot of details. The report should be clear, accurate and complete. You should not blame anybody for the bug. Your target is the bug report as the user sees the problem. Write better in the third party, it is not necessary to write from yourself. It is better to write “Error message appears” than “I saw an error message”.

Severity should have one of these values:

  1. blocker – the bug blocks development and(or) testing work
  2. critical – the bug is cause of crashes, loss of data, severe memory leak
  3. major – the bug leads to major loss of function
  4. minor – the bug leads to minor loss of function, or other problem where easy workaround is present
  5. trivial – the bug is a cosmetic problem like misspelled words or misaligned text

Symptom can have one or a few values. It can be incorrect operation, data loss, cosmetic flaw, documentation issue, installation problem, localization issue, missing feature, slow performance, system crash, unexpected behavior, unfriendly behavior, variance from specifications and so on. The symptom is not required field because such information can be found in the description or in the steps result.

Priority shows sequence of the bug fixing. It can have values like as ASAP, high, normal, low.

You can attach screenshots, videos and error logs to the bug report. Sometimes one screenshot is more useful than long confused description.

One bug report must be associated with one defect. Only a bad report describes a few bugs at once. If a defect follows from another, create separate reports and make links to each other.


Item tags