Quality control versus quality assurance

Quality is achieved by four things, not one

Quality does not appear. It is produced by four broad activities working together. Software engineering methods — understanding the problem and designing against it, so the thing being built is capable of quality in the first place. Project management techniques — estimation that makes the delivery date achievable, schedule dependencies respected instead of short-circuited, risk planning so that a surprise does not turn into chaos; every one of those, done badly, destroys quality no matter how good the engineering is. Quality control actions. And a quality assurance infrastructure over the top. Modern practice adds a fifth, defect prediction: statistical and machine-learning models over historical metrics that flag which components are likely to be defect-prone, so review and test effort can be aimed rather than spread.

Quality control acts on the work product

Quality control is the set of software engineering actions that keep each work product inside its quality goals. Models are reviewed for completeness and consistency. Code is inspected before testing starts. A series of testing steps hunts errors in logic, data handling and interfaces. Crucially, quality control is a feedback loop: measurement of the work product feeds back into the process, so that when an artefact misses its goals the team tunes how it is producing artefacts. That is variation control — the same idea manufacturing has used for a century, applied to documents and code. Testing is quality control. Reviews are quality control. Inspection is quality control.

Quality assurance acts on the process and the evidence

Quality assurance establishes the infrastructure that supports the methods, the management practice and the control actions — and then adds an audit-and-report function on top, whose job is to judge whether those control actions are effective and complete. Its goal is to give management and technical staff the data they need to be genuinely informed about product quality, so that confidence in the product is evidence-based rather than felt. If the data show a problem, acting on it is management's responsibility, not the auditor's. Note the asymmetry that the exam is testing: quality control finds defects; quality assurance finds out whether defect-finding is working.

What the SQA function covers

The software quality assurance function reaches across ten concerns: standards (ensuring the adopted ones are followed and work products conform), reviews and audits (audits being reviews performed by SQA people to check that the guidelines are being followed — an audit of the review process is the canonical example), testing (ensuring it is planned and conducted so it can actually achieve its goal), error and defect collection and analysis, change management, education, vendor management, security management, safety, and risk management. Read that list twice: almost none of it is testing, which is the single most common misconception about the term.

Worked example — the week BorrowBox's reviews stopped working

The BorrowBox team reviews every pull request; that is quality control, and for two releases it worked. Over the next three releases the review pass rate stays at 100% while defects escaping to members climb. Nothing in the control loop can see this, because every individual review came back clean. Quality assurance is what notices. The audit samples twelve reviews and finds a median preparation time of four minutes, no checklist in use, and reviewers assigned by whoever was free; it computes defect removal efficiency across the three releases and reports that it has fallen from 0.82 to 0.55. The output is not a fixed defect — it is a report that lets the sponsor fund a checklist per work-product type and a preparation-time floor. Quality control found defects. Quality assurance found out that defect-finding had quietly stopped working.