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 vocabulary used by bug-report-critic.

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

Per the ISTQB Glossary (glossary.istqb.org):

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:

Per the platform docs (Atlassian "Issue workflow", Linear "Workflow states", GitHub "Issue templates"):

• Jira workflow is fully configurable - the table reflects the default Software project template.
• Linear workflow states are fixed enums (Backlog, Todo, In Progress, In Review, Done, Cancelled) but each can be subdivided per team.
• GitHub Issues has only Open / Closed as states; richer lifecycle requires Projects (status column) + labels.

Recommended state-transition guardrails

The platform-workflow skills enforce these:

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. 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.
• Sibling references in this plugin: severity-vs-priority-reference, defect-taxonomy-istqb.
• Consumed by: bug-report-critic, bug-report-from-failure, and platform-workflow skills.
• Sibling-plugin neighbour: bug-report-template (qa-bug-repro is reproduction-focused; this plugin is workflow / lifecycle / taxonomy-focused).