What software quality means

Five people say "quality" and mean five different things

A sponsor, a compiler author, a buyer and an auditor can all use the word in one meeting without ever colliding, because quality is describable from at least five viewpoints. The transcendental view says quality is recognisable but not definable — you know it when you use it. The user view judges by whether the product meets that user's goals. The manufacturer's view judges conformance to the original specification. The product view ties quality to inherent characteristics — the functions and features actually present. The value-based view measures it by what a customer will pay. None of them is wrong, and an answer that names two or three and then says which one the stakeholder in front of you is using has already done real work.

Quality of design versus quality of conformance

Two of those views harden into a pair worth its own sentence. Quality of design is the level a designer specifies — how completely the design covers the functions, features and performance the requirements model asked for. Quality of conformance is how faithfully the implementation follows that design and meets its stated goals. The two dissociate, and that is the point: you can build exactly the wrong thing, perfectly. Glass's corrective is worth carrying into the exam — user satisfaction needs a compliant product, good quality and delivery inside budget and schedule. A flawless system that arrives a year late satisfies nobody.

The definition that carries the marks

Software quality is an effective software process, applied so as to create a useful product, that delivers measurable value to the people who build it and the people who use it. Three clauses, all load-bearing. Effective process puts quality upstream: the planning, change management and technical reviews that stop a project thrashing are what make quality repeatable instead of lucky. Useful product means it delivers the content, functions and features the user asked for and the implicit ones nobody wrote down — ease of use is the standard example. Measurable value means the benefit is real on both sides: the producer spends less on rework and support, the user gains a capability that repays the purchase.

Factor models — what you assess against

Quality is never assessed as one lump. McCall's factors group into product operation (correctness, reliability, efficiency, integrity, usability), product revision (maintainability, flexibility, testability) and product transition (portability, reusability, interoperability). ISO 25010 restates the same ambition as eight product quality characteristics — functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, portability — and adds a quality in use model (effectiveness, efficiency, satisfaction, freedom from risk, context coverage). Assessment can be qualitative (a checklist of probing questions per factor) or quantitative (metrics that manifest quality indirectly, since quality itself is never measured directly). Pick one model, name its groups, and give one factor a worked instance.

Worked example — grading BorrowBox v1.0

BorrowBox, our neighbourhood tool library, opens the correct locker on every valid scan and has not lost a reservation in four months. Quality of conformance: excellent. Now walk the other columns. Collecting a drill takes six taps and cannot be done one-handed while carrying a toolbox, and the reservation screen fails a WCAG 2.2 AA contrast check in direct sun — usability fails, a product-operation factor. The late-fee rate is hard-coded in three classes, so moving from £2 to £1.50 per day is a three-file edit with no covering test — maintainability fails, a product-revision factor. The value destroyed is concrete: support calls, abandoned reservations, an accessibility exposure the library cannot defend. A conformant product can be a low-quality one, and naming which factor fails in which group is precisely what separates a 6/7 answer from a 3/7 one.