What Is Defect/Bug Life Cycle In Software Testing?

Defect Life Cycle Tutorial

Last Updated:August 7, 2022

Introduction to the Defect Life Cycle

In this tutorial, we will talk about the life cycle of a defect to make you aware of the various stages of
a defect which a tester has to deal with while working in a testing environment.

We have also added the most frequently asked interview questions on Defect Life Cycle. It is
important to know about the various states of a defect in order to understand the life cycle of a defect.
The main intention of performing a testing activity is to check if the product has any issues/errors.
In terms of real scenarios, errors/mistakes/faults are all referred to as bugs/defects and hence we can
say that the main objective of doing testing is to ensure that the product is less prone to defects (no
defects is an unrealistic situation).

Now, the question arises as to what a defect is?

What You Will Learn: [hide]

 What Is A Defect?
 Defect Life Cycle in Detail
o Defect Workflow
o Defect States
o Guidelines for Implementing a Defect Life Cycle
o Frequently Asked Questions
 Additional Information on Defect or Bug
o States of Defect
o Invalid and Duplicate Defect Report
o Defect Data
o Process Capability
 Conclusion
o Recommended Reading

What Is A Defect?
A Defect, in simple terms, is a flaw or an error in an application that is restricting the normal flow of
an application by mismatching the expected behavior of an application with the actual one.

The defect occurs when any mistake is made by a developer during the designing or building of an
application and when this flaw is found by a tester, it is termed as a defect.

It is the responsibility of a tester to do thorough testing of an application to find as many defects as

possible to ensure that a quality product will reach the customer. It is important to understand the
defect life cycle before moving to the workflow and different states of the defect.

Hence, let’s talk more about the Defect Life Cycle.

So far, we have discussed the meaning of defect and its relation in context to the testing activity.
Now, let’s move to the defect life cycle and understand the workflow of a defect and the different
states of a defect.

Defect Life Cycle In Detail

The Defect Life Cycle, also known as the Bug Life Cycle, is a cycle of defects from which it goes
through covering the different states in its entire life. This starts as soon as any new defect is found
by a tester and comes to an end when a tester closes that defect assuring that it won’t get reproduced
again.

Defect Workflow
It is now time to understand the actual workflow of a Defect Life Cycle with the help of a simple
diagram as shown below.

Defect States
#1) New: This is the first state of a defect in the Defect Life Cycle. When any new defect is found, it
falls in a ‘New’ state, and validations & testing are performed on this defect in the later stages of the
Defect Life Cycle.
#2) Assigned: In this stage, a newly created defect is assigned to the development team to work on
the defect. This is assigned by the project lead or the manager of the testing team to a developer.
#3) Open: Here, the developer starts the process of analyzing the defect and works on fixing it, if
required.
If the developer feels that the defect is not appropriate then it may get transferred to any of the below
four states namely Duplicate, Deferred, Rejected, or Not a Bug-based upon a specific reason. We
will discuss these four states in a while.
#4) Fixed: When the developer finishes the task of fixing a defect by making the required changes
then he can mark the status of the defect as “Fixed”.
#5) Pending Retest: After fixing the defect, the developer assigns the defect to the tester to retest the
defect at their end, and until the tester works on retesting the defect, the state of the defect remains in
“Pending Retest”.
#6) Retest: At this point, the tester starts the task of retesting the defect to verify if the defect is fixed
accurately by the developer as per the requirements or not.
#7) Reopen: If any issue persists in the defect, then it will be assigned to the developer again for
testing and the status of the defect gets changed to ‘Reopen’.
#8) Verified: If the tester does not find any issue in the defect after being assigned to the developer
for retesting and he feels that if the defect has been fixed accurately then the status of the defect gets
assigned to ‘Verified’.
#9) Closed: When the defect does not exist any longer, then the tester changes the status of the defect
to “Closed”.
A Few More:
 Rejected: If the defect is not considered a genuine defect by the developer then it is
marked as “Rejected” by the developer.
 Duplicate: If the developer finds the defect as same as any other defect or if the
concept of the defect matches any other defect then the status of the defect is changed
to ‘Duplicate’ by the developer.
 Deferred: If the developer feels that the defect is not of very important priority and it
can get fixed in the next releases or so in such a case, he can change the status of the
defect as ‘Deferred’.
 Not a Bug: If the defect does not have an impact on the functionality of the
application, then the status of the defect gets changed to “Not a Bug”.
The mandatory fields where a tester logs any new bug are Build version, Submit On, Product,
Module, Severity, Synopsis and Description to Reproduce
In the above list, you can add some optional fields if you are using a manual Bug submission
template. These Optional Fields include Customer name, Browser, Operating system, File
Attachments, and screenshots.
The following fields remain either specified or blank:
If you have the authority to add bug Status, Priority, and ‘Assigned to’ fields then you can specify
these fields. Otherwise, the Test Manager will set the status and Bug priority and assign the bug to
the respective module owner.

Look at the following Defect cycle

The above image is quite detailed and when you consider the significant steps in Bug Life Cycle you
will get a quick idea about it.

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

AD

When a bug gets assigned to a developer, he/she can start working on it. The developer can set the
bug status as won’t fix, Couldn’t reproduce, Need more information, or ‘Fixed’.

If the bug status set by the developer is either “Need more info” or “Fixed” then the QA responds
with a specific action. If the bug is fixed then the QA verifies the bug and can set the bug status as
verified closed or Reopen.
Guidelines for Implementing a Defect Life Cycle
Some important guidelines can be adopted before starting to work with the Defect Life Cycle.

They are as follows:

 It is very important that before starting to work on the Defect Life Cycle, the whole
team clearly understands the different states of a defect (discussed above).
 Defect Life Cycle should be properly documented to avoid any confusion in the
future.
 Make sure that each individual who has been assigned any task related to the Defect
Life Cycle should understand his/her responsibility very clearly for better results.
 Each individual who is changing the status of a defect should be properly aware of
that status and should provide enough details about the status and the reason for
putting that status so that everyone who is working on that particular defect can
understand the reason of such a status of a defect very easily.
 The defect tracking tool should be handled with care to maintain consistency among
the defects and thus, in the workflow of the Defect Life Cycle.
Next, let’s discuss the interview questions based on the Defect Life Cycle.

Frequently Asked Questions

Q #1) What is a defect in the perspective of Software Testing?
Answer: A defect is any kind of flaw or error in the application that is restricting the normal flow of
an application by mismatching the expected behavior of an application with the actual one.
Q #2) What is the major difference between Error, Defect, and Failure?
Answer:
Error: If the developers find that there is a mismatch in the actual and expected behavior of an
application in the development phase then they call it an Error.
Defect: If testers find a mismatch in the actual and expected behavior of an application in the testing
phase then they call it a Defect.
Failure: If customers or end-users find a mismatch in the actual and expected behavior of an
application in the production phase then they call it a Failure.
Q #3) What is the status of a defect when it is initially found?
Answer: When a new defect is found, it is in a new state. This is the initial state of a newly found
defect.
Q #4) What are the different states of a defect in the defect life cycle when a defect is approved
and fixed by a developer?
Answer: Different states of a defect, in this case, are New, Assigned, Open, Fixed, Pending Retest,
Retest, Verified, and Closed.
Q #5) What happens if a tester still finds an issue in the defect that is fixed by a developer?
Answer: The tester can mark the state of the defect as . Reopen if he still finds an issue with the
fixed defect and the defect gets assigned to a developer for retesting.
Q #6) What is a producible defect?
Answer: A defect that is occurring repeatedly in every execution and whose steps can be captured in
every execution, then such a defect is called a “producible” defect.
Q #7) What type of defect is a non-reproductible defect?
Answer: A defect that is not occurring repeatedly in every execution and is producing only at some
instances and whose steps as proof have to be captured with the help of screenshots, then such a
defect is called as a no reproducible.
 Q #8) What is a defect report?
Answer: A defect report is a document that includes reporting information about the defect or flaw
in the application which is causing the normal flow of an application to deviate from its expected
behavior.
Q #9) What details are included in the defect report?
Answer: A defect report consists of Defect ID, Description of the defect, Feature Name, Test Case
Name, Reproducible defect or not, Status of the defect, Severity, and Priority of the defect, Tester
Name, Date of testing of the defect, Build Version in which the defect was found, the Developer to
whom the defect has been assigned, name of the person who has fixed the defect, Screenshots of a
defect depicting the flow of the steps, Fixing the date of a defect, and the person who has approved
the defect.
Q #10) When is a defect changed to a ‘deferred’ state in the defect life cycle?
Answer: When a defect that is found is not of very high importance and the one which can get fixed
in the later releases are moved to a ‘deferred’ state in the Defect Life Cycle.

Additional Information On Defect Or Bug

 A defect can be introduced at any point in the Software Development Life Cycle.
 Earlier, the Defect is detected and removed, the lower the overall cost of quality will
be.
 The cost of quality is minimized when the defect is removed in the same phase in
which it was introduced.
 Static testing finds the defect, not a failure. The cost is minimized as debugging is not
involved.
 In Dynamic testing, the presence of a defect is revealed when it causes a failure.
States of Defect
S.No
Initial State Returned State Confirmation State
.

1 Gather information for person responsible Defect is Rejected or asked for Defect is Fixed and should be
for reproducing the Defect more information tested and closed

2 States are Open or New States are Rejected or States are Resolved and
Clarification. Verification.

Invalid and Duplicate Defect Report

 Sometimes defects occur, not because of code but because of test environment or
misunderstanding, such a report should be closed as an Invalid defect.
 In the case of Duplicate Report, one is kept and one is closed as a duplicate. Some
invalid reports are accepted by the Manager.
  The Test Manager owns the overall Defect Management & process and the Defect
Management tool cross-functional team is generally responsible for managing the
reports.
 Participants include Test Managers, Developers, PMs, Production Managers, and
other stakeholders who are interested.
 The Defect Management committee should determine the validity of each defect and
determine when to fix or defer. To determine this, consider the cost, risks, and
benefits of not fixing any defect.
 If the defect has to be fixed, then its priority has to be determined.
Defect Data
 Name of the Person
 Types of Testing
 Problem Summary
 Detailed Description of Defect.
 Steps to Reproduce
 Life Cycle Phase
 Work product where Defect was introduced.
 Severity and Priority
 Subsystem or Component where the Defect is introduced.
 Project Activity occurring when the Defect is introduced.
 Identification Method
 Type of Defect
 Projects and Products in which problems exist
 Current Owner
 Current State of the Report
 Work product where Defect occurred.
 Impact on Project
 Risk, loss, opportunity, and benefits associated with fixing or not fixing the defect.
 Dates when various defect lifecycle phases occur.
 Description of how the defect was resolved and recommendations for testing.
 References
Process Capability
 Introduction, Detection, and Removal info -> Improve Defect detection and Cost of
Quality.
 Introduction -> Praetor analysis of the process in which the largest number of defects
is introduced to reduce the total number of defects.
 Defect Root info -> find underline reasons for the defect to reduce the total number of
defects.
 Defect Component info -> Perform Defect Cluster Analysis.