This presentation provides the details about Defect Life Cycle in Software Testing.

1. By Shilpi M Bhalla
Software Testing
Defect Life Cycle

2. Is Defect Life Cycle and Bug Life Cycle
same??
Defect and bug are the words used interchangeable though they differ minutely
in their meaning.
A defect is caused by coding error. Whereas a bug is the result of requirement
deviation. For a QA both are the errors in the software.
Thus Defect Life Cycle and Bug Life Cycle denotes the same thing.

3. What is Defect Life Cycle?
There is a systematic process for dealing with defects found in a software.
Defects change various states from its origin to its closure, and are taken care
by various teams.
Defect Life Cycle represent the flow of bug from one state to another. How a
bug changes various status from its origin to its closure is denoted in Defect
Life Cycle.
Note: The status used may differ from organization to organization but basic
flow will remain same.

4. Defect Life Cycle
The various status are depicted in the diagram ahead on the next slide.
In the diagram some colours have been used,
Green colour has been used to denote that the bug is with QA team
Orange colour signify that the bug is with development team
Yellow colour indicate that the bug is with product management group
And Red colour represents the final state of all bugs

5. Defect Life Cycle

6. About various Status
New
When a bug is created it is assigned the status New. Generally a bug is created by the QA team
member. However, in many organizations, even other members involved in the project can create a
bug (as in developers, managers, writers, stake holders)
Open
The bug with New status is reviewed by the QC Team Lead/ Manager and once approved that the bug
is genuine its status is changed to Open. The bug is now assigned to Dev Lead/ Manager.
Note: In many organizations instead of two status New and Open just one status is used, and the QC
team member directly assigns the bug to development Lead or team member in consultation with the
QC Lead.
Assigned
The Dev Lead/Manager assigns the bug to a particular developer to address it. Bug status now is
changed from Open to Assigned.

7. About various Status (cont..)
A bug may be assigned to a development team member directly by a QC lead if they are aware of the
modules handled by individual dev members or in case of generic bugs.
Resolved
This bug status is used to denote that the bug is fixed by the development team and is ready to be
verified by the QC team.
Not a bug/ Rejected
If a developer is of the opinion that the bug is a desired functionality and not any fault in the software
he marks the status as “Not a bug”. To fight against their point, both dev and qa need to prove their
point with reference of requirement specifications.
Need More Info
If a developer is not clear with the bug and needs any further information on it from QA member he
may mark the bug as Need More Info. He may ask for information relating to steps to reproduce,
environment specific, hardware specific, browser specific or any other particular detail.

8. About various Status (cont..)
Duplicate
If there already exist a similar bug in the bug tracking tool the bug can be marked as Duplicate by the
development team. QA team will verify the details with the existing bug, and if found similar, the bug
can be Closed else Reopened.
Hold
A developer can put the bug on hold if he cannot proceed further with it due to some dependency.
However Hold status does not indicate that the bug will be fixed in the next release, these bugs are to
be resolved in the current release only.
Deferred
Deferred status indicates that the bug will not be fixed now and will be taken care in the next release.
Deferred bugs are reviewed by the Project Management Group and decided for the next release
version. Deferred bugs are marked back as Assigned in the release they are to be delivered in.

9. About various Status (cont..)
Reopen
If during testing qa still find the application faulty they change the status as Reopen. Or we say the bug
is still reproducible by QA.
● QA can reopen Resolved bug if its still reproducible.
● They may reopen Not a Bug bug if they feel its a genuine bug and should not have been
rejected. This needs to be assisted with supporting facts.
● QA reopens Need More Info bug as they provide the required relevant information for developer
to address.
● QA may reopen Duplicate bug if they find that the two bugs are addressing different issues.
Closed
Every bug should finally reach this status. If a bug is verified by qa and qa agrees to the solution they
mark the status as Closed. All bugs should finally be closed after QA verification.

10. Thank You