When
you have completed the execution of the test cases you will come up with
The
result. Report the result to the team lead/project lead /Project manager.
(Note) Do not report a bug to a developer
directly (Until you told to do so)
(Note) If the organization at which you are
working has a bug tracking tool log the bug In the tool
Bug logging/tracking tool: -
A bug tracking tool is used
to log all the bugs build wise/product Wise. It is configured centrally so that
every one can access it through browser with the given privileges. Most of the
bug tracking tools provides a facility of mail configuration and customization
of the fields in it. When a bug is logged or updated the status will be sent to
the TL/PL/PM as configured.
The
process generally goes like this
a) Test engineer logs a bug
in the bug tracking tool
b) A mail will be sent to
the TL/PL/PM (if it is configured)
c) TL/PL/PM will review the
bug and allot it to the corresponding developer
d) Developer fixes the bug
and updates the status in the bug tracking tool. Mail will be sent to the
TL/PL/PM about the updation & to the test engineer (If it is configured)
e)
Test engineer will validates the bug and update the status as one of the
following
New
Open
Close
Reopen
FAD (Function as designed)
DL
(Design limitation)
Duplicate
* Step “e” is called as a bug life cycle.
(Note1) 5&6 points will be updated in the
bug tracker by a developer.
(Note2) If any bug that you have
reported and developer updates its status as Fad or dl, but still you feel it is a bug you can
call for meeting and discuss its impact on the product and explain why you want
to make it as a bug
(Note3) Never report a bug to a developer
directly.
A
bug logging /tracking tool has the following fields (In General):-
a)
Bug id (This is a tool generated number)
b)
Title (Title of the bug)
c) Setup (Give the installation details)
d) Steps to reproduce
(includes expected & actual result)
e) Product
f) Version
g) Build
h) Operating system
i) Bug category
(functional, design, documentation, GUI etc)
j) Bug Severity
(High/major, medium/minor, low/trivial)
k) Status (New, open,
closed, reopen, Fad, DL, duplicate)
l) Comments/notes
m) Attachments
(Note) These fields might be
differing among bug tracking tools.
(Note) You can also customize
fields as per requirements
Note on bug severities:
a) Major/high : System inoperable, causes system to
hang or crash
b) Minor/medium : Incorrect
results or behavior with known reasons
c) Trivial/low : Affects limited areas of
functionality, cosmetic changes ETC
Reasons for software having bugs:-
Following
are the most common reasons for a software application/system/product
Having
bugs in it
a) Software complexity
b) Programming errors
c) In sufficient
application requirements & poor design
d) Time pressures
e) Frequent changes in
requirements
f) Usage of third party
tools & software’s in the product/application/system
