DEFECT LIFE CYCLE, also known as Bug Life Cycle, is the journey of a defect from its identification to its closure. The life cycle varies from organization to organization and is governed by the software testing process the organization or project follows and / or the Defect Tracking tool being used.
Statuses
During the life cycle of a defect, it can have the following statuses:
| Status | Alternate Status |
| OPEN | NEW |
| ASSIGNED | |
| DUPLICATE | |
| DROPPED | REJECTED |
| DEFERRED | |
| FIXED | COMPLETED / RESOLVED |
| REASSIGNED | |
| CLOSED | VERIFIED |
Elaboration
- OPEN / NEW: Defect is identified via a review or a test and reported. This is the beginning of a defect’s journey.
- ASSIGNED: The defect is assigned to a person who is tasked with its analysis or resolution.
- DUPLICATE: If the defect is invalid because it’s a duplicate of another one already reported, it is marked as a duplicate.
- DROPPED / REJECTED: If the defect is invalid because of various other reasons like false positives, it is dropped / rejected.
- DEFERRED: If the defect is valid but it’s decided to be fixed in a future release instead of the current release, it is deferred. When the time comes, the defect is assigned again.
- FIXED / RESOLVED / COMPLETED: After the defect is ‘fixed’, its status is changed so that its verification can begin. If the defect can’t be fixed, it could be because of any of the following reasons:
- Need More Information: More information, such as the exact steps to reproduce, is required to analyze and fix the defect.
- Can’t Reproduce: The defect cannot be reproduced for reasons such as change of environment or the defect somehow being already fixed.
- Can’t Fix: The defect cannot be fixed due to some other reason. Such defect is either assigned to another person (in the hope that the other person will be able to fix it), deferred (in the hope that the delay in fixing won’t hurt much), or dropped (when there’s no hope for its resolution ever and the defect needs to be considered as a ‘known issue’)
- REASSIGNED: If the ‘fixed’ defect is, in fact, verified as not being resolved at all or being only partially resolved, it is reassigned. If there’s time to fix the reassigned defect in the current release, it is fixed again but if it’s decided to wait and fix in a future release, it is deferred.
- CLOSED / VERIFIED: If the defect is verified as being resolved indeed, it is closed. This is the happy ending. Hurray!
Guidelines
- Make sure the defect life cycle to be used in your project is well-documented and the entire team understands what each defect status exactly means.
- Ensure that each member of the team is clearly aware of his / her responsibility as regards each defect and its current status.
- Ensure that enough detail is entered in each status change. For example, do not simply drop a defect but provide a plausible reason for doing so.
- Make sure the status of the defect in the defect tracking tool reflects the actual status. For example, do not be ask for verification without changing the defect’s status to FIXED.
.
What next?
Learn how to REPORT DEFECTS EFFECTIVELY.
.
Last Updated on September 10, 2020 by STF