Testing, QA, and QC

Job ads say QA. Teams say testing. Textbooks add a third word, QC, and most people outside the field — and plenty inside it — use all three as if they were the same. They're related, but they are not the same, and the difference is so commonly asked about in junior interviews that getting it straight is the first easy win of your career.

Here's the short version to hold onto while we unpack it: testing is an activity, quality control is a goal for the product, and quality assurance is a goal for the process. One sits inside the next, like nesting dolls.

Testing: Examining the Software

Testing is the hands-on part: actually examining the software — running it, probing it, feeding it inputs — and comparing what it does against what it should do. When you enter a promo code and check that the price dropped by exactly 15%, you are testing. It also includes examining things without running them — reading a requirement and spotting a contradiction is testing too, as you'll see in Chapter 3. But the heart of it is always the same comparison: expected versus actual.

Quality Control: Checking the Product

Quality control, or QC, is the broader goal that testing serves: checking the product for defects before it reaches customers. Testing is the main QC activity in software, but QC is the umbrella — it's about the thing being built. A factory inspector examining finished cars is doing quality control; so are you, examining a Fernway release before it ships.

Quality Assurance: Improving the Process

Quality assurance, or QA, is wider still — and this is where the nesting doll gets interesting. QA is about improving the process that produces the product, so that defects are prevented, not just found. If testers keep catching the same kind of mistake — say, ambiguous requirements that two developers read two different ways — QA asks: what should change about how we write requirements, so this stops happening?

A restaurant makes the difference easy to feel. Tasting each dish before it leaves the kitchen is quality control — you're checking the product. Redesigning the kitchen so dishes stop coming out wrong — clearer recipe cards, labeled shelves, a rule that two cooks never season the same pot — is quality assurance. The tasting catches tonight's mistakes; the redesign prevents next month's. A serious restaurant does both, and so does a serious software team.

What Testing Can Never Prove

One more distinction, and it's the deepest one on this page. A passed test does not prove the feature is correct. It proves exactly one thing: this particular check didn't fail. Remember from the last topic that even a small form has more possible situations than anyone can examine — so every test you run is one sample from an ocean. Finding a defect proves a defect exists. Finding nothing proves only that you didn't find anything.

This isn't pessimism; it's the professional ground rule. Testing demonstrates the presence of defects, never their absence. Say that sentence in an interview and you'll sound like you've done the job. It's also the first of seven principles that get the whole next topic.

So What Does "QA Engineer" Mean on a Real Team?

If QA is about process, why is the person who tests all day called a QA engineer? Honest answer: job titles are looser than textbooks. On most teams, "QA engineer" means someone who does testing plus a growing share of process influence. Your first weeks at Fernway will be nearly all testing — probing the booking flow, reporting what you find. But by the end of this book you'll also be doing genuine QA: changing how the team reviews requirements so that the double-discount refund from last topic can't quietly happen again. The title describes the direction the role grows in, not just what it does on day one.

So when this book says "tester," it means the activity; when it says "QA engineer," it means you — the person hired to test today and to improve the process over time.