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

Shawn West
Feb 19
8 min read

Updated: Aug 10

A team that swore it "did QA" still shipped a bug that gave customers free money. The problem wasn't effort — it was that QA, QC, testing, and quality engineering act at four different moments, and the team was only running one of them. Here's what each word actually means, the same defect caught or missed at each layer, and how to tell which one your own team is short on.

(Developed example — composite scenario.) A small team ships a checkout page. They test it. Someone clicks through the flow, adds an item, pays, sees the confirmation. It works. Two weeks after launch, finance notices the numbers don't add up: a handful of orders came through with negative totals, and the system dutifully turned the difference into store credit. Customers had found that stacking two coupons on a cheap order pushed the total below zero — and the software paid them for shopping.

Ask that team what happened and you'll hear, "But we had QA. Someone tested it." Both halves of that sentence are true, and together they explain the bug. They tested — they ran the software and it behaved on the one path they tried. What they didn't have was any of the other three things the word "QA" is quietly standing in for. The four terms get used as if they're synonyms, and when a team can't tell them apart, work falls through the gaps between them.

So here is each word, what it actually means, and when it acts — because that, more than any dictionary difference, is what separates them. We'll carry one example the whole way through: the checkout page above, and that coupon defect.

Testing: did this specific thing work, right now?

Testing is the narrowest of the four and the easiest to picture. You run the software and compare what it does against what it should do. You add an item, 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 a person or a script does — not a department and not a philosophy. You can test by hand or with automation, but either way testing answers exactly one question: does this behave as expected, on the path I just exercised?

That last clause is the catch. Testing only ever tells you about the cases you actually run. Our team tested the happy path — one item, one valid card — and it passed. Nobody ran the "two coupons on an $8 order" path, so the test suite was silent about it. Testing is essential and it is also reactive: by the time you're testing, the code is already written, and you only learn about the scenarios you thought to try. (If you're new to the activity itself, Your First Week as a Software Tester walks through what testing looks like day to day.)

Quality Control (QC): is this build correct before it ships?

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 real users touch it: running the full test suite on every commit, reviewing the UI against the design, confirming the order email really sends.

The defining trait of QC is that 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." Crucially, QC acts late: it runs on finished or nearly-finished software, right before release.

Here's what matters about that timing. If QC is all you have, you live permanently in catch-up mode — you find defects at the very end, under deadline pressure, and scramble to fix them. Strong QC might well have caught the coupon bug, if someone had thought to test negative totals. But notice what QC can never do: it can't stop the code that allows a negative total from being written in the first place. For that, you have to act earlier.

Quality Assurance (QA): is our process built to prevent this?

Quality assurance is about the process, not the product — the practices that make a defect less likely to exist at all. QA is proactive where QC is reactive, and it acts before the code is written.

On the checkout page, QA is not the test. It's the decisions made before anyone typed the pricing logic: a definition of "done" that requires error handling for edge cases, acceptance criteria written up front that say the order total can never be less than zero and no more than one coupon applies per order, a code-review standard that puts a second pair of eyes on money-handling logic. Any one of those would have caught the coupon defect before it became code — not because someone tested cleverly, but because the rule existed before the mistake could.

Here's the mental model that makes QA and QC click apart: QC is checking the cake; QA is improving the recipe and the kitchen so fewer bad cakes get made. QC finds the bad cake at the end. QA means the bad cake mostly never comes out of the oven.

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 catches the survivors faster, because the process is built to catch them.

Quality Engineering: build all three 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 checkpoint bolted on. Quality engineering rejects that handoff. It says quality is everyone's job, built in continuously, and supported by engineering: automation, tooling, and infrastructure.

On our checkout page, a quality engineer doesn't wait at the end to test. They build the automated suite that runs on every commit, the CI gate that blocks a merge if the checkout tests fail, the test-data setup that lets anyone spin up a realistic cart in seconds, and the monitoring that would have flagged a negative-total order in production within minutes instead of two weeks. They make it easy for the whole team to prevent and catch defects, and hard to ship something broken. Quality engineering is the system that wires testing, QC, and QA together so they run automatically, rather than depending on someone remembering to do them.

The four, side by side

They aren't competing — they nest, and each acts at a different moment. Read this table by the "When it acts" column; that's where the real difference lives.

Term	What it is	When it acts	What it catches	How you'd notice it's weak
Testing	An activity: run the software, compare to expected	During and after coding	Whether the paths you tried behave correctly	Bugs appear on paths nobody thought to run
QC	Inspecting the finished product	Late — before release	Defects that made it into the build	Everything's found in a crunch right before ship
QA	Shaping the process to prevent defects	Early — before code exists	Whole classes of defect, before they're written	No definition of done or acceptance criteria; same bugs recur
Quality Engineering	The system that automates all three	Continuously, on every change	Prevention and detection, without relying on memory	Quality depends on one heroic person, not the pipeline

Testing is part of QC; QC and QA are both part of what quality engineering automates. A healthy team runs all four. Most struggling teams run only the first two — and that pattern has a name and a tell.

How to tell if your team is QC-heavy and QA-thin

Our checkout team wasn't lazy. They were doing the two things that feel like productivity — testing and inspecting — and skipping the two that happen before anything visible exists. That's the most common and most expensive imbalance in software, and you can diagnose it in your own team this week without any tools:

Look at when your bugs are found. Skim your last dozen or two defects and ask, for each: was it caught before the code was written, or during a test-and-fix scramble near release? If almost everything clusters at the end, you're detecting late (QC) and preventing little (QA).
Listen to how planning sounds. If the recurring answer to quality problems is "we need more testing," that's the tell. More testing at the end is more QC. It finds the coupon bug on the twentieth try instead of the first; it never stops the bug from being written.
Check whether "done" is defined before work starts. Ask where your acceptance criteria and definition of done live. If the honest answer is "we sort of know it when we see it," you have almost no QA — quality is being decided after the code exists, which is exactly too late to prevent anything.

This is where the ShiftQuality view is blunt: quality starts before code, not after it. The coupon defect wasn't a testing failure — a test would only have found it if someone already suspected negative totals. It was a discovery failure. Nobody, early on, asked the plain question "what's the lowest a total can go, and what should happen there?" That question costs one sentence in an acceptance criterion and would have erased the bug for free. Found in production, the same gap cost real money and a fire drill. (For what "quality" even buys you once you look past "it works," see What Is Software Quality? Beyond 'It Works'. And because not every defect deserves the same panic, What Is a Bug, Really? Severity vs Priority is worth reading alongside this.)

What to do this week

Don't reorganize your team or hire a "quality engineer" on the strength of one article. Do one small thing that shifts effort earlier:

Pick the next feature your team is about to build. Before a line of code is written, spend ten minutes writing down what "done" actually means for it — including the ugly edge cases ("the total can never go below zero," "a coupon applies at most once"). That single note is QA: it's you moving one gate to the left, from catching the defect to preventing it. Then watch, over the next few features, whether the same class of bug stops reaching your release crunch.

The four words aren't trivia. Testing tells you if the path you tried works. QC tells you the build is correct before it ships. QA shapes the process so the defect never gets written. Quality engineering makes all three run on their own. If your team only ever talks about the first two, you now know exactly which half you're missing — and the cheapest place to start closing the gap is the sentence you write before the code, not the bug you find after it.

Frequently Asked Questions

What's the difference between QA and QC?

Quality Assurance (QA) works on the process to prevent defects before they happen — a definition of done, acceptance criteria, a review standard. Quality Control (QC) inspects the finished product to catch defects that slipped through — running the test suite, checking the build against the design. QA asks 'is our way of working sound?'; QC asks 'is this specific build correct?' QA acts before code exists; QC acts after.

Is testing the same as QA?

No, though the words get swapped constantly. Testing is one activity — running the software to see whether it behaves as expected. QA is the broader discipline of shaping the process so quality is built in, and testing is only one part of that. A team can test heavily and still have almost no QA, because testing happens after the code is written and QA happens before.

What is quality engineering?

Quality engineering treats 'make quality fast and automatic' as an engineering problem. Instead of a separate team inspecting finished software, a quality engineer builds the test frameworks, CI gates, and monitoring that let the whole team prevent and catch defects continuously. It's the system that wires testing, QC, and QA together so they run on every change without someone remembering to do them.

How can I tell if my team is QC-heavy and QA-thin?

Look at when your defects are found. If almost every bug surfaces during a test-and-fix crunch right before release, and your planning conversations are about 'more testing' rather than clearer acceptance criteria or definitions of done, you are detecting late and preventing little. A prevention-strong team finds fewer bugs at the end because fewer were created, and catches the rest earlier.

ShiftQuality