The DEFECT LIFE CYCLE or Bug Life Cycle is a set of specific states that Bug experiences throughout its entire life cycle. The purpose of creating a process for a bug / defect life cycle is for those responsible for the bug / defect to easily manage and change the state until the bug / defect is completely removed from the system.
The tester’s main goal is not only to find the bug / flaw of the software but also to keep track of the bug until it is closed. Therefore, the life cycle of a bug is from the moment the tester finds the bug to the moment the tester closes it.
1. Life cycle diagram of bug
Bug life cycle diagram
Describes in detail each of the Bug’s states throughout a life cycle
NEW (New)
When the tester executes the test case and the output of that test case does not match the expected result, they will call it a bug. Meaning that there is a difference between the expected result and the actual result is called a bug. So this bug needs to be fixed. But the tester is not the one who fixes the bug, but the programmer will fix it.
How will a tester report this bug? They will go over to the developer and say: Hey man, I found a bug, let’s fix it soon? The answer is no. Testers need to log this bug to Team Lead and Team Lead will assign this bug fix developer after analysis. (There are many companies, testers will directly assign bugs to developers, not through Team Lead).
→ When the tester finds the bug, it will state as NEW.
OPEN
The error was logged by the tester. Team lead needs to verify that bug is correct or not, the bug has OPEN status. The following are the activities that should be performed by the team lead:
Activity should be performed by team lead
REJECTED (Denied)
A bug is marked as Rejected when the bug is invalid. That means sometimes tester may misinterpret the function and may mark the function as a bug. In this case, the bug will be rejected after the team lead has checked it again.
→ When a tester reports a bug but it is a function of the application, team lead will mark it as REJECTED (H1).
DUPLICATE (Duplicate)
If the bug is valid, then the team lead will check if the bug was logged by someone else. If someone else has logged it, the team lead will mark it as DUPLICATE. If it has not been reported by another tester, the team lead will search for it in scope.
As we all know, we work in a team. It is likely that the same software or module will be assigned to more than one tester, in which case the same error can be found by many testers.
So the team lead needs to make sure that the same bug won’t be reported twice or more.
→ If the same bug is reported by two or more testers then the error reported later will be marked as DUPLICATE.
POSTPONED (Delayed)
If the bug is not duplicated, but is not part of the current release, it will be marked as Deferred. That means let’s say you are following an agile model, and they divide the project request into sprints, for example split into 10 sprints: sprint 1, sprint 2, …, sprint 10. Currently on sprint 1, but the bug you find is related to a feature that will be developed in sprint 2, this bug will be marked as DEFERRED. The Deferred bug is a bug, but it will be fixed in a future release.
→ When a bug is part of a future release it will be marked as DEFERRED.
ASSIGNED (Assign bug)
When the bug found is valid, unique, and belongs to the current release, the team lead will assign that bug to the developer.
FIX
When receiving a bug from team lead, developer will make changes to fix the bug to meet the requirements, and push back to the tester to check it again.
RE-TESTING (Test again)
After the bug is fixed, and the function / feature is ready for testing, then the tester will redo the test case and verify it was running properly or not. This is called RE-TESTING.
CLOSED
Once the bug has been fixed, has been tested again and it runs as required, the tester will mark it as CLOSED.
RE-OPENED
There are 2 situations where we need to re-open the bug:
- Scenario 1: When the developer fixes the bug and the tester performs re-testing it, but after re-testing the bug still occurs, the tester will RE-OPEN the bug and assign it to the developer.
- Scenario 2: There is a case where the fixed and closed error reappears. In this case, the tester needs to RE-OPEN the closed bug and assign it to the developer.
2. Explain the life cycle of bug / defect
- Tester found bug / defect
- Assign bug status: New / New
- Transfer the bug to Project Manager for analysis
- The project manager decides if the bug is valid or not
- If the error is not valid, the status will change to “Rejected / Rejected.”
- If the error is not rejected, the next step is to check if it is in the scope. Let’s say we have another function – an email function for the same application and you see a problem with that. But if it’s not in the scope of this app release, the bug’s status may change to “Postponed / deferred”.
- Next, the manager needs to verify if any similar bugs have been found previously. If present, the bug is changed to “Duplicate / Duplicate”.
- If no problem arises while the dev fixes the bug then the bug is changed to “In-progress / in progress” state.
- When the code is fixed. Bug will be assigned the status of “Fixed / fixed”
- Next, the tester will retest the code that has just been fixed. If the relevant test cases are passed, the bug is closed or changed state to “Closed”. If the test cases fail again, the error is reopened / re-opened and passed on to dev again
- Consider a scenario where during the first release, an error found in the Fax order was corrected and assigned a close state. In the second upgrade, the same error reappears. In such cases, a closed defect will be reopened.
Translation and references from https://www.guru99.com/defect-life-cycle.html and software-testing-tutorials-automation.com/2016/12/bug-life-cycle.html