Defect Lifecycle Management: From Discovery to Closure

A defect lifecycle is the sequence of states a bug passes through from discovery to confirmed resolution. Teams that manage this well ship faster: bugs get fixed in priority order, regressions get caught before release, and nothing falls through the cracks.

Teams that don't manage it well accumulate bug backlogs that grow until they're ignored, lose track of who owns what, and repeatedly fix the same bugs.

This guide covers the complete defect lifecycle — states, transitions, responsibilities, and tooling.

The Standard Defect Lifecycle

New → Triaged → Open → In Progress → Fixed → Verification → Closed
                  ↕                              ↓
               Rejected                       Reopened

Each state has a clear owner and exit criteria.

1. New

A defect is created in New state. Anyone can create defects: QA engineers, developers, automated tests, end users.

Required information at creation:

• Clear title describing the observed behavior
• Steps to reproduce
• Expected result
• Actual result
• Environment (OS, browser, version, data setup)
• Severity (initial assessment)
• Attachments (screenshots, logs, videos)

The creator is responsible for providing enough information that the defect can be reproduced without back-and-forth.

What to include in the title:

Bad: "Login broken" Good: "Login fails with 500 error when email contains + character"

Specific titles make triage faster and help with duplicate detection.

2. Triaged

QA lead or team lead reviews the defect:

• Confirm it's a real defect (not a misunderstanding of requirements)
• Assign severity and priority (often different — see below)
• Check for duplicates
• Assign to the correct team or component

If the defect is not reproducible or is actually expected behavior, it moves to Rejected with a clear reason.

Severity vs Priority:

Don't conflate them. A critical-severity bug in a feature used by 0 customers might be lower priority than a minor-severity bug on the homepage.

3. Open

The defect is confirmed, triaged, and waiting for a developer to pick it up.

Teams using sprints: bugs are added to the sprint backlog during planning. Teams using Kanban: bugs flow directly from Open to In Progress as developers take them.

The Open state is where bugs live until development capacity is available. Monitor this queue — if it grows faster than it shrinks, you have a capacity problem.

4. In Progress

A developer has ownership and is working on the fix.

Developer responsibilities:

• Understand the root cause (not just the symptom)
• Fix the root cause, not just the manifestation
• Write a regression test before or alongside the fix
• Note the root cause in the defect for future reference

Turnaround expectations vary by severity:

5. Fixed

The developer has committed a fix. The defect moves to Fixed and is assigned back to QA for verification.

Developer should provide:

• Description of the fix
• Commit or PR reference
• How to verify the fix
• Notes on related areas to check (regression risk)

6. Verification

QA verifies the fix in the appropriate environment (typically staging, never production for initial verification).

Verification steps:

1. Reproduce the original defect using the original steps (confirm it's fixed)
2. Verify edge cases related to the defect
3. Run regression tests on related functionality
4. Verify in all affected environments (browsers, OS)

If verification passes: move to Closed. If the fix is incomplete or introduced regressions: move to Reopened with specific details about what failed.

Never close a defect without verification. Developer says "it's fixed" is not sufficient.

7. Closed

The defect is verified as resolved. It's closed with:

• Verification notes
• Build/version where the fix was confirmed
• Regression test reference (if one was added)

8. Reopened

Verification failed. The defect goes back to the developer with specific failure details.

When reopening, always specify:

• What failed (exact steps, actual result)
• Whether the original defect recurs or a new issue was introduced
• Environment and build where verification failed

A reopened defect is not a personal failure — it's the process working correctly.

Defect States for Different Issue Types

Not every defect follows the linear path. Handle variants explicitly:

Deferred: The defect is real but won't be fixed in the current release. Set target version and add to backlog. Don't close it.

Won't Fix: A conscious product decision not to fix. Document the reason. Close the defect with "Won't Fix" status. Stakeholders should agree before closing.

Can't Reproduce: The defect can't be reproduced. Don't close immediately — ask the reporter for more detail, try different environments. Close as "Can't Reproduce" only after genuine effort, with notes on what was tried.

Duplicate: A second report of the same defect. Link to the original, close as duplicate. Never merge defects — keep both, close one.

Jira Defect Workflow

# Standard Jira workflow configuration
statuses:
  - New
  - Triaged  
  - In Progress
  - Fixed
  - Verification
  - Closed
  - Rejected
  - Won't Fix
  - Deferred

transitions:
  - New → Triaged (QA lead reviews)
  - Triaged → In Progress (developer picks up)
  - Triaged → Rejected (not a defect)
  - In Progress → Fixed (developer completes)
  - Fixed → Verification (auto-assign to QA)
  - Verification → Closed (QA confirms fix)
  - Verification → Reopened → In Progress (fix incomplete)
  - Triaged → Deferred (product decision)
  - Triaged → Won't Fix (product decision)

Automation rules in Jira:

• When status changes to Fixed: auto-assign to original reporter for verification
• When Verification is older than 2 business days with no update: email assignee
• When severity is Critical and status is New for >4 hours: notify QA lead

GitHub Issues Defect Workflow

For teams using GitHub Issues:

# Bug Report Template (.github/ISSUE_TEMPLATE/bug_report.md)

**Describe the bug**
A clear description of what the bug is.

**Steps to reproduce**
1. Go to '...'
2. Click on '...'
3. See error

**Expected behavior**
What you expected to happen.

**Actual behavior**
What actually happened.

**Environment**
- OS: [e.g. macOS 14.0]
- Browser: [e.g. Chrome 120]
- Version: [e.g. 2.3.1]

**Screenshots / Logs**
Add attachments here.

**Severity**
- [ ] Critical
- [ ] High
- [ ] Medium  
- [ ] Low

Labels for lifecycle tracking:

status: new
status: triaged
status: in-progress
status: fixed
status: verification
status: closed

severity: critical
severity: high
severity: medium
severity: low

resolution: won't-fix
resolution: duplicate
resolution: can't-reproduce
resolution: deferred

Defect Metrics

Track these weekly:

Open defects by severity: The count of unresolved defects, segmented by severity. Growing critical counts require immediate attention.

Mean time to fix (MTTF): Average time from Triaged to Fixed. Track per severity to identify bottlenecks.

Reopen rate: Percentage of fixed defects that get reopened. High reopen rates indicate inadequate root cause analysis or verification.

Defect escape rate: Percentage of defects found by users (production) vs. testing. The most important quality metric.

Defect injection rate: Defects introduced per development sprint. Rising rates suggest technical debt, inadequate design review, or developer overload.

Root Cause Classification

For every defect closed, record the root cause category. After three months, analyze the distribution. Common categories:

• Requirements: Missing, ambiguous, or conflicting requirements
• Design: Incorrect technical design or architecture decision
• Code: Implementation error (logic bug, off-by-one, null handling)
• Test environment: Bug due to environment difference (config, data, dependency version)
• Integration: Behavior change in a dependency or external service
• Data: Bug triggered only by specific data conditions

If 40% of your defects are "Requirements" root cause, invest in better spec reviews. If it's mostly "Code" — look at code review practices and developer testing.

Preventing Defect Backlog Accumulation

Defect backlogs that grow without bound indicate a process problem:

1. Set WIP limits on Open: No more than X open defects per developer. Forces prioritization.
2. Zero-open-critical policy: Critical severity defects block the sprint until resolved.
3. Backlog grooming: Monthly review of deferred and low-priority defects. Close what's no longer relevant.
4. Bug debt sprints: Periodic sprints dedicated to reducing open defect count, separate from feature development.
5. Don't log every cosmetic issue: Minor cosmetic defects with no business impact should often be resolved in the moment, not logged. A bug tracker full of 2-year-old cosmetic issues destroys signal.

Summary

A well-managed defect lifecycle:

• Has clear state definitions and exit criteria
• Assigns ownership at each state
• Requires verification before closure
• Tracks root causes to prevent recurrence
• Surfaces metrics that show whether quality is improving

The process doesn't need to be heavy — a 6-state workflow with clear transitions is enough for most teams. What matters is consistency: every defect goes through the same process, every time.