What is Bug/Defect?
Simple Wikipedia definition of Bug is: “A computer bug is an error, flaw, mistake, failure, or fault in
a computer program that prevents it from working correctly or produces an
incorrect result. Bugs arise from mistakes and errors, made by people, in
either a program’s source code or its design.”
Other definitions can be:
An unwanted and unintended property of a program or piece of hardware, especially one that causes it to malfunction.
An unwanted and unintended property of a program or piece of hardware, especially one that causes it to malfunction.
or
A fault in a program, which causes the program to perform in an unintended or unanticipated manner.
Lastly the general definition of bug is: “failure to conform to specifications”.
If you want to detect and resolve the
defect in early development stage, defect tracking and software development
phases should start simultaneously.
We will discuss more on Writing effective
bug report in another article. Let’s concentrate here on bug/defect life cycle.
Life cycle of Bug:
1) Log new defect
When tester logs any new bug the mandatory fields are:
Build version, Submit On, Product, Module, Severity, Synopsis and Description to Reproduce
When tester logs any new bug the mandatory fields are:
Build version, Submit On, Product, Module, Severity, Synopsis and Description to Reproduce
In above list you can add some optional fields if you are using manual Bug submission
template:
These Optional Fields are: Customer name, Browser, Operating system, File Attachments or screenshots.
These Optional Fields are: Customer name, Browser, Operating system, File Attachments or screenshots.
The following fields remain either specified or blank:
If you have authority to add bug Status, Priority and ‘Assigned to’ fields them you can specify these fields. Otherwise Test manager will set status, Bug priority and assign the bug to respective module owner.
If you have authority to add bug Status, Priority and ‘Assigned to’ fields them you can specify these fields. Otherwise Test manager will set status, Bug priority and assign the bug to respective module owner.
[Click on the image to view full size]
Ref: Bugzilla bug life cycle
The figure is quite complicated but when
you consider the significant steps in bug life cycle you will get quick idea of
bug life.
When bug gets assigned to developer and
can start working on it. Developer can set bug status as won’t fix, Couldn’t
reproduce, Need more information or ‘Fixed’.
If the bug status set by developer is
either ‘Need more info’ or Fixed then QA responds with specific action. If bug
is fixed then QA verifies the bug and can set the bug status as verified closed
or Reopen.
Bug status description:
These are various stages of bug life cycle. The status caption may vary depending on the bug tracking system you are using.
These are various stages of bug life cycle. The status caption may vary depending on the bug tracking system you are using.
1) New: When QA files new bug.
2) Deferred: If the bug is not related to
current build or cannot be fixed in this release or bug is not important to fix
immediately then the project manager can set the bug status as deferred.
3) Assigned: ‘Assigned to’ field is set by
project lead or manager and assigns bug to developer.
4) Resolved/Fixed: When developer makes necessary code changes and verifies the
changes then he/she can make bug status as ‘Fixed’ and the bug is passed to
testing team.
5) Could not reproduce: If developer is not able to reproduce the bug by the steps given
in bug report by QA then developer can mark the bug as ‘CNR’. QA needs action
to check if bug is reproduced and can assign to developer with detailed
reproducing steps.
6) Need more information: If developer is not clear about the bug reproduce steps provided
by QA to reproduce the bug, then he/she can mark it as “Need more information’.
In this case QA needs to add detailed reproducing steps and assign bug back to
dev for fix.
7) Reopen: If QA is not satisfy with the
fix and if bug is still reproducible even after fix then QA can mark it as
‘Reopen’ so that developer can take appropriate action.
8) Closed: If bug is verified by the QA
team and if the fix is ok and problem is solved then QA can mark bug as
‘Closed’.
9) Rejected/Invalid: Some times developer or team lead can mark the bug as Rejected
or invalid if the system is working according to specifications and bug is just
due to some misinterpretation.