A Detailed Tutorial of the Defect Bug Life Cycle in Software Testing
Introduction to Defect Life Cycle
What is defect life cycle in software testing with example? In software testing, finding a defect is just the beginning; reporting it and analyzing it is the journey from discovery to closure. This guide will thoroughly explain the defect journey and its stages, with practical examples and best practices.
What is Defect Life Cycle in Software Testing
The defect life cycle, also called the bug life cycle, and it is related to the bug found during testing.
Defect life cycle is a process where a defect goes through different stages throughout its journey from discovery to closure. The defect lifecycle process starts when a defect is discovered and ends when the defect is closed.
Why the Defect Life Cycle is Important
Defect life cycle is very important in software testing. A structured bug life cycle in software development or in testing provides a consistent way of managing software issues. Some of these points are given below.
- Clear Ownership - The status of each stage indicates who currently holds responsibility.
- Better Communication - There is good and clear communication between testers, developers, and product owners.
- Faster Resolution - High-risk bugs get prioritized by severity, and priority is identified and resolved first.
- Measurable Quality - From this, we get to know about the quality of the software, defect reopened status, at what stage currently it is, what is the average time for fixing it, etc.
- Traceability - History maintains what action was taken on each defect, who took it, etc.
- Reduces Duplicate - If everyone in the team sees the status then there would be less same bug raise.
- Process Improvement - These history and metrics help in identifying weak areas to improve future testing.
Without a defect life cycle, bugs will get lost in chatboxes, emails, etc. Fixes made in software development may remain untested, and the same issues may keep recurring.
Without a defined process, team will spend its time unnecessarily deciding whether the bug is still open or fixed.
The defect life cycle provides a clear, structured workflow to every team member that brings accountability and traceability to the process.
Defect Life Cycle Diagram in Software Testing
The Defect Life Cycle flow diagram below shows how a bug goes through different stages from being New to Closed.
Key Stages of the Defect Life Cycle in Software Testing
There are different stages in the defect life cycle as discussed above also, each stage represents the current status. The name and number of defect status may vary depending on company to company.
A typical defect life cycle looks like this:
New → Assigned → Open → In Progress → Fixed → Retest → Verified → Closed
- New
During the testing phase, if a tester or the testing team discovers a new bug, they log it as "New" in the defect tracking system.
Remember, bugs of this type - when logged for the first time automatically fall into the "New" state. The tester reports the issue with reproducible steps and evidence (screenshots and logs). - Assigned
After reviewing the defect by test lead or development lead, it is assigned to the developer or development team for resolution, its status changes to the "Assigned" stage. - Open
Once a defect is accepted for investigation or fixing, its status becomes "Open".
In many organizations, "Assigned and Open" are used only on them, and in many places, they are used separately. Therefore, testers should always follow the project's documented defect workflow. - In Progress
Now, in this state, the developer analyzes the report and reproduces the problem.
Many teams use the "In Progress" state to indicate that the developer is working on which bug. This status is very effective for teams that want visibility. In this stage developer has 3 options.
- Deferred
If the developer determines that the bug is not of high priority, or that it does not pertain to the current release and can be resolve in next release, they set the status to "Deferred".
The "Deferred" status is also referred to as the "Postponed State". - Duplicate
If the same bug is reported twice or if it is essentially the same issue or concept, such that resolving one instance would effectively eliminate the other or if the bug had been raised previously and subsequently closed, then the developer marks it as "Duplicate" stage. - Rejected
If the developer determines that this is not an genuine bug, or if the bug cannot be reproduced upon analysis, they set its status to "Rejected".
- Deferred
- Fixed
If none of the above conditions are met, then the developer needs to resolve the bug. The developer marks the defect as "Fixed" and completes unit testing and provides the relevant build or version for testing. - Re-testing
This stage is also referred to as "Pending Retest".
The testing team will now begin retesting this bug and mark the stage as "Re-testing". And the testing team tests whether the bug has been truly resolved or not. In this stage tester has 1 option also.
- Re-Open
The tester performs a test, if a bug is detected and has not been resolved, they reopen it. This stage is marked as "Re-open" and the same defect lifecycle resumes, though the "New" stage is skipped in this cycle.
- Re-Open
- Verified
It is also referred to as "Ready to Close".
In this stage, the tester checks whether the bug has been fixed or not, and whether the bug fix not affected other modules(Regression Testing). If everything good, the tester marks this stage as "Verified".
Many organizations keep "Verified and Close" at combined stage. - Closed
This state means that the bug is fixed, tested and approved.
If the bug passes the "Re-testing" and "Verified" stages, then the issue of this bug can now be closed and this stage is marked as "Closed".
Defect Life Cycle Example
Various issues arise while testing an application. To understand how a bug moves through different stages, let us take a look at the process real-life example of bug life cycle.
Scenario: Login Failure on an E-Commerce Site
Let's understand the simple login process on an e-commerce site.
Test Case: The tester entered a valid email and password, but it is still showing "Invalid Credentials". This issue occurs only when the password contains special characters such as &, !, #, etc.
- New - The tester raised a ticket of this defect in the bug tracking tool, including screenshots and steps.
- Assigned - The Test Lead will review the ticket to determine if the bug is genuine or not, and then assign it to the Development Lead or a dedicated developer within the development team.
- Open - Now, the developer will accept the ticket of investigating this bug.
- In Progress - Now, the developer will start investigate this bug and try to reproduce the issue.
- Fixed - The developer has reproduced the bug, and takes the necessary actions to fix it.
- Re-testing - After fixing the issue the developer sends the ticket back to the tester for retesting, the tester verifies whether the bug has been fixed or not using the correct credentials (same credentials).
- Verified - At this stage, the tester also verifies whether the bug fix has caused any unintended changes or issues in other modules.
- Closed - The tester closes the ticket after retesting and verification.
Alternate outcome:
Reopen - If the developer hasn't fixed the issue for all the special characters, the ticket might get reopened in retesting.
Conclusion
The defect life cycle or bug life cycle is a structured process that tracks a bug from discovery to closure moving through stages such as New, Assigned, Open, In Progress, Fixed, Re-testing, Verified and Closed.
It ensures clear ownership, better communication, faster resolution and full traceability. Bugs may also be deferred, rejected, marked duplicate or reopened.
Following a defined workflow prevents lost issues, reduces duplicates, improves software quality and helps teams refine future testing.
Frequently Asked Questions (FAQs)
Who is responsible for closing a defect in the Defect Life Cycle
Generally, the tester who raised the defect (or a QA Lead) is responsible for closing the defect, after retesting the application and verified that the issue has been fixed.
Developers typically do not close their own defects. And in some teams, the Test Manager may also close defects in bulk, but not always.
Can a defect be closed without fixing it
Yes, a defect can be closed without being fixed in scenarios such as:
- If it is a Duplicate
- Rejected it is not actually a bug
- It cannot be reproduced
- Deferred, the fix is scheduled for a later release
- or a feature change renders the fix unnecessary
In all such cases, proper documentation is recorded before closing the defect.
Can a closed defect be reopened
Yes, closed defect can be reopen in some circumstances such as:
- Issue is not actually fixed (incomplete fix)
- Issue reappears in a later build
- Defect was closed by mistake
- Requirement change
What is the difference between Deferred and Rejected
Deferred refers to a valid defect whose fix has been postponed to a later release usually because of low impact or low priority.
Rejected Defect is one that the development team does not accept as valid - reasons for this include the bug not being reproducible or it not aligning with the requirements or is a duplicate defect.
