Complex systems need explicit quality models. Without one, teams over-focus on visible functional behavior and under-test the hidden properties that determine whether the system can be trusted.
Start with the quality model
A complex system is not just a larger simple system. It has more dependencies, more failure modes, more data states, more user roles, more deployment paths, and more operational consequences. A generic regression strategy is not enough.
Teams often build test plans around features because features are visible. But the hardest risks in complex systems are frequently cross-cutting: consistency, latency, authorization, accessibility, resilience, data quality, compatibility, observability, and recoverability. If the quality model does not name those properties, the test strategy will underrepresent them.
Helpful standards and signals
ISTQB's CTFL coverage spans test levels, test types, static testing, risk management, tools, and defect management. SRE adds user-centered service indicators. OWASP and WCAG provide domain-specific quality dimensions for security and accessibility. Together they point to a multidimensional model.
How I would build the model
A quality model defines what 'good' means for a system in context. It should not be copied blindly from another organization.
The model should be risk-weighted. A trading platform, healthcare workflow, internal analytics dashboard, and public e-commerce site do not have the same quality priorities.
The model should connect each quality attribute to evidence. Naming performance, security, or accessibility without defining how they will be assessed is theater.
A Practical Quality Attribute Model
- Functional correctness: Does the system perform the intended business behavior?
- Data integrity: Is data accurate, complete, consistent, and recoverable?
- Reliability: Does the service meet user-relevant availability and latency expectations?
- Security and privacy: Are controls verified against realistic misuse and exposure risks?
- Usability and accessibility: Can intended users complete workflows effectively and inclusively?
An enterprise workflow example
For a claims processing platform, quality cannot be reduced to screens and APIs. The model must include rule correctness, auditability, role-based access, integration reliability, exception handling, reporting accuracy, document retention, accessibility, and operational monitoring. Each attribute needs its own evidence strategy.
Modeling mistakes
- Using one generic definition of quality across all product areas.
- Leaving non-functional attributes until late validation.
- Failing to connect quality attributes to owners, evidence, and release criteria.
How leaders keep the model useful
- Create a living quality model for each major product or platform.
- Review the model after incidents, architecture changes, and regulatory changes.
- Use the model to drive test strategy, automation investment, and release readiness.
A quality model is how a QA leader turns vague expectations into testable engineering commitments. Complex systems require nothing less.
