How to write a good bug report?

Tips and Tricks

Why good Bug report?
If your bug report is effective, chances are higher that it will get fixed. So fixing a bug
depends on how effectively you report it. Reporting a bug is nothing but a skill and I will
tell you how to achieve this skill.
The point of writing problem report(bug report) is to get bugs fixed ! By "em
#aner$ If tester is not reporting bug correctly, programmer will most likely reject this bug
stating as irreproducible. This can hurt testers moral and some time ego also. I suggest
do not keep any type of ego. !go"s like #I have reported bug correctly$, #I can reproduce
it$, #%hy he&she has rejected the bug'$, #It"s not my fault$ etc etc..(
What are the %ualities of a good software bug report?
)nyone can write a bug report. *ut not everyone can write a effective bug report. +ou
should be able to distinguish between average bug report and a good bug report. ,ow to
distinguish a good or bad bug report' It"s simple, apply following characteristics and
techni-ues to report a bug.
&) Ha'ing clearly specified bug number(
)lways assign a uni-ue number to each bug report. This will help to identify the bug
record. If you are using any automated bug.reporting tool then this uni-ue number will be
generated automatically each time you report the bug. /ote the number and brief
description of each bug you reported.
)) *eproducible(
If your bug is not reproducible it will never get fixed. +ou should clearly mention the
steps to reproduce the bug. 0o not assume or skip any reproducing step. Step by step
described bug problem is easy to reproduce and fix.
+) Be ,pecific(
0o not write a essay about the problem. *e Specific and to the point. Try to summari1e
the problem in minimum words yet in effective way. 0o not combine multiple problems
even they seem to be similar. %rite different reports for each problem.
How to *eport a Bug?
-se following simple Bug report template(
This is a simple bug report format. It may vary on the bug report tool you are using. If
you are writing bug report manually then some fields need to specifically mention like
*ug number which should be assigned manually.
*eporter( +our name and email address.
.roduct( In which product you found this bug.
/ersion( The product version if any.
"omponent( These are the major sub modules of the product.
.latform( 2ention the hardware platform where you found this bug. The various
platforms like 345", 32)5", 3,4", 3Sun" etc.
0perating system( 2ention all operating systems where you found the bug. 6perating
systems like %indows, 7inux, 8nix, Sun6S, 2ac 6S. 2ention the different 6S versions
also if applicable like %indows /T, %indows 9:::, %indows ;4 etc.
.riority(
%hen bug should be fixed' 4riority is generally set from 4< to 4=. 4< as #fix the bug
with highest priority$ and 4= as $ >ix when time permits$.
,e'erity(
This describes the impact of the bug.
Types of ,e'erity(
Blocker( /o further testing work can be done.
"ritical( )pplication crash, 7oss of data.
1a2or( 2ajor loss of function.
1inor( minor loss of function.
Tri'ial( Some 8I enhancements.
3nhancement( Re-uest for new feature or some enhancement in existing one.
,tatus(
%hen you are logging the bug in any bug tracking system then by default the bug status
is 3/ew".
7ater on bug goes through various stages like >ixed, ?erified, Reopen, %on"t >ix etc.
5lick here to read more about detail bug life cycle.
4ssign To(
If you know which developer is responsible for that particular module in which bug
occurred, then you can specify email address of that developer. !lse keep it blank this
will assign bug to module owner or 2anger will assign bug to developer. 4ossibly add
the manager email address in 55 list.
-*5(
The page url on which bug occurred.
,ummary(
) brief summary of the bug mostly in @: or below words. 2ake sure your summary is
reflecting what the problem is and where it is.
6escription(
) detailed description of bug. 8se following fields for description fieldA
*eproduce steps( 5learly mention the steps to reproduce the bug.
3xpected result( ,ow application should behave on above mentioned steps.
4ctual result( %hat is the actual result on running above steps i.e. the bug
behavior.
These are the important steps in bug report. +ou can also add the #Report type$ as one
more field which will describe the bug type.
The report types are typically(
<( 5oding error
9( 0esign error
B( /ew suggestion
C( 0ocumentation issue
=( ,ardware problem
,ome Bonus tips to write a good bug report(
&) *eport the problem immediately(If you found any bug while testing, do not wait to
write detail bug report later. Instead write the bug report immediately. This will ensure a
good and reproducible bug report. If you decide to write the bug report later on then
chances are high to miss the important steps in your report.
)) *eproduce the bug three times before writing bug report(+our bug should be
reproducible. 2ake sure your steps are robust enough to reproduce the bug without any
ambiguity. If your bug is not reproducible every time you can still file a bug mentioning
the periodic nature of the bug.
+) Test the same bug occurrence on other similar module(
Sometimes developer use same code for different similar modules. So chances are high
that bug in one module can occur in other similar modules as well. !ven you can try to
find more severe version of the bug you found.
7) Write a good bug summary(
*ug summary will help developers to -uickly analy1e the bug nature. 4oor -uality report
will unnecessarily increase the development and testing time. 5ommunicate well through
your bug report summary. Deep in mind bug summary is used as a reference to search the
bug in bug inventory.
8) *ead bug report before hitting ,ubmit button(
Read all sentences, wording, steps used in bug report. See if any sentence is creating
ambiguity that can lead to misinterpretation. 2isleading words or sentences should be
avoided in order to have a clear bug report.
9) 6o not use 4busi'e language(
It"s nice that you did a good work and found a bug but do not use this credit for
critici1ing developer or to attack any individual.
"onclusion(
/o doubt that your bug report should be a high -uality document. >ocus on writing good
bug reports, spend some time on this task because this is main communication point
between tester, developer and manager. 2angers should make aware to their team that
writing a good bug report is primary responsibility of any tester. +our efforts towards
writing good bug report will not only save company resources but also create a good
relationship between you and developers.
:or better producti'ity write a better bug report$