What We Are Learn On This Post
Defect / Bug Life Cycle: Defect life cycle or Bug life cycle is the process of the report and resolve the bug and to track the status. The goal of the defect life cycle or bug life cycle is to resolve and test the bug or defect and follow the process until a defect or bug exists. The defect/bug can be raised at any point during testing and could be reported to the relevant development team to fix it. The defect carries its lifetime until status becomes closed.
Phases Of Defect Life Cycle
- New
- Assigned
- Open
- Resolved
- Retest
- Closed
- Reopened
- Duplicate
- Rejected
- Deferred
Read Also: Operational Readiness Test
Bug Life Cycle In Jira
- New: When any defect or bug is found and validated, the status of but or defect is logged in as New.
- Assigned: Once a bug or defect is raised and considered as valid, the raised defect or bug is assigned to the relevant team or developer to resolve, and the status marked as Assigned.
- Open: Once a bug or defect is assigned to developers, they start analyzing, and the status of the bug or defect is marked as Open. Bug fixing gets started in this phase.
- Resolved: After fixing the issue by developers, the status of the bug or defect is changed to Resolved and reassigned to testing for the retest.
- Retest: Testing team again retest the fixed issue and status marked as retest until testing completes.
- Closed: If the testing team assures that the reported issue is fixed and working as expected, then the status is changed to closed.
- Reopened: If a testing team finds that the issue is still existing and the fixed bug or defect still reproducible, then the task is again assigned to developers to fix the bug by specifying the scenarios to reproduce the bug, this time status marked as reopened.
- Duplicate: If any bug is already reported and again, the same bug is reported to fix it. During analyzing the bug, if found that the bug has already been reported and in-progress state, the status of the reported bug or defect is marked as Duplicate.
- Rejected: After analyzing any reported bug or defect by developers, if they find that a bug is invalid, then developers can reject the bug or defect by providing a valid reason, and status is marked as Rejected.
- Deferred: If any bug, which is reported and can’t be fixed in current release and moved to the next release, in this case, the QA team changes the status of the bug or defect as Deferred. To differ, a bug could have many reasons like lack of time, dependencies on other features, low priority.
When a defect is fixed from development end, assigned back to tester with the status “Ready to retest” but the tester can not proceed due to other defect is “In Process”. Which is linked with resolved one.. what tester should do and what status should we keep for the defect.
Status should remain as re- test . But we need to link that defect with this one and mention the specific comment that this defect is dependent of other defect.
If we can customize it,its better to have a status such as “Retest on Hold” and can have details furnished in comments section on why it is hold.
We can also maintain one more option called “Dependency” where we can mention the bug ID with which this current bug is on hold.
Thats a Good suggestions, But its totally depends upon the organization. If you notice the Bug life cycle is different organization to organization.