Defect lifecycle states and transitions

Reference companion to severity-vs-priority-reference. Catalogs the ISTQB-canonical defect lifecycle and maps it to Jira, Linear, and GitHub Issues workflows. Consumed by bug-tracker-workflow for state-transition logic.

How to use

1. Read the defect's current tracker state and map it to a canonical state via tracker-vocabulary-map.md (opens in new window).
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 tracker-vocabulary-map.md (opens in new window).

Recommended state-transition guardrails

Enforced by bug-tracker-workflow automation:

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 tracker-vocabulary-map.md (opens in new window)); 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.

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.

Defect categorisation taxonomies

Reference companion to severity-vs-priority-reference. Catalogs the three load-bearing defect taxonomies:

1. IEEE 1044-2009 - the formal anomaly-classification standard (canonical for regulated / safety-critical industries).
2. ISTQB CTAL-TA root-cause - the test analyst taxonomy used for retrospective root-cause analysis.
3. Orthogonal Defect Classification (ODC) - IBM Research's eight-attribute framework for in-process defect classification.

Use to categorise defects consistently across a team, drive root-cause analysis, and inform process-improvement decisions ("where in the SDLC do we leak the most defects?"). The from-CI-failure workflow in bug-report-template (qa-bug-repro) populates these classification fields; its review checklist rejects unclassified defects.

IEEE 1044-2009 classification

IEEE 1044-2009 "Standard Classification for Software Anomalies" (cite by stable ID; statutory text behind ieee.org paywall) defines four classification dimensions per defect:

1. Anomaly class

What the anomaly broadly is.

2. Anomaly type

Where in the lifecycle the defect originated.

3. Anomaly severity

Per the severity scale in the main severity-vs-priority-reference SKILL.

4. Cause classification

Root cause categories: timing, race condition, memory leak, boundary condition, calculation error, control flow, etc.

ISTQB CTAL-TA root-cause taxonomy

The ISTQB Advanced Test Analyst syllabus simplifies to six high-frequency categories used in retrospective root-cause analysis:

Per ISTQB Glossary (glossary.istqb.org (opens in new window)) entries "root cause" and "root cause analysis." The categories above appear in CTAL-TA syllabus §6 on defect management.

Orthogonal Defect Classification (ODC)

IBM Research's ODC framework (Chillarege et al. 1992) classifies each defect on eight orthogonal attributes so that the classification is reproducible across analysts and the resulting distribution is informative.

Opener attributes (recorded when defect is found)

Closer attributes (recorded when defect is closed)

ODC's strength: the distribution of values per attribute indicates where in the process the defect process leaks. A high "Function / Algorithm - Missing - Requirements activity" cluster says the requirements review process is broken.

Per IBM Research's published ODC materials and Chillarege's canonical paper "Orthogonal Defect Classification - A Concept for In-Process Measurements" (IEEE Trans. Software Engineering 1992).

Same defect under three taxonomies - worked example

Defect: Checkout silently drops the discount when the user applies two stackable promo codes in reverse order. Reproducible.

The three give different lenses: IEEE points at "control flow"; CTAL-TA points at "implementation"; ODC says "the function-test activity caught what code inspection missed, and the bug is a sequencing-triggered algorithm issue."

Process metrics enabled by classification

Once defects are classified, useful metrics emerge:

• Defect leakage by lifecycle phase: count defects where IEEE Type = "Requirements" found in System Test or later. High = upstream review is weak.
• Defect injection vs detection rate: ODC "Activity" vs "Trigger" cross-tab. Many "Function Test" activities catching "Boundary" triggers = unit-test boundary coverage is weak.
• Root-cause distribution over releases: CTAL-TA root causes per release. Trending up on "Interface" = integration contracts need attention.

Anti-patterns

Limitations

• Classification is human work. ML classifiers exist but require calibrated training data; inter-rater agreement on ODC's eight axes is moderate.
• Taxonomies are anchored in a snapshot of practice. IEEE 1044 dates from 2009 (updated periodically); ODC from 1992; ISTQB syllabus evolves. The categories are conventional, not universal.
• Costs vs benefits. Full ODC adds ~5 - 10 minutes per defect at closure. Adopt the minimum (IEEE Type + ISTQB root cause) unless safety-critical / regulated need full ODC.
• Doesn't replace 5-whys. Taxonomies categorise; root-cause analysis explains. Use both.

References

• IEEE 1044-2009 "Standard Classification for Software Anomalies" - cite by stable ID. Primary taxonomy.
• ISTQB Advanced Test Analyst (CTAL-TA) syllabus §6 - root-cause taxonomy. Glossary entries at glossary.istqb.org (opens in new window).
• Orthogonal Defect Classification - Chillarege et al. (1992) "Orthogonal Defect Classification - A Concept for In-Process Measurements," IEEE Transactions on Software Engineering 18(11). Cite by stable DOI when available.
• IBM Research ODC FAQ - chillarege.com/odc resources.

Tracker-vocabulary map

The canonical ISTQB / IEEE lifecycle maps to platform-specific terminology across Jira, Linear, and GitHub Issues.

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.