Testland
Browse all skills & agents

defect-taxonomy-istqb

Pure-reference catalog of defect categorisation taxonomies. Covers the IEEE 1044-2009 anomaly classification (anomaly class, anomaly type, anomaly severity, root cause category), the ISTQB CTAL-TA root-cause taxonomy (requirements / design / implementation / interface / test-data / build-environment), and the Orthogonal Defect Classification (ODC) eight-attribute framework. Maps each taxonomy to a worked example showing how the same defect classifies under each. 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?).

Install with skills.sh (any agent)

npx skills add testland/qa --skill defect-taxonomy-istqb
View source

defect-taxonomy-istqb

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.

Consumers: bug-report-from-failure populates classification fields; defect-report review rejects unclassified defects.

When to use

  • Reviewing a defect report's classification fields.
  • Establishing the team's classification vocabulary.
  • Running a root-cause analysis after a customer escape.
  • Producing process-improvement metrics ("60% of escapes are requirements 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.

ClassDescription
DefectAn imperfection in a work product.
Test failureAn anomaly observed during testing.
Customer failureAn anomaly observed by a customer.
Process anomalyProcess not followed correctly.
Document anomalyDocumentation defect.
Configuration anomalyConfiguration / environment issue.

2. Anomaly type

Where in the lifecycle the defect originated.

TypeExample
RequirementsMissing requirement; ambiguous requirement; conflicting requirements.
DesignArchitectural flaw; incorrect algorithm choice.
Code (implementation)Off-by-one; null-pointer; incorrect logic.
InterfaceWrong API contract; type mismatch between modules.
DataIncorrect test data; production data corruption.
ToolsCI tool failure; environment misconfiguration.
Test specificationWrong expected result in the test case.
User documentationHelp text describes wrong behaviour.

3. Anomaly severity

Per severity-vs-priority-reference.

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:

Root causeDefinitionExample
RequirementsMissing, wrong, or ambiguous requirement."We never specified what happens when the cart is empty at checkout."
DesignDesign choice that produces the defect."Architecture coupled UI to DB schema; schema change broke UI."
ImplementationCorrect design, wrong code."Off-by-one in pagination logic."
Interface / integrationModules disagree on contract."Auth service returns null for missing claim; UI expects empty string."
Test data / environmentTest passed against wrong fixture."Staging DB had stale schema; test reported false positive."
Build / configurationRight code, wrong configuration."Feature flag default flipped in prod; test environment was correct."

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)

AttributeValues
ActivityWhere defect was found: Design Review, Code Inspection, Unit Test, Function Test, System Test, Acceptance Test.
TriggerWhat made the defect surface: Design Conformance, Logic / Flow, Backward Compatibility, Concurrency, Boundary, Workload / Stress, Recovery, Test Coverage, Test Variation, Test Sequencing, Test Interaction.
ImpactHow the customer experiences it: Installability, Integrity / Security, Performance, Maintenance, Documentation, Usability, Reliability, Capability, Accessibility, Standards, Migration.

Closer attributes (recorded when defect is closed)

AttributeValues
TargetWhat was modified: Design, Code, Build / Package, Information Development (docs).
Defect TypeWhat kind of change: Function / Algorithm, Assignment / Initialization, Interface, Checking, Timing / Serialization, Build / Package / Merge, Documentation.
QualifierWhy the defect existed: Missing, Incorrect, Extraneous.
SourceWhere the defective code came from: In-house, Library / Reused, Outsourced, Ported.
AgeWhen introduced: New, Old, Rewritten, Refixed.

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.

TaxonomyClassification
IEEE 1044-2009Class: Defect. Type: Code (implementation). Severity: High (S2). Cause: Control flow (incorrect ordering in promo-stacking loop).
ISTQB CTAL-TAImplementation (correct design - stackable promos are supported - but the loop control-flow has the order-sensitivity bug).
ODCActivity: Function Test. Trigger: Test Sequencing. Impact: Capability (feature doesn't work). Target: Code. Defect Type: Function / Algorithm. Qualifier: Incorrect. Source: In-house. Age: New.

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

Anti-patternWhy it failsFix
Free-text "root cause" fieldNo aggregation possibleUse a controlled vocabulary - pick one of the three taxonomies + populate enums
Single-axis classification ("severity only")Loses root-cause signal entirelyAdd at least an IEEE 1044 Type field
Classifying after closure onlyDetection-time data lost (ODC Opener attributes)Classify at triage; refine at closure
ODC without trainingInter-analyst disagreement explodes; metrics noisyCalibrate via training set (10 defects classified by 2 analysts; reconcile)
Custom taxonomy invented per teamCross-team metrics impossibleUse IEEE 1044 or ODC as the floor
Classifying duplicates separatelyInflates counts; same root cause counted thriceResolve duplicates first; classify the canonical
Treating "Implementation" as the defaultHides design / requirements leakageRequire explicit classification; default = "unclassified" until reviewer assigns

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.
  • Sibling references: bug-lifecycle-reference, severity-vs-priority-reference.
  • Consumed by: bug-report-from-failure.

Related skills

azuredevops-bug-workflow

Authors and triages Bug work items in Azure DevOps Boards via the Work Item Tracking REST API (api-version 7.1) - Bug creation with JSON Patch, state transitions across New/Active/Resolved/Closed, and WIQL queries for triage queues and duplicate detection. Deep operational blocks (field-value fetch, PR / build artifact links, bulk close, az boards CLI, CI wiring) live in references/. Use when programmatically managing Azure DevOps Bug lifecycle states: creating from CI failures, triaging open defect queues, transitioning states in bulk, or attaching traceability links to builds and pull requests.

bug-lifecycle-reference

Pure-reference catalog of defect lifecycle states and transitions. Defines the ISTQB-canonical states (new / open / assigned / in-progress / fixed / verified / closed / reopened / deferred / rejected / duplicate) and the transitions between them, distinguishes the ISTQB terms (error → fault / defect → failure), maps the lifecycle to the standard Jira / Linear / GitHub Issues workflows, and cites IEEE 1044-2009 and ISO/IEC/IEEE 29119-3 for the canonical anchors. Use as the lifecycle vocabulary for bug-report review, duplicate detection, and the platform-workflow skills.

bug-report-from-failure

On-demand builder that converts a SINGLE test failure record (JUnit XML, Allure JSON, pytest --tb=short, Playwright HTML, Cypress mocha-junit) into a structured, tracker-agnostic bug SPEC: extracts test name, assertion, stack trace, environment, and artefacts, and proposes severity, defect type (IEEE 1044), and a root-cause hypothesis (ISTQB CTAL-TA), then hands the JSON spec to a jira/linear/github-issues-bug-workflow runner to file. Use when you already hold a failure artefact and want one classified, ready-to-file report. Distinct from the event-driven CI orchestrator that triggers automatically on a pipeline failure and files in bulk, and from screen-recording-driven bug reporting; this is the on-demand, single-record spec builder.

confirmation-testing-workflow

Procedure for proving that a claimed defect fix actually reached the build under test and actually works. Covers the merge-base ancestry check that proves the running build contains the fix commit rather than trusting a version label, the priority order for choosing which reproduction to re-run, and the VERIFIED / NOT FIXED / BLOCKED verdict table whose governing rule is that any ambiguous, flaky, or unreproducible result resolves to BLOCKED and is never guessed. Scoped to ISTQB confirmation testing (does this specific fix work?), not regression testing (did the fix break something else?), and not triage or severity assignment. Use when a developer has marked a defect Fixed and someone must decide whether it moves to Verified or back to Reopened.

github-issues-bug-workflow

Author and run GitHub Issues bug workflows via REST API (2026-03-10): issue creation, state changes (open / closed with `state_reason`), label-based severity/priority classification, and comment attachment. Covers `POST /repos/{owner}/{repo}/issues`, `PATCH` for `state_reason` transitions (completed / not_planned / duplicate / reopened), and label conventions for GitHub's binary open/closed model; Projects v2, `gh` CLI, and CI wiring live in references/. Use when programmatically managing the GitHub Issues bug lifecycle; for the same workflow on another tracker use azuredevops-bug-workflow, jira-bug-workflow-runner, or linear-bug-workflow-runner.

jira-bug-workflow-runner

Jira Cloud bug workflow runner using the REST API v3: issue creation with an ADF description, runtime transition lookup and apply, JQL search for triage queues and duplicate detection, severity/priority field updates, label-based classification (severity/priority/regression), and idempotent CI-driven filing from JUnit XML test failures. Use when the target tracker is Jira Cloud and the task involves Jira lifecycle states (create, triage, transition, close). Distinct from a platform-agnostic event-driven CI defect filer, and from linear-bug-workflow-runner / github-issues-bug-workflow for other trackers.

linear-bug-workflow-runner

Author and run Linear bug workflows via the GraphQL API: issue creation, state transitions (workflowState assignment), priority assignment (0 No priority / 1 Urgent / 2 High / 3 Medium / 4 Low), label-based classification, search by team and content. Covers the issueCreate mutation, issueUpdate for state transitions, the workflowStates query for per-team state IDs, and Linear's API-key vs OAuth Bearer auth modes; resolve-by-type, CI wiring, and result parsing live in references/. Use when the target tracker is Linear specifically; for other trackers use jira-bug-workflow-runner (Jira) or github-issues-bug-workflow (GitHub Issues). Files and transitions the issue; reproducing the defect is a separate concern.

severity-vs-priority-reference

Pure-reference catalog distinguishing defect severity (impact on the system / user) from defect priority (urgency of fix), each on its own axis. Enumerates the canonical 5-point severity scale (Critical / High / Medium / Low / Trivial) and the 5-point priority scale (Immediate / High / Medium / Low / Deferred), explains why they must be tracked separately (a Critical/Deferred legacy bug exists; a Trivial/Immediate spelling bug on the homepage exists), maps to IEEE 1044-2009 severity classes, and ties to bug-lifecycle-reference state transitions. Use when triaging a defect, configuring a tracker's severity/priority fields, or reviewing whether a bug report assigned them consistently.