The ISO 25010 Quality Model

When you talk to a developer about non-functional requirements, you need a shared vocabulary. When you write a test plan that covers non-functional concerns, you need a checklist that does not rely on memory. When you interview for a senior QA role, you need to demonstrate that you think about quality systematically. ISO/IEC 25010 is the international standard that provides all three.

What ISO 25010 is

ISO/IEC 25010 is a published international standard that defines a model for software product quality. It breaks quality down into eight top-level characteristics, each with several sub-characteristics. The model covers both what quality means in use (from a user's perspective) and what quality means in the product itself (from a developer's perspective).

You do not need to memorise every sub-characteristic. You do need to know the eight main ones — because together they form a complete checklist of quality concerns that you would otherwise build incompletely from memory and experience alone.

The eight characteristics

Here is what each one means in practice:

1. Functional Suitability — does the software do what it is supposed to do? This is the home of functional testing: completeness (all required features exist), correctness (they produce right results), and appropriateness (they serve the intended purpose). Covered by standard functional tests.

2. Performance Efficiency — does the software do it fast enough, and without wasting resources? Time behaviour (response times, throughput), resource utilisation (CPU, memory, network under load), and capacity (maximum supported load before degradation). Covered by performance testing.

3. Compatibility — does the software coexist and interoperate correctly? Co-existence (running alongside other software without conflict) and interoperability (exchanging data correctly with other systems). Covered by compatibility and integration testing.

4. Usability — can people actually use it effectively? Learnability, operability, protection against user errors, and — critically for QA engineers — accessibility as a named sub-characteristic. Covered by usability testing, accessibility testing, and UX research.

5. Reliability — does the software stay up and recover when it fails? Maturity (does it avoid failing under normal conditions?), availability (uptime), fault tolerance (degrading gracefully), and recoverability (coming back cleanly after failure). Covered by reliability, soak, and chaos testing.

6. Security — does the software protect data and resist attack? Confidentiality (data seen only by authorised parties), integrity (data not altered without authorisation), non-repudiation (actions cannot be denied), and authenticity (identity verification). Covered by security testing.

7. Maintainability — can the software be changed without risk? Modularity, reusability, analysability, testability, and modifiability. This is primarily a developer concern, but QA engineers care about testability: software that is hard to test is usually also poorly structured.

8. Portability — can the software move to different environments? Adaptability (working across operating systems and browsers), installability (can be deployed correctly), and replaceability (can substitute for another product). Covered by cross-browser, cross-device, and compatibility testing.

How to use ISO 25010 in practice

The most practical use of ISO 25010 is as a non-functional requirements checklist. When you pick up a new feature or a new product, walk the eight characteristics and ask: have we specified a requirement, or at least consciously decided not to, for each of these?

Most teams cover Functional Suitability well. Most cover Security and Performance to some degree. Many skip or underdetermine Usability, Reliability, and Portability until something goes wrong.

Why QA engineers should know this standard

First, it gives you a defensible framework for raising concerns that would otherwise be ignored. "WCAG compliance is a Usability/Accessibility concern under ISO 25010, and we have no requirement defined for it" is a more professional position than "I think we should test accessibility."

Second, it appears in ISTQB syllabi and in job descriptions at larger organisations. Knowing the structure of ISO 25010 signals that you have thought about quality comprehensively, not just reactively.

Third, it is a useful communication tool between QA and product. Product managers who have not heard of ISO 25010 still understand the question "what is our target for availability — how much downtime per month is acceptable?"

⚠️ Common mistakes

• Treating ISO 25010 as a testing checklist rather than a requirements checklist. Its primary value is identifying what requirements need to be defined, not just what tests need to be run. An undefined non-functional requirement cannot be tested.
• Assuming Maintainability is the developer's problem. Testability is a sub-characteristic of Maintainability. A QA engineer who advocates for testable code (dependency injection, clear boundaries, observable state) is acting directly on ISO 25010.
• Over-engineering sub-characteristics. You do not need a test case for every sub-characteristic on every feature. Use the top-level eight as a mental checklist; drill into sub-characteristics only for complex or regulated systems.

🎯 Practice task

Take any project you are working on — or a public product you know well.

1. Work through the eight ISO 25010 characteristics in order. For each one, write a one-sentence answer to: "Do we have a defined, measurable requirement for this?"
2. For each characteristic where the answer is no or unclear, write one concrete requirement you could propose — something specific enough to be testable (e.g., "The API must respond in under 500ms at p95 under 200 concurrent users" for Performance Efficiency).
3. Identify the two characteristics most likely to cause a production incident if ignored. Those are your highest-priority non-functional testing investments.

The output is a simple document you could walk into a sprint planning session and use to raise the right questions before any code is written.