In plain English.

Every risk-based test strategy starts with a list. A quality risk category is a class of failure a system could have; the risk items inside each category are specific failures a specific engagement is exposed to.

Most programs waste their first FMEA session reinventing the category list. This piece publishes the one we use.

Three views of the same taxonomy:

• The flat 16-category reference.
• The per-test-level cross-reference (component / integration / system-and-acceptance).
• The seven categories we added since 2002, because products and their failure modes changed.

Function, load, reliability, stress, date.

• Functionality, features don't work as specified.
• Load, Capacity, and Volume, scaling to peak concurrent usage and data volumes.
• Reliability / Stability, availability, MTBF, resource leaks, degradation over uptime.
• Stress, Error Handling, Recovery, beyond-peak behavior; deliberate failures; recovery from partition, power loss, upstream outage.
• Date Handling, time-zone boundaries, DST, leap seconds, year boundaries, fiscal-vs-calendar, internal epoch expiry.

Competitive, ops, usability, data, perf.

• Competitive Inferiority, fails to match competing systems in quality. Requires market research, not just engineering.
• Operations and Maintenance, backup/restore, runbooks, on-call workflows, ops-staff ability to recover without engineering.
• Usability, human factors; interface; install flow; onboarding; recovery from user error.
• Data Quality, silent corruption, precision loss, truncation, encoding, referential integrity.
• Performance, latency, throughput, responsiveness against SLO.

Localization, compat, security, install, docs, interfaces.

• Localization, locale, dictionary/thesaurus, collation, formatting, error messages.
• Compatibility, OS/browser/device/runtime/dependency combinations; dependency-upgrade regressions.
• Security and Privacy, fraudulent/malicious misuse. Deep sub-taxonomy (OWASP Top 10, MITRE ATT&CK, CWE).
• Installation / Migration, deployment, canary/blue-green/rollback integrity, database migration safety.
• Documentation, operator/user docs, API ref accuracy, runbook accuracy, deprecation notices.
• Interfaces, wire formats, contract violations, schema drift, protocol mismatches, silent field removal.

Close to the code.

• States, internal state transitions, state-machine correctness.
• Transactions, single-component unit-of-work correctness.
• Code coverage, structural coverage of the implementation.
• Data flow coverage, variable def/use pairs, data-flow anomalies.
• Functionality, component-level feature behavior.
• User interface, component-local rendering / input handling.
• Mechanical / signal / embedded properties, for physical products.

Fast feedback. High volume. If a category is listed here, component testing is where it's cheapest to catch it.

Across boundaries.

• Component or subsystem interfaces, contract verification, schema compliance.
• Functionality, feature behavior spanning components.
• Capacity and volume, subsystem-level load.
• Error / disaster handling and recovery, failure propagation across boundaries.
• Data quality, integrity across subsystem boundaries.
• Performance, subsystem latency and throughput.
• User interface, UI integration with data layer.

Contract verification. Data flow between subsystems. Integration testing exists for the categories that don't survive component isolation.

Only the full assembly.

Functionality · User interface · States and transactions · Data quality · Operations · Capacity and volume · Reliability, availability, stability · Error / disaster handling and recovery · Stress · Performance · Date and time handling · Localization · Networked and distributed environment behavior · Configuration options and compatibility · Standards compliance · Security and privacy · Environment · Installation, cut-over, setup · Documentation and packaging · Maintainability · Alpha, beta, and live tests.

The reason system test exists. These categories are invisible at lower levels.

Out of Usability. Into law.

Both split out of existing categories because they grew their own testable surface.

The bill. And the dependencies.

Both absent from 2002 because cloud-native and dependency-rich ecosystems changed the failure surface.

Probabilistic output changes testing.

These are distinct from Functionality and Security. They need their own test strategy, their own tooling, and their own owner.

Why did the system do what it did?

• Defensible account of specific decisions.
• Increasingly mandatory in regulated contexts: credit, hiring, healthcare, underwriting, insurance pricing, immigration, education.
• Decision logs. Feature attribution. Data and model version lineage. Ability to reconstruct a specific production decision six months later.

Pair with Cost-of-Exposure and Compliance risks under Security / Privacy. Explainability is now a category in its own right, not a subsidiary concern.

Walk it out loud. Cross-check.

1. Walk the 16-category flat list at the top of the session. "Does this category contain items that apply to this release?" Draft items if yes; log an explicit "not applicable because…" if no. The explicit negative answer is the completeness signal.
2. Cross-check against the per-test-level view. Every category with items should map to at least one test level. Categories with items but no level mapped = test-plan gap.

2026 additions. ISO mapping.

3. Apply the 2026 additions as a second pass. For any modern system, at least three of seven will apply. For AI-backed systems, usually five or more.
4. Map to ISO/IEC 25010:2023 if a formal framework is required (regulated buyer, compliance audit, procurement scoring). Both views coexist, the named categories drive FMEA items; the ISO mapping supports external reporting.

Zero ceremony. Every release.

• Sixteen categories, three minutes. Say them out loud. Answer "applies" or "not." Move on.
• Different test levels see different risks. The per-level view keeps each team focused on what they can actually test.
• Categories with items but no test level mapped = test-plan gap.

The taxonomy moves forward.

• Seven 2026 additions. Accessibility, observability, FinOps, supply chain, AI accuracy, AI safety, explainability.
• Pair with ISO/IEC 25010:2023 when a formal framework is required.
• When a new failure class bites an engagement, propose a category in the next methodology review.