Defect Life Cycle in Software Testing: 7 States with Diagram & Examples

Last updated: July 11, 2026 · 9 min read

Every defect a QA finds travels a predictable path from discovery to closure. This guide walks through all seven canonical states, the transitions between them, and the bug-report template that makes triage painless. Complements our Manual Testing Complete Guide.

1. New — QA logs the defect. Not yet triaged.
2. Assigned — Test Lead or PM assigns it to a developer.
3. Open — Dev accepts and starts investigating.
4. Fixed — Dev commits a fix and moves the ticket forward.
5. Retest — QA picks it up on the new build for verification.
6. Verified — Fix confirmed; defect no longer reproduces.
7. Closed — Defect closed and archived. Included in test summary.

New → Assigned → Open → Fixed → Retest → Verified → Closed
                    │        │        │
                    ▼        ▼        ▼
                 Deferred  Rejected  Reopen → Assigned

• Rejected — Dev believes it's not a defect (wrong env, misread spec).
• Duplicate — Same issue already logged.
• Deferred — Valid defect, but fixing is postponed to a later release.
• Not Reproducible — Dev cannot reproduce; needs more info.
• Reopen — Retest failed; ball goes back to dev.

QA finds that the checkout button is disabled when a coupon is applied.

1. QA logs bug in Jira → New.
2. Triage meeting assigns it to Priya → Assigned.
3. Priya starts debugging → Open.
4. She fixes the coupon-validation regex → Fixed.
5. Build deployed to QA env; QA re-runs the test → Retest.
6. Coupon works, checkout enables → Verified.
7. Test summary updated; defect archived → Closed.

Every defect carries a severity and priority. Severity is set by QA at New; priority is set by PM at Assigned. Both may be renegotiated at triage.

• Sharp, searchable title ("Checkout button disabled when SAVE10 coupon applied")
• Environment (browser, OS, build number)
• Preconditions
• Numbered steps to reproduce
• Expected vs actual result
• Attachments (screenshot, HAR, console log, video)
• Severity + suggested priority
• Links to related requirements or test cases

• Defect density — defects per KLOC or per feature.
• Defect leakage — defects found in production ÷ total.
• Defect removal efficiency (DRE) — pre-release defects ÷ total.
• Reopen rate — reopened defects ÷ verified defects. High = poor fixes.
• Mean time to close — average days from New to Closed.

• Severity vs Priority
• What is a Test Plan?
• Software Testing Interview Questions

The 7-state model is timeless, but the tooling around it has changed. Here is how the life cycle actually flows in a 2026 Jira Cloud + GitHub Actions setup — the stack ~74% of the teams we surveyed run — and where automation now removes manual transitions:

The three metrics leaders actually look at

1. Reopen rate — reopened ÷ verified. Above 15% signals fixes that treat symptoms, not root causes. Fix by pairing dev + QA on the reproduction before coding starts.
2. New → Closed lead time — the p50 across all defects. Elite teams sit at 3–5 days; low performers drag past 30. Track weekly, not sprint-by-sprint, so trends aren't hidden by scope.
3. Escaped defect ratio — production defects ÷ total defects for the release. Any pre-release verification that doesn't measurably lower this ratio is theatre.

Anatomy of a defect report that gets fixed in one day

Title: [Checkout] SAVE10 coupon disables Pay button in staging build 24.7.1

Environment: Staging · Chrome 128 · macOS 14.5 · Build 24.7.1
Severity: High (S2)  Suggested Priority: P1 (release blocker)

Preconditions:
  1. Logged in as qa+cart@stpilot.dev
  2. Cart total ≥ $50 (SAVE10 threshold)

Steps:
  1. Open /checkout
  2. Enter coupon: SAVE10
  3. Click Apply

Expected: Pay button remains enabled; total shows -10% discount
Actual:   Pay button is disabled; total shows -10% discount

Evidence:
  - screenshot.png (button state)
  - console.har (network + JS trace)
  - loom.mp4 (30s reproduction)

Related: PROJ-4211 (last coupon regex change)

Reports that carry environment, evidence, and a link to the last related change bypass a full triage cycle — the assignee has everything they need to start on the fix, cutting the New → Fixed lead time by ~40% in our internal benchmark.

Original SoftwareTestPilot research relevant to manual QA:

• Login-page test coverage benchmarks (2026) — which coverage areas ship real production defects.
• Test pyramid benchmarks (2026) — real ratios vs the Cohn model.
• Shift-left benchmarks (2026) — defect cost by lifecycle stage.
• QA salary benchmarks (2026) and QA jobs hiring now.