c
 



   

Posted In | Bug Defect tracking, How to be a good tester, Software Testing Templates

  
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.

  


 
  
  !" 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. 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..)

#   


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

$c% 

&
Always assign a unique number to each bug report. This will help 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.

'( 
&
If your bug is not reproducible 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.

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

c
 ( 

+ 
 &

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 Bug number
which should be assigned manually.
( & Your name and email address.

, & In which product you found this bug.

- & The product version if any.

 & These are the major sub modules of the product.

, & Mention the hardware platform where you found this bug. The various platforms like
µPC¶, µMAC¶, µHP¶, µSun¶ etc.

.& Mention all 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 bug should 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.
 *%&

ëÊ  & No further testing work can be done.

ëÊ & Application crash, Loss of data.
ëÊ / & Major loss of function.
ëÊ  & minor loss of function.
ëÊ %& Some UI enhancements.
ëÊ 4&Request for new feature or some enhancement in existing one.

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

0 &
If you know which developer is responsible for that particular module in which bug occurred,
then you can specify email address of that developer. Else keep it blank this will assign bug to
module owner or Manger will assign bug to developer. Possibly add the manager email address
in CC list.

+(1&
The page url on which bug occurred.
*&
A brief summary of the bug mostly in 60 or below words. Make sure your summary is reflecting
what the problem is and where it is.

2 &
A detailed description of bug. Use following fields for description field:

ëÊ ( & Clearly mention the steps to reproduce the bug.

ëÊ 4 & How application should behave on above mentioned steps.
ëÊ 0& What is the actual result on running above steps i.e. the bug behavior.

These are the important steps in bug report. You can also add the ³Report type´ as one more
field which will describe the bug type.

 &

1) Coding error
2) Design error
3) New suggestion
4) Documentation issue
5) Hardware problem

*   
 

 &

$( 
 &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.

'( 

 

 &Your bug should be
reproducible. Make 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.

)
    &
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. Even you can try to find more severe
version of the bug you found.

3 
&
Bug summary will help developers to quickly analyze the bug nature. Poor quality report will
unnecessarily increase the development and testing time. Communicate well through your bug
report summary. Keep in mind bug summary is used as a reference to search the bug in bug
inventory.

4( 
 
 *

 &
Read all sentences, wording, steps used in bug report. See if any sentence is creating ambiguity
that can lead to misinterpretation. Misleading words or sentences should be avoided in order to
have a clear bug report.

X2  0
%&
It¶s nice that you did a good work and found a bug but do not use this credit for criticizing
developer or to attack any individual.

 &
No doubt that your bug report should be a high quality document. Focus on writing good bug
reports, spend some time on this task because this is main communication point between tester,
developer and manager. Mangers should make aware to their team that writing a good bug report
is primary responsibility of any tester. Your efforts towards writing good bug report will not only
save company resources but also create a good relationship between you and developers.