QA vs testing vs quality control: they are not the same

A team says "we have QA" and almost always means "we have someone who tests the app before we ship it". That is not QA. That is testing, and not even all of testing. The confusion sounds harmless until the bill arrives: you hire a tester thinking you bought a quality process, you measure defects found thinking you measure quality, and you are surprised when the same bugs come back release after release.

QA, testing and quality control are three distinct things that work together. One prevents, another verifies, another inspects. Keeping them apart is not textbook purism: it is what tells you who to hire, what to measure and at what point in the project to act. Here I take them apart one by one and leave you the table you can pin on the team wall.

01 · the processQA is prevention: it deals with how things are built

Quality Assurance is a process approach. It does not look at the finished product: it looks at the way it is produced. Its question is not "is this version fine?", but "are we working in a way that keeps defects from appearing?". That is why it is preventive and why it happens throughout the entire cycle, not at the end.

QA sets standards, defines how code is reviewed, how requirements are documented, what criteria a story must meet to be considered ready. When QA works, many defects never even come to exist because the process closed them off beforehand. The ISTQB puts it plainly: quality assurance focuses on following suitable processes to give confidence that the expected quality will be achieved [1].

QA does not inspect the cake. It inspects the recipe, the oven and the hand of whoever cooks.

This has an uncomfortable consequence for whoever is hiring: you cannot "add QA" at the end of a project and expect miracles. If the process was chaotic for six months, dropping in one person the final week does not assure quality, it only measures it. QA is a decision made at the start and sustained all the way through.

02 · the activityTesting is verification: it runs the product to find failures

Testing is a concrete activity: running the software with the intent to find defects and to check that it does what it should. It is dynamic by nature: it runs the system, feeds it inputs, observes outputs and compares them against what was expected. Testing is one of the tools of quality control, not a synonym for quality itself.

Here it is worth recalling an old and still ignored principle: testing shows the presence of defects, never their absence. Finding zero bugs does not mean the software is perfect; it may mean you tested little or tested badly [1]. That is why "how many test cases passed" is a metric that misleads when read on its own.

Testing is not a single thing either. There are tests that verify the code from the inside (unit, integration) and tests that validate visible behavior (system, acceptance). A tester executes and reports; a good tester designs what to test so that each test counts. But even the best testing is still verification at the end of the chain, not prevention at the source.

03 · the inspectionQuality control is detection: it inspects what is already built

Quality Control is detection. It is inspection oriented to the product: it takes what has already been built and checks whether it meets the defined quality criteria. While QA asks "is the process good?", QC asks "does this specific result comply?". It is reactive by design: it acts on something that already exists.

Testing is the main activity of QC, but QC is broader: it includes product reviews, inspections, verification against specifications and acceptance criteria. The ISO/IEC 25010 standard contributes the vocabulary here that makes inspection serious: it defines a product quality model with measurable characteristics such as functional suitability, reliability, usability, security and maintainability [2]. Without that model, "does it comply?" is an opinion; with it, it is a measurement.

04 · the tableWho does what, when and with what mindset

Placed side by side, the three stop being confused. QA is the process umbrella; QC is the product inspection; testing is the concrete activity that feeds QC. The relationship is not one of rivalry but of fit: testing serves quality control, and quality control lives inside quality assurance.

You hire wrong when you ask for QA and describe a tester. You measure wrong when you count tests and think you count quality.

The practical consequence is twofold. First, in hiring: if your process is a mess, a tester will not fix it; you need someone to work the process (QA). If your process is healthy but you need to find failures before delivery, you need someone to run tests (testing/QC). They are different profiles and different moments. Second, in metrics: "defects found" measures QC activity, not process quality. A good QA indicator is the opposite: defects that did not occur because the process prevented them, something you see in the trend of defects escaping to production over time, not in a count of tests executed.

That these terms get used as synonyms in meetings is not a matter of pedantry. It is serious because each answers a different need, and mixing them makes you spend on what was not it and measure what does not matter. Separate them and suddenly you know who to call, at what moment and what number to watch.