bug-lifecycle-reference

Catalogs the ISTQB-canonical defect lifecycle and maps it to Jira, Linear, and GitHub Issues workflows. Consumed by the platform-workflow skills (jira-bug-workflow-runner, linear-bug-workflow-runner, github-issues-bug-workflow) for state-transition logic.

When to use

• Aligning a team's tracker configuration with the ISTQB-canonical vocabulary.
• Reviewing a bug report's current state against expected transitions (e.g., is "Closed" appropriate before verification?).
• Onboarding a tester to the canonical defect vocabulary.

How to use

1. Read the defect's current tracker state and map it to a canonical state via references/tracker-vocabulary-map.md.
2. Find that canonical state in the allowed-transitions table.
3. Check the proposed next state is in the allowed set; if it matches a forbidden transition (New -> Closed, Fixed -> Closed without Verified), flag it.
4. Apply the guardrails (triage SLA, verification gate, reopen audit, duplicate / deferred linking) before recording the move.
5. Confirm ISTQB term usage is correct (fault vs failure) in the report wording.
6. Record the transition; for Duplicate / Deferred / Rejected attach the required link or reason.
7. For metrics, count Reopened separately from New inflow.

ISTQB terms - error, fault, defect, failure, anomaly

Per the ISTQB Glossary (glossary.istqb.org (opens in new window)):

These terms are surprisingly often misused: developers say "the bug failed in production" when they mean "the failure, caused by the fault, occurred in production." The lifecycle below tracks defects (faults), not failures (events).

Canonical lifecycle states

The standard set per IEEE 1044-2009 "Standard Classification for Software Anomalies" and ISO/IEC/IEEE 29119-3:2021 "Test documentation":

Cite: ISO/IEC/IEEE 29119-3:2021 §6 "Test documentation - Anomaly report" - section enumerates the recommended fields and lifecycle states. Cite by stable ID; full text behind iso.org paywall.

State transition diagram

                +-----+
                | New |
                +-----+
                   |
       triage      |  (or reject / dup)
                   v
   +-----------+       +-----------+
   |   Open    |------>| Rejected  |
   +-----------+       +-----------+
        |                     ^
        |                     |
   assign                     |
        v                     |
   +-----------+              |
   | Assigned  |              |
   +-----------+              |
        |                     |
        v                     |
   +-----------+   defer +-----------+
   |In Progress|-------->| Deferred  |
   +-----------+         +-----------+
        |
        v
   +-----------+
   |   Fixed   |
   +-----------+
        |
   verify
        |
        +------- fail ----+
        |                 |
        v                 v
   +-----------+   +-----------+
   | Verified  |   | Reopened  |
   +-----------+   +-----------+
        |                 |
        v          assigned (back to In Progress)
   +-----------+
   |  Closed   |
   +-----------+

Allowed transitions (defensible):

Forbidden transitions (smells):

• New → Closed (skips triage + verification - only legitimate for spam / duplicate where triager catches it immediately)
• Assigned → Closed (no fix, no verification - what was closed?)
• Fixed → Closed without Verified (no verification - possibly the fix never worked)
• Closed → anything except Reopened (reopening is the only way back)

Tracker-vocabulary map

The canonical lifecycle maps to platform-specific terminology across Jira, Linear, and GitHub Issues, with per-platform notes on how configurable each tracker's states are. See the full cross-platform table in references/tracker-vocabulary-map.md.

Recommended state-transition guardrails

The platform-workflow skills enforce these:

Worked example

A Jira ticket sits in In Review and a developer wants to drag it straight to Done.

1. Map the tracker state: In Review -> canonical Fixed (per references/tracker-vocabulary-map.md); Done -> canonical Closed.
2. The requested move is therefore Fixed -> Closed.
3. Check the allowed-transitions table: Fixed allows only Verified or Reopened. Fixed -> Closed is a forbidden transition ("Fixed -> Closed without Verified").
4. Apply the verification gate guardrail: a tester must confirm the fix first, moving it to Verified.

Result: block the drag to Done, route the ticket to a QA verification step, and only allow Verified -> Closed once the fix is confirmed.

Anti-patterns

Limitations

• Workflow customisation is the norm. Real-world Jira / Linear configurations often add custom states (UX Review, Legal Review, Customer Confirmation). The canonical lifecycle is the floor, not the ceiling.
• State enumeration vs. label-based. GitHub Issues' Open / Closed binary is impoverished; teams supplement with labels and Projects status columns. This reference treats the effective lifecycle (state + label + assignee) as a single concept.
• The terms "bug" and "defect" remain interchangeable in practice. ISTQB makes the distinction sharp; most trackers don't. Adopt the canonical vocabulary or accept the colloquial use - but don't mix midstream.
• Severity / priority are separate axes. State doesn't capture how bad / how urgent. See severity-vs-priority-reference.

References

• ISTQB Glossary - glossary.istqb.org (opens in new window). Canonical definitions of error / fault / defect / failure / anomaly.
• IEEE 1044-2009 "Standard Classification for Software Anomalies" - cite by stable ID; defines defect lifecycle.
• ISO/IEC/IEEE 29119-3:2021 "Software and systems engineering - Software testing - Part 3: Test documentation" §6 - defines anomaly-report fields and lifecycle.
• Atlassian "Configure issue workflows" - Jira default workflows.
• Linear documentation "Workflow states" - fixed enum + per-team subdivision.
• GitHub Issues docs - Open / Closed + labels + Projects.
• Related references: severity-vs-priority-reference, defect-taxonomy-istqb.
• Consumed by: bug-report-from-failure and platform-workflow skills.
• Related neighbour: bug-report-template (reproduction-focused; this reference is workflow / lifecycle / taxonomy-focused).