QA vs QC: Quality Assurance vs Quality Control

QA and QC are two of the most confused acronyms in software. People say them interchangeably, job titles blur them, and "QA team" is often shorthand for "the people who test." But Quality Assurance and Quality Control are genuinely different disciplines with different goals, and getting the distinction straight changes how a team invests in quality. This page gives the answer first, then the frame, then a side-by-side table and where testing actually fits.

The cleanest way to hold the difference in your head is a single pair of questions. QA asks: are we building it right? — is the process sound, are the standards in place, will this way of working tend to produce good software? QC asks: did we build it right? — does the product in front of us actually work, does it meet the spec, are there defects? QA operates on the system that produces the software. QC operates on the output of that system.

The most durable one-line frame is QA prevents, QC detects. QA tries to stop defects from ever being written by shaping the way the team works. QC assumes some defects slipped through anyway and goes looking for them in the built product. Prevention and detection are not competing strategies — they are two halves of the same goal, applied at different moments in the lifecycle.

Per the American Society for Quality, QA is about the process used to create a deliverable, while QC is about the inspection of the deliverable itself. The ISTQB glossary frames quality assurance as the part of quality management focused on providing confidence that quality requirements will be fulfilled — confidence built into the process, not verified after the fact. That "built in versus checked at the end" split is the whole distinction in a sentence.

This is where most confusion starts. Testing is a QC activity — running a test case, doing an inspection, or exploring a feature to find failures are all ways of detecting defects in something that already exists. But testing does not float free: it is part of an overall QA process. The standards that decide what gets tested, the entry and exit criteria for a release, and the loop that feeds test results back into better practices are all QA.

So a tester performs QC work inside a QA system. Both matter, and they hand off to each other constantly. Concretely, the two disciplines break down like this:

• QA activities (prevention, process): defining coding standards, running code reviews, setting up CI/CD gates that block bad merges, adopting shift-left practices so quality is considered earlier, and conducting process audits.
• QC activities (detection, product): running test cases, exploratory testing, user acceptance testing (UAT), inspections, and filing bug reports on what you find.

QA and QC are not the top of the hierarchy — they both sit under Quality Management. Quality Management is the overall discipline of directing an organisation with regard to quality; QA and QC are two functions within it. In the ISO 9000 family of standards, quality assurance is defined as the part of quality management focused on providing confidence that quality requirements will be fulfilled, while quality control is the part focused on fulfilling quality requirements — that is, the actual checking. Same parent, different jobs: one builds confidence in the process, the other verifies the result.

This is why treating QA and QC as synonyms quietly costs teams. If "QA" in your org only ever means "someone tests it at the end," you have a QC function wearing a QA label and no one is actually improving the process that keeps producing defects.

The reason to keep these straight is not pedantry — it changes where you invest. Consider the two failure modes:

• Great QC, no QA. You test thoroughly and catch a lot of bugs, but nothing improves the process that produces them. You catch the same class of defect release after release, forever. Detection without prevention is a treadmill.
• Great QA, no QC. You have strong standards, reviews, and pipelines, so you assume the product is good — but you never actually verify it against reality. Prevention without detection is faith. Process discipline reduces defects; it does not eliminate them, and the ones that slip through ship unseen.

The takeaway is the same one the tldr opened with: you need both. QA lowers the rate at which defects are created; QC catches the ones that still get through and — crucially — feeds what it learns back into QA so the process gets better over time.

Capture tooling lives on the QC side of the line: it is part of how you detect and document defects in a built product. When QC finds a bug, the value of that finding depends entirely on how reproducible it is. A one-line "checkout is broken" report gives the process nothing to learn from. BugMojo makes each found defect reproducible — an rrweb session replay, the console errors, and the failing network requests captured at the moment the bug happens. That reproducibility is what lets a QC finding feed cleanly back into QA: a well-evidenced defect is one you can trace to a root cause and turn into a better standard, a new test, or a tighter pipeline gate, so the same class of bug does not come back. QC finds it; good evidence is what turns the find into process improvement.