The Bug Life Cycle
Every bug follows a lifecycle from discovery to resolution. Understanding this lifecycle helps you track bugs effectively, communicate clearly with developers, and ensure nothing falls through the cracks.
Standard Bug Statuses
New
Bug has been reported by QA. It has not been reviewed or assigned yet.
Who: QA Engineer creates the bug report Next: Triage meeting or lead reviews and assigns
Open (Assigned)
Bug has been reviewed, accepted as valid, and assigned to a developer.
Who: QA Lead or Project Manager assigns Next: Developer starts working on it
In Progress
Developer is actively working on the fix.
Who: Developer updates status when starting work Next: Fix is complete and ready for testing
Fixed (Ready for QA)
Developer has implemented a fix and deployed it to the test environment.
Who: Developer marks as fixed with details about the fix Next: QA verifies the fix
Verified (QA Passed)
QA has confirmed the fix resolves the original issue. The bug no longer reproduces.
Who: QA Engineer who reported the bug verifies Next: Bug is closed after release
Closed
Bug is resolved and the fix is deployed to production. The lifecycle is complete.
Who: QA or Project Manager closes after production deployment Next: None — lifecycle complete
Reopened
QA verification failed — the fix does not resolve the issue, or the bug reappears.
Who: QA Engineer reopens with explanation of why the fix failed Next: Returns to “In Progress” for the developer
Special Statuses
Duplicate
The same bug has already been reported. Link to the original.
When to use: Exact same issue, same root cause. Not just similar symptoms. Action: Close as duplicate, add link to the original bug
Cannot Reproduce
The bug cannot be recreated following the reported steps.
When to use: After multiple attempts in the specified environment Action: Return to reporter for more details, additional steps, or environment specifics
Won’t Fix
The bug is valid but a conscious decision is made not to fix it.
Reasons:
- Cost of fix exceeds the impact
- Feature is being deprecated
- Fixing would break backward compatibility
- Risk of introducing new bugs is too high
Deferred
The bug is valid but fixing is postponed to a future release.
When to use: Bug is real but not critical enough for current release timeline Action: Add to backlog with target release, review in future planning
Invalid (Not a Bug)
The reported behavior is actually by design, or the reporter misunderstood the requirements.
When to use: After confirming with product owner that the behavior is intended Action: Close with explanation, update documentation if requirements were unclear
The Life Cycle Flow
Roles at Each Stage
| Stage | QA Role | Developer Role | PM Role |
|---|---|---|---|
| New | Create detailed report | — | — |
| Triage | Explain, clarify | Assess complexity | Prioritize |
| Open | Monitor | Accept assignment | Track progress |
| In Progress | Available for questions | Implement fix | Remove blockers |
| Fixed | Verify fix thoroughly | Explain changes made | — |
| Verified | Confirm resolution | — | Plan deployment |
| Closed | Update test cases | — | Report to stakeholders |
| Reopened | Explain why fix failed | Re-analyze problem | Adjust priorities |
Exercise: Trace These Bug Journeys
For each scenario, describe the complete lifecycle path the bug should follow.
- QA reports a crash. Developer finds it is caused by the same issue as bug #234 which is already being fixed.
- QA reports slow page load. Developer investigates and discovers it only happens with a specific browser extension installed.
- QA reports a UI alignment issue. Product Owner says fixing it would delay the release by 2 days. The release date is firm.
- QA reports a data formatting bug. Developer fixes it. QA verifies the original issue is fixed but discovers the fix introduced a new bug in a related feature.
Solution
Scenario 1: New → Duplicate (linked to #234). Close with note: “Root cause identical to #234. Fix in #234 will resolve this. Will verify when #234 is fixed.”
Scenario 2: New → Cannot Reproduce → (QA provides browser extension info) → Reopened → Open → In Progress → Fixed (developer adds browser extension detection/warning) → Verified → Closed. OR: New → Invalid (if the extension is known to cause issues and is not supported).
Scenario 3: New → Open → Deferred (target: next release v3.2). Add to backlog with note: “Valid UI bug. Deferred to v3.2 to avoid release delay. Low severity, does not affect functionality.”
Scenario 4: New → Open → In Progress → Fixed → Reopened (QA notes: “Original issue fixed, but fix introduced regression in date display on export page. See new bug #567 for details.”). The developer gets the reopened bug back AND #567 is filed as a new separate bug linked to this one.
Best Practices
- Always explain status changes — never change a status without adding a comment explaining why
- Link related bugs — duplicates, regressions, and related issues should reference each other
- Re-verify after reopening — when a reopened bug is fixed again, verify both the original issue and the regression
- Track deferred bugs — review deferred bugs at the start of each release planning
- Close promptly — do not leave verified bugs hanging. Close after production deployment
Key Takeaways
- Bug lifecycle: New → Open → In Progress → Fixed → Verified → Closed
- Special paths: Duplicate, Cannot Reproduce, Won’t Fix, Deferred, Invalid
- Reopened bugs return to In Progress — always explain why the fix failed
- QA verifies fixes; Product Owner decides priority and deferral
- Every status change should include an explanatory comment
- Track deferred bugs to ensure they are addressed in future releases