Bug life cycle or the Defect Life cycle is the cycle during which the defect starts from its “New” state to “Closed” state. Throughout the defect life cycle, Testers find out the defect by testing upon the various scenarios to the code, log the defect and Developers try to fix the defect finding its root cause and as they the declare the defect has been fixed, Testers retest them with same scenarios again and close the defect if it has been fixed or re-open the defect if it need to be fixed on again. The main objective of the defect life cycle will be to make sure that the defect is not reproduced in the future.
Fig: Defect life cycle diagram in SDLC process
In the Software Development process, Bug goes into various life stages, which are described as following:
- New/Submitted
During this stage, the defect has not been approved. That means the defect has been posted for the First time. Tester should make sure he has given enough details and evidences in the defect during this stage.
- Confirmed/Open
During this stage, the defect has been confirmed by the lead of the tester(usually) if he thinks that the Defect is genuine and need to be fixed and he changes the state of the defect as “Confirmed” or “Open”. The name “Confirmed” or “Open” depends on the terminology used in the defect tracking tool. In the IBM Rational ClearQuest tool, this stage is termed as “Confirmed” whereas in Application Lifecycle Management (ALM), it has been termed as “Open”.
- Assigned
Once the Testing Lead changes the state of the defect as Open he assigns the defect to the particular developer (or Analyst). Then the state of the defect will be changed to “Assigned”. The assigned state means whoever is assigned to that defect needs to work on it.
- Test
Once the developer fixes the defect, then he changes the status of the defect as “Test” that means, the defect has been fixed and testing team (or whoever opened the defect) can retest the issue with the same scenario where he found the issue.
- Fixed
In some software, the state ” Test” has been named as “Fixed”, and this state is similar as “Test”, where the Developer has fixed the defect and the testing team needs to retest the issue.
- Deferred
Deferred state of the defect means that the defect will be worked in the upcoming releases (usually next). The reason of changing the state of the defect to this can be:
- Defect is of low priority
- Lack of time to work on the defect on the current release
- Defect doesn’t have the major impact on the code/software
- Rejected
After the defect has been assigned by the Testing team to a particular developer, it’s not like that the Defect is 100% genuine and he must work on it. With his analysis, if the Developer thinks the defect is not genuine he can reject the defect and change the state of the defect as “Rejected”.
- Duplicate
If a particular defect has been has already been confirmed in another defect, or the defect describes the similar concept of the another defect, then defect state will be changed to “Duplicate”.
- Cancelled
Sometimes when someone logs the defect by mistake or logs the duplicate defect or finds the defect is not really an valid defect then he can change the state of the defect as “Cancelled” right away and then he should give the comment in the comment section giving the reason for cancelling the defect.
- Verified
Once defect has been fixed and its state has been changed to “Test” or “Fixed”, testers will do the testing again, and if he finds the defect has been fixed then he change the state of the defect as “Verified”.
- Reopened
When the tester retests the “Fixed” defect, and finds that the defect still exists then he changes the state of the defect as “Reopened”. This state of the defect means that defect has been retested and the developer needs to fix the defect again. Now defect enters the Bug life cycle again.
- Closed
After defect has been fixed and the Tester retests it and finds no any issue then he can mark the state of the defect as “Closed”. This state of the defect means this defect has been retested completely and the issue listed in the defect no longer exist in the software. Thus defect has been fixed, retested and approved to be closed.
For a tester, following things are important during the Bug life cycle:
- Make sure the time difference between the state of the defect between “Fixed” to “Closed” or “Fixed” to “Reopened” is as less as possible. This is the time everyone will be watching at your work. Whoever is responsible to retest that particular defect needs to keep close eye on the state of the defect and work on them as soon as defect has been fixed.
- While writing the defect be as specific as possible. Don’t make it complex
- Attach nice and relevant evidences in the defect. Evidences can be screenshots, emails or other records.
- Do not create defect within the defect.
