Quality Assurance vs Quality Control in Software Testing: 5 Critical Differences

Quality assurance (QA) works on the process, so fewer defects get made. Quality control (QC) checks the product, so the defects that got through are found before users find them. Testing is the main form of QC. The ISTQB, the body that certifies software testers, puts it the same way in its Foundation Level syllabus: testing is “a product-oriented, corrective approach”, and QA is a process-oriented, preventive one.

People often say “QA” when they mean testing, and in a small team one person may do both jobs. The difference still matters when you plan a release, hire a team or decide where the money for quality should go.

QA vs QC vs testing at a glance

	Quality assurance (QA)	Quality control (QC)	Testing
Question it answers	Is the way we build likely to produce a good product?	Does this build meet the requirements?	Does this feature work, and where does it break?
Works on	The process	The product	The product
When	The whole project, from requirements to release	After something is built, before it ships	During each sprint and before each release
Typical work	Definition of done, code review rules, automated pipelines, test strategy, release rules, retrospectives	Testing, acceptance checks, release sign-off, defect reports	Manual and automated tests, regression runs, load and security tests
Who	Everyone on the team	Testers, the product owner, reviewers	QA engineers and developers

What quality assurance covers in a software project

QA sets the rules that make good work the default. In a software project that usually means:

• Clear requirements: user stories with acceptance criteria someone can check.
• A definition of done: what has to be true before a task counts as finished, tests included.
• Code review: nobody merges code that a second person hasn’t read.
• Automated builds and releases, so every change goes through the same checks.
• A test strategy: what gets automated, what gets tested by hand and on which devices.
• Release rules: who signs off, how a release can be rolled back, what gets monitored after launch.
• Retrospectives: the team looks at what went wrong and changes the process.

The ISTQB syllabus says QA “is the responsibility of everyone on a project”. A QA engineer can own the test strategy, but developers, designers and the product owner all follow the process.

What quality control covers

QC looks at what was built. It covers testing, reviews of finished work against the requirements, acceptance by the product owner and the decision to release or not.

On IPOPBOOKS, a bookkeeping platform for US small businesses, the launch QA checklist had 733 test cases. The launch was planned for June 1, 2026. We moved it to June 16 to test everything with live bank data first, and a real card payment and refund were tested before launch. QC also kept running after release: an hourly check makes sure the books still balance.

5 critical differences between QA and QC

Approach

QA is preventive. It tries to stop defects from being made, through clear requirements, reviews and a stable process. QC is corrective. It finds defects that already exist so they can be fixed before release.

Orientation

QA is oriented to the process: how the team plans, writes, reviews and releases code. QC is oriented to the product: the screens, the API, the data and how they behave.

What each one controls

QA controls the standards the team works to: coding rules, the definition of done, which checks every change must pass. QC controls the outputs: a build, a feature, a release candidate. A QC failure stops one release. A QA failure lets the same kind of defect come back release after release.

Emphasis

QC asks “is this release good enough to ship?” QA asks “why did this defect get made, and how do we stop the next one?” The ISTQB syllabus links them through test results: in testing they’re used to fix defects, and in QA they show how well the development and test processes are working.

Responsibility

QA belongs to the whole team. QC is usually assigned: a QA engineer runs the tests, a reviewer checks the code, the product owner accepts the result.

QA vs QC vs testing: where testing fits

Testing is part of QC, the biggest part, but not all of it. Code reviews, design reviews and acceptance by the product owner are QC too. And testing feeds QA: if the same kind of bug keeps showing up in tests, that’s a process problem, and the fix belongs in QA.

HealthyNikah shows what happens when only QC is left. The old app had no tests, no monitoring and no automated releases, and its custom subscription system kept breaking. Some members were charged twice. Fixing each billing bug as it showed up didn’t stop new ones. We replaced the billing setup instead of patching it again, tested the new subscription flow, and it worked at launch.

Why the difference matters more with AI-written code

In 2026 a lot of code is written with AI tools, and that raises the stakes for both QA and QC.

• The 2025 DORA report, based on nearly 5,000 technology professionals, found that 90% use AI at work. AI adoption now goes with higher throughput, but it still goes with lower software delivery stability. The report’s summary: “AI doesn’t fix a team; it amplifies what’s already there.”
• In the Stack Overflow Developer Survey 2025, 45.7% of developers said they distrust the accuracy of AI output. The top frustration, named by 66%, was AI answers that are almost right, but not quite. 45.2% said debugging AI-generated code takes more time.

Code that is almost right passes a quick look. More QC catches more of it, but the lasting fix is QA: a rule that AI-written code gets the same review and the same tests as any other code, and a definition of done that doesn’t bend because the code arrived faster.

There’s also a 2026 deadline for some teams. From 11 September 2026, makers of products with digital elements sold in the EU must report actively exploited vulnerabilities and severe incidents, with an early warning within 24 hours (European Commission). Whether the rule covers your product is a question for a lawyer. If it does, monitoring and incident handling become part of QA, not an afterthought.

How we would budget QA in an estimate

Our project estimate turns your brief into user stories. You confirm what is in scope, and every hour in the budget traces back to a story you kept. We check the hours the model suggests against what our team actually books on finished projects, then multiply by our published rate of $39-55 an hour. QA gets its own line in that budget, so the time for testing is planned from the start.

Here is an example run of our estimate’s math with sample inputs: a B2B SaaS web app with teams, roles and subscription billing. QA came to 22 of 201 hours, next to 56 for the frontend and 56 for the backend. The budget came to $6,600 to $13,600, over 5 weeks. The inputs are assumptions, not a quote. To get the same breakdown for your own product, see what your idea costs to build.

If your team is short on testing, QA engineers can join your own team at $39-55 an hour.

A QA and QC checklist for a first release

QA (set up once, before the build):

• User stories have acceptance criteria.
• The definition of done includes tests and a code review.
• Every change goes through the same automated checks.
• AI-written code follows the same review and test rules.
• Someone owns the release decision, and a release can be rolled back.

QC (repeat before every release):

• The main user flows are tested end to end on real devices.
• Payments, sign-up and anything else that touches money or personal data are tested with real accounts.
• Regression tests pass after the last change.
• Error tracking and monitoring are live before launch day.
• Defects found are logged, and repeat ones go back to the process review.

For a short project, our guide to setting up a QA process on short-term projects goes through the setup step by step.

What we would do

1. Write the definition of done before the first sprint, with tests and code review in it.
2. Pick the flows that would hurt most if they broke, such as payments, sign-up and data import, and test them hardest.
3. Automate the checks every change must pass, and run regression tests before each release.
4. Treat AI-written code like any other code: same review, same tests.
5. Test with real accounts and real data before launch, even if it moves the date by a week or two.
6. After each release, look at the defects found and change the process where the same kind keeps coming back.
7. If you inherit code with no tests, start with a code audit ($3,500, 5 working days) before adding features.

FAQ

What is the difference between QA and QC in software testing?

QA is about the process: it sets the rules and checks that make defects less likely, such as code review and a definition of done. QC is about the product: it finds defects in what was built, mainly through testing. QA prevents, QC detects.

Is software testing QA or QC?

Testing is a form of quality control, and the biggest one. It checks the product and finds defects. Its results also feed QA: when the same kind of defect keeps showing up, the team changes the process.

Who is responsible for quality assurance?

Everyone on the project. A QA engineer often owns the test strategy, but developers, designers and the product owner all follow the process QA sets.

Does an MVP need a separate QA engineer?

It needs someone whose job is to test, even part-time. Developers testing their own code miss things. In our estimates QA is a separate line in the budget, so the time for it is planned from the start.

Does AI-written code need more testing?

It needs the same review and the same tests as any other code, with no shortcuts. In the Stack Overflow Developer Survey 2025, two thirds of developers named AI answers that are almost right as their top frustration.