In software development, the defect life cycle also known as bug lifecycle is the set of steps that a bug goes through from detection to closing it off. But what is a defect? Defect/ Fault/ Bug is a flaw or missing feature in software which causes it to produce incorrect results.
While we have a preexisting lifecycle that a defect should follow, it is important to note that
- The Defect Lifecycle varies from one organization to another. This is influenced by testing tools and testing methods that different teams use.
- The number of states that a defect follows is not static. It is also influenced by different tools and processes used.
- A defect lifecycle aims at easy coordination and communication on the current status of the defect and help in making the defect-fixing process efficient.
Defect Lifecycle Process
Defect lifecycle can be time consuming and resource intensive. However, early issue detection, improved communication and enhanced customer satisfaction outweigh the challenges. With a comprehensive defect lifecycle development, teams can;
- Reduce costs
- Improve ROI
- Deliver reliable, user friendly software
New
Any new defects identified by a tester automatically fall into the New state. It is important for testers to provide a proper defect document so the dev team can refer and fix the bug accordingly.
On this state, something important happens - bug triage meeting. This is a cross-functional team meeting where newly reported software defects are reviewed.
This meeting aims at
- Validating defects
- Assigning severity
- Assigning priority levels
- Decide which issues to fix immediately or defer.
Deferred
This state is dependent on the outcome of the bug triage meeting. Bugs with lower priority/ to be fixed later are assigned this state. Deferred defects are usually revisited in future releases.
Assigned
Once the bug/ defect has passed the New state and is approved for fix, it gets assigned to a developer.
Open
This state means that a valid bug is accepted for fix and waiting for action or analysis. Bug is approved, active and queued up in the backlog, but hands-on fixing has not necessarily started.
In this stage, one important thing happens;
If the bug is
- Not reproducible
- Not a bug
- This would happen if wrong test data was used.
- Duplicate the developer closes the bug moving it to Rejected then Closed state.
In-Progress
In this state, a developer is actively coding or troubleshooting a fix.
Depending on the team's preference for workflow simplicity, either the 'Open' or 'In Progress' status is often omitted to reduce tracking overhead.
Fixed
When the developer has made the necessary code changes or fixes on the identified bug, it is moved to Fixed state.
Pending Retest
When the developer finishes the fix, they move it to the test team for retesting. If the testers have not started working on it, the status is assigned as Pending Retest
Retest
At this stage the tester performs a confirmation test to verify the fix.
Two important decisions happen here. If the tester finds the bug even after the fix, bug moves to Reopen. Otherwise, it is moved to Verified state
Verified
The tester retested the bug after the developer fixed it and did not find any bug.
Reopened
After retesting/ confirmation testing, and the tester still finds the bug, even after the developer fixed it, the bug status changes to Reopened. From here the bug will go back to Open state and pass through the lifecycle again.
Closed
This is the last step of the defect lifecycle. If a bug has been fixed and a confirmation test is done; and it passes, the bug moved to Closed state.
Also remember that bugs closed as a duplicate or not considered as a bug also get assigned this state.
Top comments (0)