QA vs QC vs Testing vs Quality Engineering: The Words, Explained

Contributor
Feb 19
5 min read

Sit in on any sprint planning and you'll hear all four terms used in the same breath, as if they mean the same thing. "QA will catch it." "We need more QC." "That's a testing problem." "We should engineer quality in." Everyone nods. Nobody's quite sure they're talking about the same thing — and half the time they aren't.

This isn't pedantry. When a team can't tell these four apart, work falls through the cracks: defects ship because everyone assumed "QA" covered something it didn't. So here's each term, what it actually means, and a single example carried through all four so the differences are obvious.

The example: you're building a checkout page for an online store.

Testing: did this specific thing work?

Testing is the narrowest of the four and the easiest to picture. You execute the software and compare what it does against what it should do. You add an item to the cart, enter a card, click pay, and check that the order goes through and the total is right.

That's a test. It's an activity — something you do — not a department or a philosophy. You can test manually (clicking through yourself) or automatically (a script that does it for you). Either way, testing answers one question: does this behave as expected, right now?

Testing is essential, but it's also reactive. By the time you're testing, the code is already written. If the checkout logic was wrong, testing finds the symptom — it doesn't stop the wrong code from being written in the first place. That's where the bigger ideas come in.

Quality Control (QC): is this build correct?

Quality control is inspection of the product. It's the umbrella over testing, plus everything else you do to verify the actual thing you built before it reaches users. Running the full test suite on the checkout page, having someone review the UI against the design, checking that the order email actually sends — that's QC.

The defining trait of QC: it looks at the real output. It's checking the cake after it's baked. On our checkout page, QC is the gate that says "this specific build of the checkout flow has been verified and is good to ship." It catches defects that made it into the product.

QC is necessary, but if it's all you have, you're permanently in catch-up mode — finding bugs at the end and scrambling to fix them under deadline pressure. The goal is to need it less. Which brings us to QA.

Quality Assurance (QA): is our process sound?

Quality assurance is about the process, not the product. It's the set of practices designed so that defects are less likely to happen in the first place. QA is proactive where QC is reactive.

On the checkout page, QA isn't testing the page — it's the decisions that made the page more likely to be right before anyone tested it: a clear definition of "done" that includes error handling, a code review standard that requires a second pair of eyes, acceptance criteria written before coding started so everyone agreed what "correct" means, a rule that payment logic needs automated tests.

Here's the mental model that makes QA vs QC click: QC is checking the cake; QA is improving the recipe and the kitchen so the cake comes out right more often. QC finds the bad cake. QA means fewer bad cakes get made.

A team strong on QC but weak on QA finds lots of bugs late. A team strong on QA finds fewer bugs because fewer were created — and the ones that remain are caught faster because the process is built to catch them.

Quality Engineering: build quality into the system

Quality engineering is the newest term and the one reshaping the field. The old model was a separate QA team that received "finished" software and inspected it at the end — a quality checkpoint bolted onto the process. Quality engineering rejects that handoff. It says quality is everyone's responsibility, built in continuously, and supported by engineering: automation, tooling, and infrastructure.

On the checkout page, a quality engineer doesn't sit at the end waiting to test. They build the automated test suite that runs on every commit, the CI pipeline that blocks a merge if checkout tests fail, the test-data setup that lets anyone spin up a realistic cart in seconds, the monitoring that catches a payment error in production within minutes. They make it easy for the whole team to produce quality work and hard to ship something broken.

Quality engineering folds testing, QC, and QA together and treats "make quality fast and automatic" as an engineering problem in its own right. It's why you'll see the job title "Quality Engineer" or "SDET" (Software Development Engineer in Test) where you used to see "QA Tester."

The one-line version

Testing — execute the software to see if it behaves correctly. (An activity.)
QC — inspect the actual product to catch defects before release. (Checking the cake.)
QA — design the process so defects are prevented. (Improving the recipe.)
Quality Engineering — build quality into the system with automation, as a shared responsibility. (Engineering the kitchen.)

They nest: testing is part of QC, QC and QA are both part of quality engineering's broader scope. They're not competing — a healthy team does all four.

The mistake to avoid

The most common and most expensive mistake is leaning entirely on the narrow end — testing and QC — while ignoring QA and quality engineering. It feels productive (you're finding bugs!) but it's a treadmill: you find defects late, fix them under pressure, ship, and repeat. Real improvement comes from shifting effort left — investing in process and automation so fewer defects exist to find.

If your team only ever talks about "more testing," that's the tell. The leverage isn't in testing harder at the end. It's in the recipe and the kitchen.

Where to go next

Now that the words mean something, the natural next question is why we bother at all — what quality actually buys you and how to think about it without drowning in process.

New to all of this? Start with the Start Here path — it builds from these definitions up to running real quality work, one short article at a time.

ShiftQuality