Tag: what is defect life cycle

The Defect Life Cycle, also known as the Bug Life Cycle, is the journey of a defect from its initial discovery to its eventual resolution. This cycle is a key part of defect management or bug tracking in software development and testing. It provides a standardized process for reporting, tracking, and resolving defects.

Here is a typical flow of stages in a Defect Life Cycle:

1. New: When a defect is logged and posted for the first time, its status is marked as new.
2. Assigned: The project manager or the defect triage team reviews the defect and assigns the defect to corresponding developer/team. The status of the defect is changed to assigned.
3. Open: At this stage, the developer begins to analyze and work on the defect fix.
4. Fixed: Once the developer makes necessary code changes and verifies the fix, they mark the defect as fixed and it is passed on to the testing team.
5. Test: At this stage, the tester does the testing to confirm that the defect has been successfully fixed and no additional issues are introduced due to these changes.
6. Reopen: If the defect still exists, the tester reopens the defect. The developer has to fix it again.
7. Verified: The tester re-tests the code. If the defect no longer exists in the software, they mark it as verified.
8. Closed: If the tester feels that the defect no longer exists in the software, they close the defect.
9. Deferred: Sometimes, a defect may not be fixed in the current iteration and can be moved to the next iteration. Reasons may include low defect priority, time constraints, etc. In such cases, status is changed to deferred.
10. Duplicate: If the defect is repeated twice or if the same defect is logged again, then one defect status is changed to ‘duplicate.’
11. Rejected: If the developer feels that the defect is not genuine, they reject the defect. Then the state of the defect is changed to ‘rejected.’
12. Not a bug: If it is determined that the defect is not a bug, then the status is changed to ‘Not a Bug.’

The exact stages can vary depending on the organization, the software development methodology used, the defect tracking tool, and other factors.