Defect life cycle is the series of states that a defect or bug traverses before being disposed or closed. Defect life cycle or Bug life cycle starts when the a defect is found in the software product and ends when defect is disposed or closed.
Before we actually go into the details of defect life cycle lets first try to understand what is a defect and when is the defect introduced in software.
A defect or bug is flaw in any software system that can cause the software system to fail to perform what its actually supposed to perform. A defect gets introduced in software work product due to the mistake made by the person creating that work product.(Work product can be requirements, design document, test plan, test scripts, code etc.)
A defect can be introduced in any phase of SLDC(Software Development Life Cycle) so it is very important that test team is involved from beginning of SDLC for detecting and removal of defects. The earliest the defect is detected and rectified, the minimal cost of quality will incur.
For Example: If the defect is identified in requirements phase then the cost of fixing it is just modifying the requirement whereas if the wrong requirement is designed and implemented in the code and found during the test execution phase then the cost to fix that defect will be very high as the fix needs to be done in requirement and then those changes need to propagate to design, development and testing again.
In the figure shown below all the defect reports move through a series of clearly identified states before they are Closed/Disposed.
- A defect is in open state when the tester finds any variation in the test results during testing, peer tester reviews the defect report and a defect is opened.
- Now the project team decides whether to fix the defect in that release or to postpone it for future release. If the defect is to be fixed, a developer is assigned the defect and defect moves to assigned state.
- If the defect is to be fixed in later releases it is moved to deferred state.
- Once the defect is assigned to the developer it is fixed by developer and moved to fixed state, after this an e-mail is generated by the defect tracking tool to the tester who reported the defect to verify the fix.
- The tester verifies the fix and closes the defect, after this defect moves to closed state.
- If the defect fix does not solve the issue reported by tester, tester re-opens the defect and defect moves to re-opened state. It is then approved for re-repair and again assigned to developer.
- If the project team defers the defect it is moved to deferred state, after this project team decides when to fix the defect. It is re-opened in other development cycles and moved to re-opened state.
- It is then assigned to developer to fix it.
