Defect Life Cycle

1. New/Defect Logged

The defect life cycle begins when a tester identifies an issue in the software. Once the issue is detected, it is logged into a defect tracking tool, such as Jira or Bugzilla. This stage is called the “New” stage, where the defect is categorized with details such as severity, description, and steps to reproduce. At this point, the defect has not been investigated or addressed yet.

• Details captured: Defect ID, severity, description, environment, screenshots, reproduction steps, etc.
• Priority and severity: These are set to indicate the defect’s impact and how urgent the fix should be.

2. Assigned to Developer

Once the defect is logged, the next step is assigning it to a developer for further investigation. The development team analyzes the defect to determine its cause, whether it’s due to coding errors, design flaws, or other issues. At this stage, developers prioritize and allocate resources to fix the issue.

• Defect assessment: The developer assesses the defect’s root cause.
• Priority setting: The priority and severity of the defect are reassessed if necessary to align with project timelines and resources.

3. Open/Under Investigation

At this stage, the defect is marked as “Open” or “Under Investigation.” The developer starts working on fixing the issue. This phase may involve debugging the code, consulting with other team members, and evaluating the complexity of the issue. If it’s a critical issue, this phase could be expedited.

• Root cause analysis: Developers dive into debugging and identifying the core issue.
• Impact analysis: The team evaluates if the fix will affect other parts of the system.

4. Fixed

Once the developer resolves the issue, the defect moves to the “Fixed” stage. The developer implements the necessary changes and updates the code to address the defect. The issue is considered resolved, but it is not yet considered complete.

• Code changes: Developers modify the code, data, or configuration based on the defect’s root cause.
• Unit testing: Developers test the changes to ensure that the fix works as expected before passing it back to the testing team.

5. Retest

After the defect is fixed, it is sent back to the testing team for retesting. The tester verifies whether the defect has been fixed and if the solution does not introduce new issues into the software. This stage may lead to one of two outcomes:

• If the fix is successful, the defect is closed.

• If the defect still exists, it is sent back to the developer for further investigation, and the process repeats.

• Regression testing: Testers often perform regression testing to ensure that the fix doesn’t break other features.

• Verification: The defect is verified across different environments to check for consistency.

6. Closed

If the defect has been successfully fixed and retested without any further issues, it is marked as Closed. This indicates that the defect is no longer an issue and that the necessary actions have been taken to resolve it. The defect is now considered to be permanently addressed.

• Final verification: The defect is closed after successful verification by the testing team.
• Documentation: The issue is documented for future reference, often in terms of lessons learned and root cause analysis.

7. Reopened

If during any phase of the life cycle, the defect reappears (for example, after a fix was applied but the issue reoccurs), it may be reopened. This stage requires the defect to be reviewed again, and the process repeats from the “Open” or “Under Investigation” phase until a final resolution is achieved.

• Verification failure: If the issue reoccurs after fixing, it’s reopened.
• Root cause reassessment: The developers may reassess the cause and determine if the fix was truly the right solution.

8. Deferred

In some cases, a defect might be deferred if it is not critical for the current release but may need attention in future versions. This happens when the defect is not prioritized, either due to its low impact or because the team decides that it’s not urgent enough to fix immediately.

• Low impact: The issue may not affect the functionality or experience significantly enough to delay the release.
• Future releases: The defect is marked for attention in a later version or release cycle.

9. Rejected

Sometimes, a defect is rejected. This typically happens if the reported defect is found to be incorrect, based on misunderstanding or a misconfiguration. The testing team may realize that the issue does not actually exist, or that it’s not a valid bug, and will mark it as “rejected” and close the report.

• False report: The issue may be invalid or caused by user error rather than a software defect.
• No action needed: There is no real defect to address.