---
title: Explain defect life cycle using real world example?
description: "**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…"
url: "https://vinothqaacademy.com/docs/explain-defect-life-cycle-using-real-world-example/"
updated: "2025-02-24"
category: QA Software Testing
tags:
  - QA Software Testing
---

# Explain defect life cycle using real world example?

**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**

1. A tester finds that clicking "Add to Cart" does nothing (**New**).
2. The defect is assigned to a developer (**Assigned**).
3. The developer investigates and starts fixing it (**Open**).
4. The missing function is added, and the issue is fixed (**Fixed**).
5. The tester retests it (**Pending Retest** → **Retesting**).
6. The tester confirms it works correctly (**Verified**).
7. 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.*