How to Write Effective Bug Report

The bug report should be effective because fixing a bug depends on how effectively you report it. Reporting a bug is nothing but a skill and we will explain to you how to achieve this skill.


“The point of writing Defect report is to get bugs fixed” – By Cem Kaner. If a tester is not reporting bug correctly, a programmer will most likely reject this bug stating as irreproducible. This can hurt testers moral and sometimes ego also. (I suggest not to keep any type of ego. Ego’s like “I have reported bug correctly”, “I can reproduce it”, “Why he/she has rejected the bug?”, “It’s not my fault” etc etc..)


Qualities of good Software Bug Report

Anyone can write a bug report. But not everyone can write an effective bug report. You should be able to distinguish between an average bug report and a good bug report. How to distinguish a good or bad bug report? It’s very simple, apply the following characteristics and techniques to report a bug.


1. Having a clearly specified bug number :

Always assign a unique number to each bug report. This will help you to identify the bug record. If you are using any automated bug reporting tool then this unique number will be generated automatically each time you report the bug. Note the number and brief description of each bug you reported.


2. Reproducible:
If your bug is not reproducible, then it will never get fixed. You should clearly mention the steps to reproduce the bug. Do not assume or skip any reproducing step. Step by step described bug problem is easy to reproduce and fix.


3. Be Specific:

Do not write an essay about the problem. Be Specific and to the point. Try to summarize the problem in minimum words yet in an effective way. Do not combine multiple problems even if they seem to be similar. Write different reports for each problem.


How to Report a Bug

Use the following simple Bug report template:
This is a simple bug report format. It may vary depending upon the bug report tool that you are using. If you are writing a bug report manually then some fields need to be specifically mentioned like Bug number which should be assigned manually.

Reporter: Your name and email address.

Product: In which product you found this bug.

Version: The product version if any.

Component: These are the major sub-modules of the product.

Platform: Mention the hardware platform where you found this bug. The various platforms like ‘PC’, ‘MAC’, ‘HP’, ‘Sun’ etc.

Operating system: Mention all the operating systems where you found the bug. Operating systems like Windows, Linux, Unix, SunOS, Mac OS. Mention the different OS versions also if applicable like Windows NT, Windows 2000, Windows XP etc.

When should the bug be fixed? Priority is generally set from P1 to P5. P1 as “fix the bug with highest priority” and P5 as ” Fix when time permits”.

This describes the impact of the bug.
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 the new feature or some enhancement in existing one.

When you are logging the bug into any bug tracking system then by default the bug status is ‘New’.
Later on, the bug goes through various stages like Fixed, Verified, Reopen, Won’t Fix etc.
Click here to read more about detail bug life cycle.


To find sample Defect Report Click Here!(Sample-Status-Report)


1 Comment
  1. HatsOff 11:21 AM / August 27, 2016 - Reply

    It’s wonderful to be here, Such a nice explanation of most confusing topic …. I have in industry since 6 yrs and feeling good that i still have lot of space to improve my approach after reading your article …. Thanks 🙂

Leave a Reply