Quality Assurance vs Quality Control: Key Differences

What Is Quality Assurance (QA)?

Quality Assurance (QA) is a proactive process that prevents defects by building quality into the development lifecycle, from design through testing, so products meet requirements before release.

The formal definition is narrower and more useful than most summaries suggest. The ISO/TC 176/SC 1 listing of terms records ISO 9000:2015 clause 3.3.6 defining quality assurance as "part of quality management focused on providing confidence that quality requirements will be fulfilled." That 2015 wording is quoted here because it is the phrasing carried by current glossaries, certification syllabi, and audit checklists, even though ISO now lists a 2026 edition as available.

The wording is doing precise work. Confidence means QA produces justified belief that requirements will be met, which is a weaker claim than proof. Will be puts QA ahead of the build in time, so QA is the work you do before there is anything to inspect.

Translated into engineering terms, QA owns the rules of production rather than the product:

• Definition of done - the agreed conditions a story must satisfy before it can be called complete.
• Test strategy and plan - what will be tested, at which level, with which coverage expectations.
• Entry and exit criteria - the thresholds a build must clear to enter testing and to ship.
• Standards and review policy - coding conventions, review requirements, and the checks that run before merge.
• Process audits and retrospectives - checking that the defined process was actually followed, and correcting it when it was not.

None of those activities can find a bug, because none of them touches running software. That is what makes them QA: they change the probability that a defect gets created at all.

What Is Quality Control (QC)?

Quality Control (QC) is a reactive process that detects and corrects errors in the finished product through testing, inspection, and review against established quality standards before release.

The same ISO 9000:2015 listing defines quality control in clause 3.3.7 as "part of quality management focused on fulfilling quality requirements." The contrast with clause 3.3.6 is precise: assurance provides confidence that requirements will be fulfilled, while control is concerned with actually fulfilling them. Both sit under quality management, alongside quality planning and quality improvement.

In software, QC always has an object. You do not run QC in general; you run it against build 1482, on a named browser, at a point in time. Every QC activity produces a verdict about that specific artifact, and each verdict either passes or surfaces bugs and defects to be triaged.

This is also why QC cannot substitute for QA. A failing check tells you a defect exists, but it says nothing about why the process allowed it, so inspection finds escapes without removing their cause.

Note: Tighten both sides of quality: prevent defects earlier with a documented QA process, and catch what slips through by running QC on real browsers and devices. Try TestMu AI Today!

Quality Assurance vs Quality Control: Key Differences

Both are components of the software quality management process, and they differ in the techniques applied, the nature of the work, and the point in time at which each one acts.

The row that causes the most argument in practice is responsibility. QA is shared because process compliance is everyone's job, while QC is usually concentrated in whoever executes the checks. Teams that assign both to one person tend to lose the QA half first, because it has no build to force the work.

This Voices of Community episode, Achieving Continuous Quality Through People, Process, Tools and Culture, covers the organizational side of that responsibility split.

QA and QC Examples in Software Testing

The fastest way to classify any quality activity is to ask whether it could run before the code exists. If yes, it is QA. If it needs a build, it is QC.

QA examples - writing a software quality assurance plan, agreeing a definition of done with the team, setting a coverage threshold that blocks merges, running a requirements review to catch an ambiguous acceptance criterion, and auditing whether the last release followed the documented sign-off process.

QC examples - executing the regression pack against build 1482, running a smoke suite on a pull request, performing an exploratory session on a new checkout flow, logging a defect with reproduction steps, and re-testing that defect after the fix lands.

A single scenario shows the handoff. Suppose the acceptance criterion says the confirmation message must read "QA prevents, QC detects". Agreeing that wording is QA. Checking whether the built page actually renders it is QC, and the check either confirms the requirement or reports a mismatch.

Running exactly that check on the TestMu AI cloud against the Selenium Playground produced the output below. It is the QC half of the example, recorded under build 106035961 on 23 September 2026:

$ npx playwright test simple-form-demo.spec.js --project=chromium-testmu

Running 1 test using 1 worker

  1) simple-form-demo.spec.js:14 > rendered message must match acceptance criterion

     Error: expect(received).toBe(expected)

       Expected: "QA prevents, QC detects"
       Received: "QC detects, QA prevents"

     at simple-form-demo.spec.js:14:32

  1 failed
  0 passed

The run detected a mismatch between the rendered text and the agreed criterion; it did not prevent it. The criterion itself, the decision to assert on it, and the choice to gate the merge on the result were all settled before the run existed. That is QA. Everything visible in the log is QC.

QA Activities vs QC Activities

Each activity has a different input. QA activities take requirements, standards, and process data; QC activities take a build.

The activity set for software QA is specified in a standard. IEEE publishes IEEE 730-2026, the Standard for Software Quality Assurance Processes, as an active standard that superseded IEEE 730-2014, covering requirements for initiating, planning, controlling, and executing software quality assurance.

QA activities cover the process:

• Requirements review - product owner, tester, and developer together at refinement, before estimation. Leaves a set of acceptance criteria someone has agreed is testable.
• Test planning - the test lead during sprint planning. Leaves a plan naming test levels, environments, and data needs.
• Standards definition - the engineering team once, then amended at retrospectives. Leaves coding conventions, branch policy, and configured review gates.
• Process audit - a reviewer independent of the release, after it ships. Leaves a finding on whether the documented sign-off path was followed.
• Root cause analysis - the team on an escaped defect, in the maintenance phase. Leaves a process change, not a bug fix.

QC activities cover the product:

• Unit and integration runs - the developer and CI, on every commit. Leaves a pass or fail verdict attached to a named commit.
• Smoke and regression suites - CI on a pull request and nightly. Leaves a run report showing whether the build is viable and what it broke.
• Exploratory testing - a tester on a built feature, within the sprint. Leaves session notes and any defects found.
• Defect logging and re-test - the tester who found it, then again after the fix. Leaves a defect record with reproduction steps and a closing verdict.
• Acceptance sign-off - the product owner at release. Leaves a recorded decision that the build met its criteria.

QA and QC in the SDLC and STLC

QA spans the full software development lifecycle, while QC occupies the execution phases of the software testing lifecycle. Mapping both against the phases removes most of the ambiguity.

• Requirements - QA reviews acceptance criteria for testability and sets coverage expectations. No QC is possible, because nothing is built.
• Design - QA defines test levels and environments, and reviews the design against standards. Still no QC.
• Implementation - QA enforces review policy and merge gates. QC begins here in its earliest form, as unit checks against committed code.
• Build and test - QC dominates: smoke, integration, regression, and exploratory work against a specific artifact. QA is present only as the criteria those runs are judged by.
• Release - QC produces acceptance sign-off. QA owns the exit criteria that sign-off is measured against.
• Maintenance - QA runs root cause analysis on escapes and amends the process. QC re-tests fixes and guards against regressions.

The clean technical split is that most QA work is static testing, which examines artifacts such as requirements, designs, and code without executing them. Most QC work is dynamic testing, which executes the software and observes behavior.

QA and QC in a CI/CD Pipeline

A pipeline makes the difference concrete, because the two practices occupy different objects in the same repository. QA is the pipeline definition. QC is the run.

QA in the pipeline is every decision encoded in configuration: which stages exist, which suites run on a pull request versus nightly, the coverage threshold that fails the job, the required reviewers, and the rule that a failing check blocks the merge. Those choices are made once, before any build, and they are what shift left testing actually moves earlier.

QC in the pipeline is every execution result: the job that ran on commit a1b2c3d, the 47 tests that passed, the 2 that failed, and the artifacts those failures produced. A pipeline run only reports what already happened.

The practical consequence is that the two are debugged differently. If defects keep reaching production, the pipeline definition is wrong, which is a QA problem: a missing stage, a threshold set too low, or a gate that warns instead of blocking. If the pipeline is too slow to run on every change, it gets bypassed, and the QC coverage you designed stops happening regardless of how well the QA gates were specified.

Is a QA Engineer Actually Doing QC?

Usually, yes. In most software organizations the role titled QA Engineer spends its time writing and executing tests against builds, triaging failures, and signing off releases. By the ISO definitions, that is quality control.

The mismatch is historical. Software borrowed the QA label from manufacturing for the team that checks output, while manufacturing reserves QA for the process function and uses inspector for the checker. The result is a job title that names the opposite of the work, which is why the two terms blur together in software more than in any other industry.

The mislabel has practical consequences:

• Nobody owns QA - if every quality person is executing checks, process design is unowned by default, and escaped defects have no obvious home for root cause work.
• Hiring targets the wrong skills - interviews weighted toward test execution select for QC strength, which is why quality control interview questions about defect detection and product validation dominate QA job interviews.
• Metrics measure one half - pass rates and defect counts report QC activity, so a team can look healthy while its process quality is never measured.

This also explains why testing is not a synonym for either term, a distinction covered in more depth in software testing and quality assurance. Designing a test is QA, running it is QC, and testing is the umbrella word people use for both.

How QA and QC Fit Into a Quality Management System

Neither practice is a top-level concept. The same ISO 9000:2015 listing places both inside quality management at clause 3.3.4, which it records as being achieved through four parts: quality planning, quality assurance, quality control, and quality improvement.

Seeing all four at once explains the gaps most teams actually have. Planning decides what quality means for this product. Assurance builds the process to reach it. Control verifies the output. Improvement changes the process based on what control found.

Teams that report a QA problem are often missing the fourth part rather than the second. They have standards and they run tests, but nothing routes QC findings back into a process change, so the same class of defect recurs release after release. That routing is what a quality audit checks, which is why an audit is a QA activity even though it consumes QC output.

Metrics That Show QA and QC Are Working

Prevention and detection need different measurements, and most teams track only the detection set. The split matters for diagnosis: a QC metric tells you what the product looks like now, while a QA metric tells you whether the process is improving.

One signal of how late issues surface: in GitLab's 2025 Global DevSecOps survey of 3,266 DevSecOps professionals, fielded by The Harris Poll, 76% said more compliance issues are currently discovered after deployment than during the development process.

QA-side metrics measure the process:

• Escaped defect ratio - defects found in production divided by total defects found. Rising means prevention is weakening.
• Requirement coverage - the share of acceptance criteria with at least one linked test case.
• Review effectiveness - defects caught in review versus those caught later in execution.
• Process compliance - how often releases followed the documented sign-off path.

QC-side metrics measure the product and the runs:

• Defect density - confirmed defects per module or per thousand lines of code.
• Pass rate and flaky rate - how much of the suite passes, and how much of it cannot be trusted either way.
• Mean time to green - how long a broken build stays broken.

A practical diagnostic falls out of the pairing, and it is covered further in QA metrics. High escaped defects with a high pass rate points at a QA gap, because the process is producing defects your criteria do not ask about. High in-sprint defect counts with low escapes points at QC working as intended.

How Do QA and QC Align Teams With Quality Goals?

Alignment is mostly a question of ownership and handoffs. The QA process owns the standards and builds them into every phase, QC owns the verdict on each build, and the handoff between them is the criteria document both sides agree on.

Three artifacts carry that handoff in practice: the agreed acceptance criteria, a traceability link from each criterion to the run that checked it, and a standing review of anything that escaped. Remove the criteria and QC has nothing to judge against. Remove the traceability link and nobody can tell which requirements were actually verified. Remove the escape review and QC findings never reach the process that caused them.

For teams running both, TestMu AI is an AI-native test automation platform that covers the preventive and detective halves in one place:

• Requirement traceability - a traceability matrix links requirements to test cases, runs, and defects, so coverage gaps surface before the release rather than after it.
• Automated execution - run an existing Selenium, Cypress, Playwright, or Puppeteer suite across 3,000+ real browser and OS combinations in parallel.
• HyperExecute - a test orchestration cloud that runs suites up to 70% faster than traditional grids by placing the test script and its execution components in one isolated environment.
• Real device coverage - validate the finished build on 10,000+ real Android and iOS devices, which are physical handsets rather than emulators or simulators.

How Is AI Reshaping QA and QC?

AI changes the cost of both halves without merging them: QA gets more predictive, QC gets faster.

• On the QA side - AI turns requirements and past defects into test plans, and flags risky areas before code is written.
• On the QC side - self-healing locators, anomaly detection, and AI failure triage speed execution and cut maintenance.

The 2025 DORA State of AI-assisted Software Development report from Google Cloud, based on responses from nearly 5,000 technology professionals, found that 59% reported a positive influence of AI on code quality while 30% reported little or no trust in AI-generated code.

That report covers developer sentiment and does not prescribe a testing policy. The read across to QA and QC is an inference rather than a finding: where nearly a third of practitioners distrust the generated output, the detective checks are the part to keep.

TestMu AI's KaneAI generates cases before code exists and runs them after, so it appears on both sides of the split:

• Test generation from existing artifacts - turn a Jira ticket, PRD, or screenshot into structured test cases before code is written.
• Natural-language authoring - write and edit tests in plain English, with no selectors or framework knowledge needed to start.
• Multi-framework export - export generated tests to Selenium, Playwright, Cypress, and Appium if the team wants to own the code.

Conclusion

Open your team's current quality activities and sort each one into two columns: a definition of done, a test strategy, and a code review standard go under QA, while a smoke run on last night's build, a regression pass, and a logged defect go under QC.

When the detective column needs production hardware, run the suite on the TestMu AI real device cloud. The Test Manager documentation covers linking those runs back to the requirements they verify, so a gap in either column is visible before release.