Guide
Defect life cycle
Defect life cycle in software testing with diagram: the usual states a bug moves through from discovery to closure, what triggers each transition, and a worked example.
Updated 5 min read
Why statuses matter
A defect without a clear status is just a complaint. Status tells dev, QA, and PM where the issue sits: still open, waiting on a fix, ready to retest, or done.
Teams rename states to match Jira or Azure DevOps, but the flow is usually the same. Pair this guide with severity vs priority so triage stays consistent.
Bug life cycle states explained
Common defect life cycle states
| Status | Owner | Trigger | Typical next step |
|---|---|---|---|
| New / Open | QA or reporter | Defect logged during a run | Triage and assign to dev |
| Assigned / In progress | Developer | Accepted for current sprint | Code fix and move to Fixed |
| Fixed / Resolved | Developer | Fix merged to test build | QA retest on new build |
| Retest | QA | Build with fix available | Close if pass; Reopen if fail |
| Closed | QA or lead | Retest passed or accepted | None — archived for audit |
| Reopened | QA | Fix failed retest or regression | Back to Assigned / In progress |
| Deferred / Won't fix | PM or lead | Out of scope or low ROI | Monitor or revisit later |
| Duplicate | Triage | Matches existing defect | Link and close duplicate |
Common life cycle stages
- New / Open: found during testing, not yet assigned
- Assigned / In progress: a developer owns the fix
- Fixed / Resolved: code change is in; needs retest
- Retest: QA verifies on a new build
- Closed: fix confirmed or accepted as done
- Reopened: fix failed retest or regressed later
- Deferred / Won't fix: acknowledged but not shipping now
- Duplicate: same as an existing defect
Before closing a defect
Before flipping the status to Closed, walk through this short list. It is the difference between an audit-clean defect log and one that gets reopened in regression.
Verify these 4 items before closing
- Same numbered steps run on a build that contains the fix
- Observed result matches the original expected result
- Linked test case step shows a Pass on the latest run
- Closure note records the build number and any spec deviations
Worked example: one defect from New to Closed
BUG-1042: coupon trailing space
Monday — QA fails CHECKOUT-03 step 4. Defect logged as New with screenshot and build 408.
Tuesday — Dev picks it up. Status → Assigned. Fix merged to build 409. Status → Fixed.
Wednesday — QA retests steps 1–4 on build 409. Coupon applies. Status → Closed.
Friday — Regression on build 411: same bug returns. Status → Reopened, linked to same case step.
Reopened vs deferred defect status
Reopened means the issue came back or the fix did not hold. Someone must reproduce on the current build and send it back to dev.
Deferred means the team agrees the bug is real but will not fix it in this release. Document the reason so QA does not retest it every sprint.
Retest is where teams lose time
Defects pile up in "Fixed" because nobody scheduled the retest. QA Workspace surfaces resolved defects as retest suggestions on the Tasks page. One click creates a retest task linked to the defect ID.
When you export a report, defects stay tied to the step and screenshot that produced them, so retest notes do not start from zero.
Closing without guessing
Close a defect only after you ran the same steps on a build that contains the fix and saw the expected result. If behavior is acceptable but different from the original spec, document that in the closure note.
- New / Open: Found during testing
- Assigned: Developer owns the fix
- Fixed: Fix in test build
- Retest: QA verifies on new build
- Closed: Fix confirmed
- Retest may move to Reopened: Fix failed or regressed
- New may move to Deferred: Acknowledged, not shipping now
- New may move to Duplicate: Matches existing defect