Quality is the degree to which a set of inherent characteristics fulfils requirements. Read plainly, that makes quality a comparison against something written down, which is why quality management begins in the requirements rather than in the testing.
Practitioners supply a second half of the definition from experience. A deliverable meeting every stated requirement while being useless to the person who has to work with it has satisfied conformance and failed fitness for purpose, so both readings are needed and neither is sufficient alone.
Conformance and fitness for purpose
Conformance to requirements means the product does what the specification said. It is objective, testable and the basis of any acceptance decision, and without it no other quality claim survives a dispute.
Fitness for purpose means the product satisfies the real need. It is the check on whether the requirements were the right ones, and it fails in a distinct way, since a project can meet its specification exactly and still deliver something nobody uses.
Requirements that were never made measurable are where most quality arguments start. A stated need for a fast report generates disagreement forever, whereas a need for a report returning within four seconds at a defined data volume can be tested and settled.
Prevention costs less than inspection
Quality is planned in rather than tested in. Inspection finds defects that already exist and pays for the work that produced them, while prevention keeps them out of the product.
The economics come from how the cost of a defect grows with the delay in finding it. A requirement misunderstood and caught in review costs a conversation. The same misunderstanding caught in testing costs the design, the build and the retest as well. Caught in production it costs all of that plus the incident, the customer relationship, and an emergency change that goes in without the usual care.
The growth is roughly multiplicative at each stage, which is why moving detection one stage earlier is worth more than making later detection more thorough.
The cost of quality
Cost of quality is the total cost of conformance and nonconformance across the life of the deliverable, including the part that lands after handover.
One defect, priced four times. Left of the dashed line the project is spending its own money on its own schedule, and right of it the spending is unplanned, urgent, and increasingly somebody else's budget.
Conformance costs are prevention and appraisal. Prevention covers training, documented process, tooling and design reviews, meaning everything spent to stop defects existing. Appraisal covers testing, inspection and audit, meaning everything spent to find the defects that do exist.
Nonconformance costs are internal and external failure. Internal failure is rework and scrap found before delivery. External failure is warranty work, support cost, liability and lost business found after it, and it is the expensive category by a wide margin.
| Category | What the money buys | Example on one payment defect | Cost |
|---|---|---|---|
| Prevention | Stops the defect coming into existence | Two hours of design review on the payment interface, plus the checklist that came out of it | £200 |
| Appraisal | Finds the defect that already exists | The automated suite, the exploratory session and the release inspection | £800 |
| Internal failure | Repairs what was found before delivery | Rework, retest, the scrapped build and the slipped release date | £4,000 |
| External failure | Repairs what was found after delivery | Emergency release, support calls, a credit to the customer, the incident review and an account that renews smaller | £40,000 |
The figures rise between fourfold and tenfold at each step, and the step across handover is the steepest of them. That shape is what makes the argument for prevention economic rather than moral, since £200 spent to remove a one in ten chance of the £40,000 outcome buys away £4,000 of expected cost and returns twenty times what it cost.
The reason to model all four is that they trade against each other. Cutting prevention and appraisal reduces cost visibly and immediately, and the saving reappears as external failure later, in a budget that usually belongs to somebody else. That accounting split is why underinvestment in quality is so easy to justify from inside a project.
Assurance looks at the process, control looks at the product
Quality assurance audits whether the processes being followed are capable of producing a conforming deliverable, and it improves those processes where they are not. Its subject is the way the work is done.
Quality control measures deliverables against the requirements and produces verified deliverables along with the measurements themselves. Its subject is the output.
They answer different questions, and the difference is worth being precise about. Control tells you this deliverable is correct. Assurance tells you the next one is likely to be correct as well, because the process that produced it is sound. A project relying only on control finds every defect one at a time and never learns why they keep appearing.
Control also feeds assurance. The measurements control produces are the evidence assurance uses to decide which processes need changing, so the two work as a loop rather than as separate departments.
Grade and quality are different scales
Grade is a category assigned to deliverables with the same functional use but different technical characteristics, meaning how much the thing does. Quality is how well it does whatever it claims to do.
Because the two scales are independent, all four combinations exist, and only half of them are a problem.
| Quality | Low grade | High grade |
|---|---|---|
| High | A basic utility that does its limited job reliably every time, which is a perfectly good decision | A capable product that also works as specified, which is what a large budget is supposed to buy |
| Low | A basic utility that fails at even its limited job | A capable product loaded with features that crash, and the most expensive way to fail |
Low grade is often perfectly acceptable, because a basic model chosen deliberately and specified as basic is a legitimate decision. Low quality is never acceptable, because it means the deliverable does not meet its own stated requirements.
Confusing the two produces the argument in which somebody defends defects by pointing at the budget. The budget explains which column a deliverable belongs in, and it has no bearing at all on which row.