QA Fundamentals # 2 - QA vs QC vs Testing vs Quality Engineering

A release goes out. Two days later, customers complain that scheduled orders arrive 40 minutes late.

In the retro, the first question is the familiar one: “Why didn’t QA catch this?”

But QA did test it. Every check against the spec passed. The spec itself said “start preparing at the scheduled time” when users meant “arrive by the scheduled time.” No amount of end-of-sprint testing would have caught that, because the tests were checking the wrong expectation.

The bug wasn’t a testing failure. It was a requirements failure that nobody owned.

Moments like this happen when a team uses QA, QC, testing and quality engineering as if they meant the same thing. They don’t, and mixing them up quietly puts the whole burden of quality on the people at the end of the line.

The short version

One line to remember them by:

Testing finds out. QC checks. QA prevents. QE builds it in.

Testing: finding out

Testing is the activity of evaluating a product to learn how it behaves. You run scenarios, explore edge cases, compare results with expectations and report what you found.

It is investigative by nature. A good tester doesn’t only confirm that things work. They ask “How can this fail?” and bring back evidence.

Testing is essential, but it is one activity, not the whole of quality.

QC: checking the product

Quality Control is about inspecting the product against a standard before it goes out. Testing is the main tool QC uses in software, alongside reviews of outputs and release checks.

A kitchen makes this easy to picture: QC is the chef tasting the dish before it leaves the pass. It stops a bad plate from reaching the customer.

But QC has a limit. It detects defects after they’re made. If the same problem shows up every sprint, faster detection won’t fix it.

QA: improving the process

Quality Assurance is about the process that produces the product. In the kitchen, it’s the standard recipes, hygiene training and fridge temperature checks. It stops the bad dish from being made at all.

In software, QA work includes:

• Reviewing requirements before development starts

• Agreeing a definition of done

• Setting a test strategy based on risk

• Making sure error handling and edge cases are specified

• Spotting patterns across defects and fixing their cause

Here’s the important part: you can do QA without running a single test. Asking “how fast is fast, on what network?” during refinement is QA. No test was run, and a defect was still prevented.

That’s also why a “QA team” that only tests builds at the end of the sprint is really a test team with a different name. It’s valuable work, but it’s half the job.

Quality Engineering: building it in

Quality Engineering moves quality from a process people follow to systems that check it automatically:

• Automated checks running on every commit

• Shared test frameworks, test data and environments

• Contract tests between services

• Quality gates in the CI/CD pipeline

• Production monitoring and alerts

• Visible quality metrics, such as escaped defects and flaky-test rate

The question changes from “Did we follow the process?” to “Does our system tell us, quickly and reliably, when quality is slipping?”

Two cautions are worth stating plainly:

1. QE doesn’t replace QA thinking. A pipeline full of checks is only as good as the decisions about what to check.

2. A title change isn’t QE. If the work is still manual regression at the end of the sprint, only the label changed.

Where verification and validation fit

These two terms cut across everything above.

• Verification: did we build what the spec said?

• Validation: did we build what the user actually needed?

Back to the scheduled-order story. Verification passed completely: slots worked, past times were blocked, the 2-day limit held. Validation failed: users picked 1:00 for lunch, and their food arrived at 1:40.

Verification mostly happens through reviews and testing against requirements. Validation happens through UAT, beta users, usability sessions and production data. A team that only verifies will ship exactly what was written down, including the mistakes in what was written down.

So who owns quality?

“Everyone owns quality” is true, but it’s only useful once each part has an owner:

QA doesn’t own the final verdict on quality alone. One team can’t inspect quality into a product that others designed and built. QA’s real job is making sure the team never ships blind: it knows what it’s releasing, risks included.

What this means for your work

You don’t need a new title to use these distinctions. Start with three habits:

1. Look for patterns in your bugs. If several share a root cause, raise the process fix, not just the defects. That’s QA work.

2. Ask one question before code is written. “What should happen if this fails?” in refinement prevents more bugs than any regression run.

3. Map your checks. Mark each quality check as manual, automated or monitored in production. The ratio shows where you are on the path from QA to QE.

How to answer this in an interview

If someone asks, “What’s the difference between QA, QC and testing?”, here’s an answer that shows real understanding:

“Testing is the activity of evaluating the product. QC uses testing to check the product against a standard before release, so it’s detective. QA focuses on the process, like requirement reviews and a definition of done, to prevent defects in the first place. Quality engineering builds those checks into the delivery pipeline so quality is measured continuously, not just at the end.”

Then give one example from your own work of preventing a defect rather than finding it. That’s what separates a strong answer from a memorized one.

The takeaway

These four terms aren’t competing labels. They are layers of the same goal:

Testing finds out. QC checks. QA prevents. QE builds it in.

Teams that blur them end up asking “Why didn’t QA catch this?” Teams that separate them ask a better question: “Where in our process should this have been caught, and whose part was it?”

Your turn: In your team, which of these four does your role really cover, and which does it get blamed for? Reply or leave a comment. I’d like to hear it.

This is part of the QA Fundamentals series. Next: Error, Bug, Defect, Failure and Incident: Finally Explained