QA vs QC in Software: What Is the Difference?

QA and QC get used interchangeably in job titles, standups and RFPs — and the confusion costs real money. Teams hire a QA team, give it only QC work, then wonder why the defect rate never falls. The distinction is not academic pedantry: it decides who owns quality, where you spend budget, and whether your defect count trends down or stays flat forever. This guide gives the precise definitions, the comparison table, worked examples of each activity, and the practical answer to where testing actually sits.

• QA is process-oriented and preventive — it stops defects being created.
• QC is product-oriented and detective — it finds defects already in the build.
• Testing is a QC activity that operates inside the QA system: QC is a subset of QA.
• QA is everyone's job; QC is usually executed by testers — assigning both to one team is the classic anti-pattern.
• QC alone plateaus. Without QA, you find the same defect classes release after release.

What is quality assurance (QA)?

Quality assurance is the set of planned, systematic activities that make sure the process used to build software will produce a product that meets its requirements. It is about the how, not the what. QA never inspects a build — it shapes the conditions under which the build is created.

Concretely, QA is your coding standards, your definition of done, your requirement review sessions, your branching model, your CI gates, your test strategy document, your architecture reviews and your retrospective actions. When a team agrees that no pull request merges without a passing pipeline and a second reviewer, that agreement is QA. Nobody tested anything; the probability of a defect reaching main just dropped.

The mental model that sticks: QA is the recipe and the kitchen discipline. It decides ingredient quality, oven temperature, the order of steps and who checks the work. Get the recipe right and most dishes come out right — before anyone tastes them.

Because QA governs process, it cannot live inside a testing team alone. A product owner writing a vague, untestable acceptance criterion is a QA failure. A developer merging without a review is a QA failure. Both happen upstream of anyone executing a test. This is why mature organisations treat QA as an engineering-wide responsibility and why QA consulting engagements almost always start by examining process artefacts rather than test cases.

What is quality control (QC)?

Quality control is the set of activities that inspect a built product to determine whether it meets requirements. It is about the what — the actual artefact in front of you. QC is inherently reactive: it cannot run until something exists to inspect.

QC is executing test cases, running an automated regression suite, doing a smoke check on a deployed build, reviewing a rendered page against a design, running a load test against a staging environment, or verifying a bug fix. Every one of those looks at output and asks: is this correct?

Continuing the kitchen analogy: QC is tasting the dish before it leaves the pass. It is genuinely necessary — recipes are followed imperfectly, ingredients vary, and something will always slip. But tasting does not improve the recipe. If the dish is consistently over-salted, the fix is upstream, not more tasting.

QC has one property teams underrate: it produces information, not quality. A test that fails has not improved the software by one line. It has told you something. The improvement happens when a developer acts on that information — and the rate at which such information appears is governed by QA. The full software testing and quality assurance guide walks the same relationship across an end-to-end delivery lifecycle.

What is the difference between QA and QC?

The difference is orientation and timing: QA is process-oriented, preventive and runs throughout the lifecycle; QC is product-oriented, detective and runs once a build exists. Everything else follows from that.

Dimension	Quality assurance (QA)	Quality control (QC)
Orientation	Process-oriented — how software is built	Product-oriented — what was built
Goal	Prevent defects being introduced	Detect defects that already exist
Approach	Proactive	Reactive
Nature	Preventive	Detective / corrective
Responsibility	Whole team — product, dev, QA, leadership	Usually testers, SDETs or developers running checks
Timing	Throughout the lifecycle, starting before code	After a build or increment exists
Typical activities	Standards, reviews, definition of done, CI gates, audits, test strategy	Test execution, regression runs, smoke checks, defect verification
Output	A process that reliably produces quality	Information about whether this build is acceptable
Measured by	Defects created / injected per increment	Defects found, defect escape rate, coverage
Scope relationship	The wider system	A subset of QA

Read the last row carefully, because it is the one most comparison tables get wrong. QA and QC are not two peers sitting side by side. QC sits inside QA. Quality assurance defines, among many other things, what quality control will look like — which is why "we have QA and QC teams" usually describes an org chart, not a real division of responsibility.

Why is QA process-oriented and QC product-oriented?

QA is process-oriented because defects are created by process, not discovered by it. A defect exists because a requirement was ambiguous, a design missed an edge case, a developer misread a spec, or a merge skipped a review. Every one of those is a process event. Changing the process is the only lever that changes how many defects get created.

QC is product-oriented because by the time it runs, the process has finished doing its work. The build is what it is. QC can only measure the result. You can add ten more testers and find more defects; you cannot add ten testers and cause fewer defects to have been written.

This is why the two have completely different economics. QA investment compounds — a code standard that prevents a class of null-handling bug prevents it in every future sprint, forever, for free. QC investment is linear and recurring — every release needs testing again. Both are necessary, but only one of them bends the curve. Teams that plateau on quality have almost always over-invested in QC and under-invested in QA.

Is testing QA or QC?

Testing is QC. Executing a test case against a build to find defects is inspection of a product, which is the textbook definition of quality control. If you take one thing from this article, take that sentence — it resolves most of the confusion in the industry.

The nuance that makes it feel ambiguous: testing is governed by QA. Someone decided what the test strategy is, which risks justify coverage, what the entry and exit criteria are, when testing starts, and what "done" means. All of those decisions are QA. The person executing the tests is doing QC inside a frame that QA built.

ISTQB frames it as nested sets: testing ⊂ quality control ⊂ quality assurance ⊂ quality management. Each is contained by the next. So the honest answer to "is testing QA?" is: no, testing is QC — but testing happens inside QA, and the QA decisions are what make the testing worth doing. A person can be a great tester and a poor QA practitioner, and the difference shows up in whether the defect rate falls over time.

If you want the taxonomy underneath the QC layer — unit, integration, system, acceptance, functional, non-functional and the rest — the guide to types of software testing maps the full landscape, and manual testing covers the human-judgment end of it.

QA vs QC vs testing: how do the three fit together?

QA is the system, QC is the inspection function inside it, and testing is one technique QC uses. They are three nested scopes, not three departments.

	Quality assurance	Quality control	Testing
Scope	Widest — the whole delivery process	Subset of QA — inspecting outputs	Subset of QC — one inspection technique
Core question	Is the process capable of producing quality?	Does this artefact meet requirements?	Does this behaviour match the expected result?
Runs when	Continuously, from before code exists	Once an artefact exists	Once a build or component is executable
Example	Defining that every story needs testable acceptance criteria	Reviewing the built screen against the design	Running the checkout regression suite in CI
Owned by	Engineering leadership + whole team	QA function / SDETs / developers	Testers, SDETs, automated pipelines
Fails when	Process is undefined or unenforced	Inspection misses defects (escapes)	Tests are flaky, shallow or unmaintained

A useful diagnostic: if an activity would still make sense before a single line of code was written, it is QA. If it requires something to already exist, it is QC. Writing a test strategy before the sprint is QA. Writing a test case against a built feature and executing it is QC.

What are examples of QA and QC activities?

The fastest way to internalise the split is to sort real activities into the two buckets. Here is how a typical delivery team's work divides.

QA activities (process, preventive)

• Requirement and story reviews — catching ambiguity before it becomes a defect. The cheapest bug fix in existence.
• Definition of done — the shared contract for what "complete" means, including test coverage and review.
• Coding standards and linting rules — preventing whole classes of defect mechanically.
• Design and architecture reviews — surfacing edge cases and failure modes before implementation.
• Test strategy and risk analysis — deciding what deserves coverage and why.
• CI/CD quality gates — no merge without a green pipeline and a reviewer.
• Process audits and retrospectives — finding why defects keep appearing and changing the system.
• Training and onboarding standards — reducing defects caused by unfamiliarity.

QC activities (product, detective)

• Executing functional test cases against a build.
• Running the automated regression suite on every commit.
• Smoke and sanity checks on a fresh deployment.
• Exploratory testing sessions hunting unknown unknowns.
• Performance and load testing against staging.
• Security scanning of a built artefact.
• Defect verification and retesting after a fix.
• Acceptance testing — see acceptance testing for the final QC gate before release.

Notice that code review appears in the QA list, not QC — even though a reviewer is inspecting code that already exists. This is the one genuinely contested case. The reason it belongs in QA: review's primary purpose is enforcing standards and spreading knowledge across the team, which changes future output. Its defect-finding is a side effect. If you run review purely as inspection, you have turned a QA practice into a QC one and lost most of its compounding value.

How do QA and QC work together?

QA and QC form a feedback loop: QA sets the conditions, QC measures the result, and the result feeds back into QA. Neither works properly in isolation.

The loop in practice: QA defines a test strategy and a definition of done. Development produces a build. QC executes tests and finds a defect. The defect gets logged and moves through the bug life cycle to a fix. So far, this is just detection — ordinary, and it happens on every team.

The loop closes at the next step, which most teams skip: someone asks why that defect existed. Was the requirement ambiguous? Was there no unit test for that branch? Did the design miss a state? The answer produces a process change — a new lint rule, a sharper acceptance criterion, a mandatory check. That change is QA acting on QC's information, and it is the only mechanism by which defect rates fall.

A concrete pattern worth stealing: track defects not just by severity but by root-cause category (requirement gap, design gap, coding error, environment, test data). After a few sprints the distribution tells you exactly which QA practice is missing. If 40% of defects are requirement gaps, no amount of extra testing will help — fix the story-writing process. That single classification habit turns QC output into a QA roadmap.

QC tells you the process failed. QA is what you do about it. A team that logs defects but never changes the process is paying for information it refuses to use.

Why do teams confuse QA and QC?

The confusion is mostly historical and organisational, not conceptual. Three causes account for nearly all of it.

Job titles. The industry labelled testers "QA Engineers" decades ago and the name stuck. Someone whose entire job is executing tests is doing QC while carrying a QA title, so both words end up describing the same person. Once the vocabulary collapses, the concepts follow.

Org structure. Many companies created a "QA department" that sits at the end of the pipeline and receives finished builds. Structurally, that department can only do QC — it has no authority over requirements, design, standards or merges. It gets held accountable for quality while owning only inspection. That arrangement reliably produces the "QA is a bottleneck" complaint, and the bottleneck is a symptom of a process problem, not a testing one.

Both words mean "quality" to non-specialists. To a stakeholder, "QA" and "QC" are interchangeable synonyms for "the bit that stops bugs". Nobody outside engineering has a reason to care about the distinction — until the defect rate refuses to improve.

The practical fix is not to police vocabulary. It is to check where authority sits. Ask one question: who can change the definition of done? If the answer is "nobody in the QA team", you have a QC function with a QA nameplate, and your quality ceiling is already set.

Should you invest in QA or QC first?

Invest in QC first if you have no safety net, then shift the balance to QA as soon as the net exists. The sequencing matters and it is not a matter of taste.

If you currently ship with little or no testing, you cannot start with process improvement, because you have no measurement. You do not know which defects escape, in which areas, or at what rate. Build a basic QC layer first — smoke tests, a regression suite on critical journeys, defect logging with root-cause categories. That gives you data.

Once QC is producing reliable signal, the marginal return flips. Adding your tenth tester finds fewer new defects than fixing the requirement-review process that creates them. This is the point most organisations miss: they keep scaling QC linearly because it is visible and easy to budget, while the compounding QA investments — standards, gates, reviews, testable acceptance criteria — stay unfunded because nobody can put a defect count next to them.

• No safety net: build QC. Smoke suite, critical-path regression, defect tracking.
• QC exists but defects are flat: the bottleneck is QA. Fix the process creating them.
• Defects fall but releases are slow: the bottleneck is QC efficiency. Automate the repetitive layer.
• Both healthy: shift to prevention economics — measure defects injected per increment, not just found.

A structured maturity view helps here — our free QA maturity assessment works through where a team's process and inspection layers actually sit, so the next investment goes to the constraint rather than the loudest complaint.

How Appsierra helps

Most teams that call us want more testing. Usually what they need is a working QA system with a competent QC layer inside it — because testing harder is what you do when the process is the problem and nobody has said so. Our engagements typically start by separating the two: what is your defect escape rate telling you about inspection, and what is your root-cause distribution telling you about process?

Appsierra runs expert-supervised pods rather than unmanaged contractors, which matters specifically here. A pod that only executes test cases can improve QC and nothing else. A senior-led pod can also work upstream — tightening acceptance criteria, adding CI gates, defining a real definition of done — which is where the defect curve actually bends. We are ISO 9001 and ISO 27001 certified and CMMI-aligned, and our quality assurance services cover both the process layer and the execution layer rather than selling one and calling it the other.

If you want an outside read on where your quality ceiling is set, QA consulting starts with your artefacts — stories, standards, gates, defect history — not your test cases. And if you would rather see it working than read about it, pods are typically productive in about seven days and start with a risk-free paid pilot tied to a metric you choose. A free 30-minute call is enough to work out whether your problem is QA, QC, or the gap between them — teams evaluating an experienced quality assurance company usually find that question more useful than any tooling discussion.

Frequently asked questions