Defect Life Cycle Management
~By Ritesh Mittal
Defect Lifecycle Management refers to the process of identifying,
tracking, and resolving defects (bugs or issues) in a software application
from the moment they are discovered until they are resolved and closed.
❖ Effective defect lifecycle management ensures that all defects are
addressed systematically and efficiently, improving software quality
and development productivity.
❖ It is a critical process in software quality assurance that involves
tracking and managing the lifecycle of a defect (bug) from its discovery
to its resolution and eventual closure.
❖ Managing defects effectively ensures that issues are properly
addressed, quality is maintained, and development timelines are met.
❖ The defect lifecycle (also known as Bug Life Cycle) consists of several
stages, each of which represents a distinct phase in the defect
resolution process.
New (or Open)
Definition: When a defect is first identified and reported, it
enters the "New" or "Open" state.
Action: A defect is logged by the tester (or user) in a defect
tracking system. At this stage, the defect has not been
reviewed, verified, or assigned yet.
Criteria: The defect needs to be reviewed by the team to
determine its validity.
For Example: A tester reports that clicking the "Submit"
button on a form causes the page to crash.
Assigned
Definition: After the defect has been reviewed and
deemed valid, it is assigned to a developer or team
member who will be responsible for fixing it.
Action: The defect is assigned to a developer who
investigates and starts working on the fix.
Criteria: The developer assesses the defect and
determines the cause.
For Example: The defect related to the "Submit" button is
assigned to a developer who investigates the issue and
identifies a coding error in the form validation logic.
Open / In Progress
Definition: This is the active stage where the developer is
working on resolving the defect.
Action: The developer makes the necessary code changes,
adjusts configurations, or reworks the feature to fix the
issue. The defect is actively being worked on.
Criteria: The issue is being actively investigated and
addressed.
For Example: The developer begins to fix the issue with the
form submission by correcting the validation logic in the
backend.
Fixed / Resolve
Definition: After the defect has been worked on and fixed,
the developer marks the defect as "Fixed" or "Resolved.“
Action: The defect is considered resolved, but it has not
yet been verified. The fix is ready for testing to ensure that
the issue is corrected.
Criteria: The developer believes the issue has been fixed,
but it still needs to be tested to ensure it works correctly.
For Example: The developer corrects the validation issue
and submits the fix to be tested.
Fig. Defect (or Bug) Life Cycle
Retested
Definition: After the defect is marked as fixed, it is passed
back to the QA (Quality Assurance) team or tester for
verification and retesting.
Action: The QA team retests the application to ensure that the
defect has been fixed and that the solution does not introduce
new issues. This may involve regression testing as well.
Criteria: The defect is retested to verify that it has been
resolved and that the fix does not break other functionalities.
For Example: The QA team tests the form again to confirm
that the "Submit" button works as expected and no new
issues have been introduced.
Closed
Definition: Once the defect has been verified and
confirmed to be fixed, the defect is marked as "Closed.“
Action: The defect is considered resolved, and no further
action is needed. It is closed in the defect tracking
system.
Criteria: The defect passes testing and verification, and
the fix is confirmed to work.
For Example: The QA team confirms that the "Submit"
button works, and no new issues have been found, so the
defect is closed.
Rejected
Definition: Sometimes, defects are rejected if they are found
to be invalid or not reproducible. This could be because the
issue was not a defect in the code, the reported issue is due to
user error, or the defect does not align with the product’s
requirements.
Action: The defect is rejected, and the status is updated to
reflect this decision.
Criteria: The defect does not meet the criteria for being
considered a valid issue.
For Example: A tester reports that the "Submit" button is not
working, but after review, it turns out the user didn’t enter the
required data, so the issue is rejected.
Deferred
Definition: In some cases, a defect may be marked as
"Deferred." This means the defect is acknowledged but is
postponed for a future release. This often happens when the
defect is not critical and does not need to be fixed in the
current iteration or release cycle.
Action: The defect is postponed but is tracked for future
resolution.
Criteria: The defect is acknowledged but is not prioritized to
be fixed in the current release.
For Example: A low-priority cosmetic issue with the UI is
identified but is deferred for a future release because the
team is focused on critical functionality.
Duplicate
Definition: A defect is marked as a "Duplicate" if it is found to
be the same as a previously reported defect. Instead of
keeping both records, the new defect is closed and linked to
the original one.
Action: The duplicate defect is closed, and the original defect
is kept open for resolution.
Criteria: The new defect is identical to one already reported.
For Example: If two testers report the same issue with the
"Submit" button, the second defect is marked as a duplicate
and linked to the first one.
Example of a Defect Lifecycle
1. New: A tester logs a defect stating that the "Submit" button on a registration
form does not work. The tester has encountered this issue after filling out all
the required fields and clicking "Submit.“
2. Assigned: The product owner reviews the defect and assigns it to a
developer to investigate.
3. In Progress: The developer checks the code for the "Submit" button and
discovers that the form’s validation logic is not correctly triggering the
submission process when all fields are filled. The developer starts working on
fixing the validation logic.
4. Fixed: After correcting the validation logic, the developer tests the fix locally
and marks the defect as "Fixed." The defect is now ready for QA testing.
5. Retested: The QA team tests the form again and verifies that the "Submit"
button now functions correctly, submitting the form and displaying the
confirmation message. No new issues are found.
6. Closed: The QA team confirms that the defect has been resolved, and the
defect is marked as "Closed.“
7. Rejected (if applicable): If the defect had been caused by the user
misunderstanding how to use the form (e.g., missing required data), it might
have been rejected as invalid.
8. Deferred (if applicable): If a non-critical visual defect was found (e.g., text
alignment issues on the "Submit" button), it could have been deferred to the
next release.
9. Duplicate (if applicable): If another tester had already reported the same
issue with the "Submit" button, the new defect would have been marked as a
duplicate and linked to the original.
Benefits of Defect Lifecycle Management
❖ Improved Software Quality: Ensures that defects are tracked,
fixed, and tested thoroughly, leading to higher-quality software.
❖ Efficient Use of Resources: By managing defects in a
structured way, teams can prioritize critical issues and allocate
resources effectively.
❖ Clear Communication: Each stage of the defect lifecycle
provides clear visibility into the status of defects, improving
communication between developers, testers, and other
stakeholders.
❖ Better Planning and Predictability: Effective defect
management allows teams to estimate timelines more
accurately, track progress, and plan for upcoming releases or
sprints.
Key Tools for Defect Lifecycle Management
Defect lifecycle management is typically done using defect
tracking tools. These tools help to log, track, and manage defects
through each stage of the lifecycle. Some popular tools include:
❖ JIRA: A popular tool for issue tracking and project management
in Agile environments.
❖ Bugzilla: An open-source defect tracking tool.
❖ Trello: Used for managing tasks, including defects, in an Agile
board format.
❖ Quality Center (QC): An enterprise-level quality management
tool by Micro Focus.
