QA vs QC (Quality Assurance vs Quality Control)

Quality control inspects the product; quality assurance improves the process that makes it. QC catches the defective unit before it ships; QA asks why the process produced it and fixes that. The confusion is expensive: organisations with inspection only are doomed to keep finding what they should have prevented.

What It Is

Quality control (QC) is product-oriented detection: inspecting, testing, and sorting output — catching defects before release. Quality assurance (QA) is process-oriented prevention: defining standards, reviewing practices, analysing defect patterns, and improving the system that produces the software, so entire classes of defect stop occurring. In software terms, QC is the test cycle; QA is the engineering discipline around it — code review standards, definition of done, CI quality gates, root-cause analysis, the retrospective loop. The lineage is manufacturing (Deming's insight that quality is built into process, not inspected into product), and software spent decades learning the same lesson.

Why It Matters to You

The QA/QC lens gives executives the right question when defect rates disappoint: 'what in the process permits this class of defect?' — versus the reflex question 'why didn't testing catch it?', which is QC thinking, and which leads to more inspection, more test cycles, and the same defects next quarter. The mature posture is both: QC as the safety net (some inspection always), QA as the engine (defect patterns fed back into process changes). In vendor evaluation, ask what changes after a defect escapes: a new test case is QC; a changed practice is QA. Teams that only ever add tests are treating symptoms professionally.

When You'll Meet It

In quality reviews and post-incident processes. After the next significant defect, ask both questions in sequence — and note which one the organisation's answer habitually is.