Every bug has a story—from the moment it’s discovered to the moment it’s fixed and closed. This journey is known as the Defect Life Cycle (or Bug Life Cycle).
Understanding the defect life cycle is critical for:
- Testers who log and manage bugs
- Developers who fix them
- Managers who track quality progress
In this post, we’ll walk through each stage of the defect life cycle, what happens at each step, and who is involved.
✅ What Is the Defect Life Cycle?
The Defect Life Cycle defines the stages a defect goes through during its lifetime in the software development process—from detection to closure.
It ensures bugs are handled in a systematic, trackable, and transparent way.
🧾 Stages in the Defect Life Cycle
🔍 1. New
A tester finds a defect and logs it using a defect tracking tool like Jira, Bugzilla, or qTest.
- Bug is assigned a unique ID
- Details like steps to reproduce, environment, severity, and attachments are added
- Status is set to New
📌 Owner: QA
✅ 2. Assigned
The bug is reviewed by the QA lead or project manager and assigned to a developer.
📌 Owner: QA Lead → Developer
🔬 3. Open
The developer acknowledges the bug and begins investigation. This stage means the issue is now being actively worked on.
📌 Owner: Developer
🛠 4. In Progress (Optional)
Some teams add this stage to show that the developer is currently fixing the issue.
📌 Owner: Developer
🧪 5. Fixed
The developer applies the fix, builds the code, and marks the bug as Fixed. The issue is now ready for retesting.
📌 Owner: Developer
🔁 6. Retest
The QA tester retests the defect in the updated build using the original steps.
📌 Owner: QA
✅ 7. Verified / Ready for Closure
If the fix works as expected and the bug no longer exists, the tester marks it as Verified or Ready to Close.
📌 Owner: QA
🔒 8. Closed
Once verified, the QA or lead marks the defect as Closed.
📌 Owner: QA Lead / QA
🔄 Alternate or Conditional Stages
🚫 Rejected / Not a Bug
If the developer or product owner determines it’s not a bug (e.g. working as designed), the status may be marked as Rejected.
🚫 Duplicate
The bug is already logged. QA updates the new ticket as Duplicate and links to the existing one.
🚫 Deferred / Postponed
The bug is acknowledged but won’t be fixed in the current release due to low impact or priority.
🚫 Cannot Reproduce
The developer or tester cannot reproduce the issue with the given steps/data. More info may be requested.
🧠 Visual Flow: Defect Life Cycle
plaintextCopyEditNew → Assigned → Open → In Progress → Fixed → Retest → Verified → Closed
↘ Rejected / Duplicate / Deferred / Cannot Reproduce ↙
🛠 Tools That Support Defect Life Cycle
- Jira (most popular)
- Bugzilla
- qTest
- TestRail (linked with Jira)
- Azure DevOps
- Redmine
📋 Best Practices
- Provide clear, reproducible steps
- Attach screenshots or recordings
- Include environment and build version
- Track linked test cases
- Use consistent severity and priority definitions
- Communicate status changes with relevant team members
🧠 Final Thoughts
The Defect Life Cycle helps QA and dev teams stay organized, efficient, and accountable. It ensures every bug is tracked, investigated, fixed, and verified before a product goes live.
By understanding this flow, you’ll be able to:
- Improve your bug reporting and follow-up
- Coordinate better with developers
- Maintain high-quality testing documentation
