QA vs QC vs Testing (and verification vs validation)
Three words people mix up every day, made crystal clear with a restaurant-kitchen analogy, plus the classic verification-vs-validation distinction.
Three phrases get thrown around as if they're the same thing: quality assurance, quality control, and testing. They overlap, people use them loosely, and that's usually fine in casual talk. But knowing the real difference makes you sound like you actually understand the field, and it genuinely changes how you think about your job. The cleanest way in is a kitchen.
The restaurant kitchen analogy
Imagine a busy restaurant that wants every plate to delight its guests.
- Quality Assurance (QA) is writing the recipes, training the chefs, and keeping the kitchen clean. It's about the process: building good habits so fewer bad plates ever happen. QA is preventive: it works on the system, not the dish.
- Quality Control (QC) is the head chef inspecting each finished plate before it leaves the kitchen, checking the cooking, the seasoning, the look. It's about the product: catching bad plates that slipped through. QC is detective: it inspects the result.
- Testing is one specific tool of QC: actually tasting the food. It's the hands-on act of trying the dish and noting what's wrong. Testing is a part of quality control, which sits inside the broader effort of quality assurance.
So they nest inside each other: testing is a part of QC, and QC is a part of QA. QA is the widest circle (improve the whole process), QC is inside it (inspect the products), and testing is inside QC (the actual trying-it-out).
| Term | Focuses on | Goal | Nature | Kitchen version |
|---|---|---|---|---|
| Quality Assurance | The process | Prevent defects | Proactive / preventive | Recipes, training, clean kitchen |
| Quality Control | The product | Find defects | Reactive / detective | Inspecting each finished plate |
| Testing | Running the software | Find specific bugs | A hands-on activity within QC | Tasting the food |
QA = Are we building it the right way? (the process). QC = Did we build a good thing? (the product). Testing = Let me actually try it and see. (the activity).
Verification vs validation
There's a second pair of terms that shows up constantly, especially in interviews: verification and validation. They sound almost identical, but they ask two genuinely different questions. The classic one-liner is worth memorising:
Verification: "Are we building the product right?" (Does it match the spec and the plan?) Validation: "Are we building the right product?" (Does it actually meet the user's real need?)
Verification
- Are we building the product right?
- Checks the work against the documents, designs, and rules.
- Often done without running the software: reviews, walkthroughs, inspections.
- Asks: does it match what we said we'd build?
- Kitchen: does this dish follow the recipe exactly?
Validation
- Are we building the right product?
- Checks the actual working software against real user needs.
- Done by running the software: executing tests, real usage.
- Asks: will this actually satisfy the person who wanted it?
- Kitchen: does the guest actually enjoy eating it?
Here's why the difference matters and isn't just word games. You can perfectly verify something (it matches the spec to the letter) and still fail validation (the spec described the wrong thing, so users hate it). That's the same lesson as the absence-of-errors fallacy from the last lesson, viewed from a fresh angle: matching the plan is not the same as solving the problem.
If an interviewer asks for the difference, lead with the two questions, then give one example: "A team built exactly what the document said (verification passed), but the document misunderstood the customer, so the product failed in real use (validation failed)." That tells them you grasp the idea, not just the wording.
- QA improves the process (preventive), QC inspects the product (detective), and testing is the hands-on activity inside QC.
- They nest: testing is part of QC, and QC is part of QA.
- Verification asks "are we building it right?" (matches the spec); validation asks "are we building the right thing?" (meets the real need).
- You can pass verification and still fail validation, because matching the plan isn't the same as solving the user's problem.