What Is Software Quality?
The ISTQB glossary defines quality as the degree to which a work product satisfies the stated and implied needs of its stakeholders. Software quality is that degree for a software product, and the same idea sits behind the product quality model ISO/IEC 25010. Quality is a matter of degree, not yes or no. Stated needs are written in requirements and user stories; implied needs are expected without being written: a password is not shown on screen, an Arabic name is saved exactly as typed, a payment is not taken twice.
A clinic booking app may let a patient choose a doctor and a time exactly as its user story says. If the free times take a minute to load, or one patient can open another patient’s booking by changing a number in the address bar, nobody would call it a quality product.
Why it matters
If quality only meant "the features work", testing would only check features. Software also fails people in other ways: it is slow at peak time, exposes personal data, cannot be used with a screen reader, loses work when the network drops, or is so hard to change that every fix breaks something else. Finding these gaps while the design can still change saves time and money.
For a tester, a quality model is a checklist and a shared vocabulary: it shows what a requirement leaves out and helps you explain why a defect matters to a specific stakeholder.
The nine characteristics of ISO/IEC 25010:2023
ISO/IEC 25010 divides product quality into characteristics, each refined into sub-characteristics. Functional testing checks functional suitability; the other eight belong to non-functional testing, which a later lesson covers.
Older material, including the 2011 edition, says usability instead of interaction capability and portability instead of flexibility, and has no safety. The ISTQB Foundation syllabus (v4.0.1) keeps usability and portability, adds the new names next to them and lists safety. Use the 2023 names in new documents:
- Functional suitability: the functions are complete, correct and appropriate for the users’ tasks.
- Performance efficiency: time behaviour, resource utilisation and capacity.
- Compatibility: co-existence with other software and interoperability with connected systems.
- Interaction capability: users can learn and operate it and are protected from their own errors; inclusivity and user assistance replace accessibility.
- Reliability: faultlessness, availability, fault tolerance and recoverability.
- Security: only authorised access, through confidentiality, integrity, authenticity, accountability, non-repudiation and resistance to attack.
- Maintainability: modularity, reusability, analysability, modifiability and testability.
- Flexibility: the product can be adapted, scaled, installed and replaced.
- Safety: it avoids endangering life, health, property or the environment, for example by failing safe and warning about hazards.
Product quality and quality in use
Product quality describes the software itself, and much of it can be examined before release through reviews, static analysis and tests. Quality in use describes the effect when people use the product for their goals in a real context.
The 2011 edition of ISO/IEC 25010 contained both models; quality in use now has its own standard, ISO/IEC 25019:2023. It defines quality in use as the extent to which a product, used in a specified context of use, satisfies or exceeds stakeholders’ needs to achieve specified beneficial goals, with three characteristics: beneficialness, freedom from risk and acceptability.
Good product quality makes good quality in use possible, not certain. The booking app can pass every test and still fail patients who book on an old phone with a weak signal. That gap is one reason for acceptance testing with real users and for monitoring after release.
Quality depends on users and context
Stakeholders weigh the same product differently: a patient wants to book in a few taps, the clinic manager wants no double bookings, a health regulator cares about who can read medical data. Which characteristics matter most depends on who uses the product, for what and where, so the same defect can be trivial in one product and serious in another.
Characteristics also conflict: asking for a one-time code at every sign-in adds security but costs interaction capability. Choosing the balance is a product decision; the tester makes the trade-off visible with evidence.
- A monthly internal report for three analysts: correctness first; a slow screen is tolerable.
- A public payment page on the first day of a national sale: performance efficiency, security and reliability.
- Software that calculates medicine doses: safety can outweigh everything else.
- A banking app with many older and screen-reader users: interaction capability is a core requirement.
Worked example: questions for a clinic booking app
User story: "As a patient, I want to book an appointment with a doctor at a free time, so that I do not have to call the clinic." The clinics serve many older patients, store medical data and open bookings at 08:00.
One question per characteristic turns this functional story into decisions and future checks. The team rates functional suitability, interaction capability, reliability and security as high, the other four as medium, and safety as low because the app gives no medical advice; the product owner still answers the safety question.
- Functional suitability: does booking 09:00 with the chosen doctor reserve exactly that slot?
- Performance efficiency: how fast must free slots load at 08:00, when many patients try at once?
- Compatibility: does every booking reach the clinics’ scheduling system correctly?
- Interaction capability: can a first-time patient book unaided, with a screen reader or large text?
- Reliability: if the connection drops during confirmation, is there exactly one booking or none?
- Security: can a patient see only their own appointments, even after editing the booking number in the address bar?
- Maintainability: can the cancellation deadline change without side effects?
- Flexibility: does it run on the supported phone operating systems, and can new clinics be added?
- Safety: should "chest pain" as the reason for a visit send the patient to emergency care?
| Characteristic | The question it asks of any product | Weight for the clinic booking app |
|---|---|---|
| Functional suitability | Does it do what users need, completely and correctly? | Highthe story itself |
| Performance efficiency | Is it fast enough, with acceptable resources, at the expected load? | Medium |
| Compatibility | Does it work alongside other software and exchange data with connected systems? | Medium |
| Interaction capability2011 name: usability | Can the intended users, including people with disabilities, learn and use it? | Highmany older patients |
| Reliability | Does it keep working, and recover when something fails? | Highone booking or none |
| Security | Can only authorised people and systems reach the data and functions? | Highmedical data |
| Maintainability | Can the team change and test it without breaking other parts? | Medium |
| Flexibility2011 name: portability | Can it be adapted, scaled, installed in a new environment or replaced? | Medium |
| Safetynew in 2023 | Could a failure endanger life, health, property or the environment? | Lowno medical advice, but the question is still answered |
The weights are this team’s judgement for this app. Another product or context weighs the same nine questions differently.
Common mistakes
- Treating quality as "the features work": functional suitability is one characteristic of nine.
- Testing only what is written and ignoring implied needs.
- Using one quality bar for every product, whatever the users and the context.
- Mixing 2011 and 2023 names in one test plan, so that usability and interaction capability look like two areas.
- Calling a build "good" or "bad" without naming the characteristic, the stakeholder and the evidence.
- Assuming that a product that passes its tests works well for real users in their context.
The QA perspective
Quality characteristics come up first when stories are refined and requirements reviewed. For each story, ask which characteristics matter and whether the story says anything about them: "What response time is acceptable?", "Who may see this data?", "What if the payment provider is down?" Record the answers as acceptance criteria or non-functional requirements so that they can be tested.
In bug reports, name the characteristic: "Reliability: if the connection drops during confirmation, the slot stays blocked and no booking appears." In test reports, state which characteristics were not tested, so that the team accepts that risk knowingly.
Practice exercise
Write quality questions for a school fees portal
A school launches a web portal where parents pay fees and see their children’s grades, on phones and laptops, in Arabic or English. Most fees are paid in the last week before the deadline.
Write one quality question per characteristic, pick the three most important characteristics for this context with a reason for each, and name one implied need and whose need it is (look beyond the parents). Then compare your list with the angles the Test Scenario Generator suggests.
Show the model answer
Example questions. Functional suitability: is each child’s amount due correct, with a receipt for every payment? Performance efficiency: does payment stay fast in the deadline week? Compatibility: do payments reach the school’s finance system? Interaction capability: can a parent pay on a phone, in Arabic, unaided? Reliability: if the bank page times out, is the parent charged once or not at all? Security: do parents see only their own children’s grades? Maintainability: can next year’s fee table change without side effects? Flexibility: could a second school join? Safety: there is no risk to life or health; record that instead of skipping it.
Most important: security (children’s grades and payment data), functional suitability (a wrong amount costs money and trust) and reliability (a lost or double payment in the deadline week). Performance efficiency is also a defensible choice because of the deadline-week peak; a good answer ties every choice to a fact in this context.
Implied need: the finance team needs online payments to match the bank statement every day, although the requirement only mentions parents.
Frequently asked questions
Is software quality the same as having no defects?
No. Defects reduce quality, but a product with no known defects can still be slow, hard to use or built for the wrong need. Quality is judged against stakeholders’ needs, not only by counting defects.
Should I say usability or interaction capability?
Use interaction capability, the 2023 name, in new documents, and recognise usability in older material, including the ISTQB Foundation syllabus, which keeps the older name and notes the new one. The same applies to portability and flexibility.
Does a tester test all nine characteristics on every project?
No. The team chooses by risk and context. The model is a checklist so that leaving a characteristic out is a recorded decision, not an oversight. Some, such as maintainability, are assessed mainly through reviews and static analysis rather than by running the software.
Who decides what quality means for a product?
The stakeholders do, usually through the product owner, who sets priorities. Testers do not define quality on their own; they provide information about it so that others can make informed decisions.
References
- ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelThe product quality model: functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability and flexibility.
- ISTQB GlossaryThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
- ISTQB Certified Tester Foundation Level (CTFL) v4.0The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
Practise with Mutqan tools
Generate high-level test scenarios covering functional, negative, security, usability and compatibility angles for a feature.
Score features by likelihood and impact, then generate a prioritised risk-based test plan.
Generate Given/When/Then acceptance criteria and a definition-of-done checklist from a user story.
Find missing requirements — error handling, permissions, edge conditions, non-functional needs — with Mutqan AI.
Go deeper
Your progress on this topic
Not started
Mark the topic complete when you have studied it and done the exercise.
Sign in to track your progress
Mark topics complete, continue where you left off and unlock specialisation exams.