Defect life cycle or bug life cycle refers to the stages that the defect goes through from its beginning to end. It starts from the time a bug is created / logged. It ends after the bug is closed. A defect life cycle starts at the time of testing when bugs are found by the testing team.
At this point, it is important to remember that the bug life cycle varies across organizations depending on the testing process followed within the organization and/or the defect tracking software used by the organization.
The life cycle of a defect through the various states is explained below.
- New: During the testing phase, when a tester finds a bug, he/she posts it in bug tracking tool and the status of the bug is set to “New” by the testing team.
- Assigned: After a bug is reported by the tester, the test lead verifies whether the bug is genuine or not. This is usually necessary if the tester is inexperienced. This is done to avoid spamming the development team with invalid defects. After confirming the bug is genuine, the test lead changes the status to “Assigned” and assigns the defect to the development lead or the developer.
- Open: If the defect is valid, the developer or the development lead analyzes the bug and works on a solution to fix the defect. The developer or development lead changes the status of the bug to “Open”. In some special circumstances, the development team may choose to ship the product with Open defects.
- Rejected: During the analysis phase, if the development lead finds the bug to be invalid or not genuine, the defect is rejected and the status is updated to “Rejected” by the developer or the development lead. Though a bug is rejected, it is not deleted since it contributes to quality metrics which can be used to gauge the effectiveness of the testing team.
- Deferred: This status is used if the developer or the development lead finds the bug reported by the testing team to be genuine, but decides to push the bug fix to a future release date. The status of the defect is updated to “Deferred” by the development lead and this is informed to the testing lead.
- Duplicate: If the issue reported by the tester has already been reported earlier or if it refers to the same situation mentioned in another defect, the development lead after analyzing it can change the status to “Duplicate”
- Not A Defect: If the defect raised does not impact the functionality of the application and the development team feels the defect is not significant (Example: Some cosmetic issue), they can set the state as Not A Defect.
- Fixed: The developer updates the status of the defect to “Fixed” after they have fixed the defect and tested it to verify that it has been fixed. They then assign it to the testing team.
- Verified: Once the testing team has checked the bug and ensured that the defect is fixed, then the testers change the status of the defect to “Verified”.
- Reopened: During the testing stage, if the testing team finds the defect is still not fixed, they will change the status of the bug to “Reopened” and will assign it back to the developer or development lead for fixing.
- Closed: A bug that is verified by the testing team is closed by the testing lead when it is confirmed that the bug no longer exists in the software. The status of the bug is updated to “Closed”.
The following diagram will help you to understand how the statuses are assigned to bugs.
These are the different states the defect or bug life cycle goes through from the time it is found till it no longer exists and is closed.