Explain defect life cycle using
real world example?
Defect Life Cycle (Bug Life Cycle) with Real-World Example
The Defect Life Cycle represents the stages a defect goes through from discovery to closure. It helps in tracking defects efficiently during software development and testing.
🔄 Defect Life Cycle Stages
| Stage | Description | Real-World Example (E-commerce Website) |
| 1. New 🆕 | A new defect is identified and reported. | A tester finds that the “Add to Cart” button is not working. The defect is logged in the bug tracking tool (e.g., Jira, Bugzilla). |
| 2. Assigned 📌 | The defect is assigned to a developer for fixing. | The project manager assigns the defect to a developer to investigate. |
| 3. Open 🔍 | The developer starts working on fixing the issue. | The developer checks the code and identifies a missing function that prevents the button from adding items to the cart. |
| 4. Fixed 🔧 | The defect is resolved by modifying the code. | The developer fixes the missing function and updates the system. |
| 5. Pending Retest ⏳ | The defect is sent to the testing team for verification. | The tester is notified that the issue has been fixed and needs to be rechecked. |
| 6. Retesting 🔄 | The tester verifies whether the defect is properly fixed. | The tester clicks the “Add to Cart” button again to confirm that items are added successfully. |
| 7. Verified ✅ | The tester confirms that the defect is resolved. | The tester finds that the button is now working correctly. |
| 8. Closed 🚀 | The defect is considered completely resolved. | The tester closes the defect in the bug tracking system, marking it as fixed. |
Other Possible Defect States
| Stage | Description | Real-World Example |
| Retest Failed ❌ | The issue is not fixed correctly and needs rework. | The tester finds that the “Add to Cart” button still doesn’t work for specific products. The defect is reopened. |
| Rejected 🚫 | The developer does not accept the defect (not a bug, duplicate, or works as designed). | The tester reports a UI defect, but the developer explains it was designed that way intentionally. |
| Deferred ⏳ | The defect is postponed to be fixed in a future release. | The issue is minor (e.g., a spelling mistake in a tooltip), so the team decides to fix it later. |
| Duplicate 🔄 | The same defect was reported earlier. | Another tester already logged the same issue, so it is marked as a duplicate. |
Real-World Example Summary: E-commerce Website
- A tester finds that clicking “Add to Cart” does nothing (New).
- The defect is assigned to a developer (Assigned).
- The developer investigates and starts fixing it (Open).
- The missing function is added, and the issue is fixed (Fixed).
- The tester retests it (Pending Retest → Retesting).
- The tester confirms it works correctly (Verified).
- The defect is marked as Closed.
If the defect is not fixed properly, it goes back to Retest Failed and is reopened.
Conclusion
The Defect Life Cycle ensures that software defects are properly tracked, prioritized, and resolved efficiently. It helps teams maintain software quality by making sure that bugs don’t get ignored or forgotten.
