Software Testing Experience

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.

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

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.

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.

Look at the following Bug life cycle:

[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.

On successful logging the bug is reviewed by Development or Test manager.
Test manager can set the bug status as Open, can Assign the bug to developer or
bug may be deferred until next release.

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.

1) New: When QA files new bug.

2) Deferred: If the bug is not related to current build or
can not 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.

Labels: Manual Testing