Quality Testing in Software: QA vs QC vs Testing Explained

People who search for quality testing software are usually asking about three different jobs at once. Quality assurance (QA) shapes the process so fewer bugs get made, quality control (QC) checks the product your team built for problems, and testing is the hands-on work that supplies most of QC’s evidence.

Mixing up the three jobs gets expensive when you staff a project. A company with a weak process may hire someone who only runs test cases, while a startup short on testers may pay for a consultant to redesign its workflow. Either way, the budget goes to the wrong kind of help.

This guide explains QA, QC, and testing in plain words, using the official definitions from the ISTQB, which certifies software testers internationally. You’ll also see how the jobs fit together in a real project and what to ask before you hire. If you’d rather hand all three to one partner, our dedicated QA team works that way.

Why Is Quality Testing Software Really Three Different Jobs?

Each of the three jobs answers a different question. QA asks whether the team works in a way that produces good software, and QC decides if this particular release is ready to ship. Testing asks where the product breaks and gathers the evidence QC needs to make that call.

Quality Assurance Prevents Defects in the Process

The ISTQB glossary defines quality assurance as “activities focused on providing confidence that quality requirements will be fulfilled.” In everyday terms, QA sets up working habits that prevent bugs, which testers call defects.

Day to day, QA work is mostly planning and agreeing on rules. A QA specialist reviews each feature’s written description and makes sure it’s clear enough to build and test. Part of the job is agreeing on what “done” means, what gets tested before every release, and how problems get reported and tracked. When a bug reaches users anyway, QA looks for the gap in the process that let it through.

Quality Control Finds Defects in the Product

Quality control is the checking side. The ISTQB glossary describes QC as “activities designed to evaluate the quality of a component or system.” Put simply, QC compares what your team actually built with what you planned to build.

QC happens once there’s something to inspect, such as a single screen, a new feature, or a full release. Testers divide this work into two parts, known as verification and validation:

• Verification: Does the product match the written plan?
• Validation: Do real users get what they need from the product?

Testing Is the Main Way Quality Control Gets Done

Testing means deliberately using the software to find problems before your customers do. The ISTQB syllabus says QA and testing “are not the same” and calls testing “a major form of quality control.” In other words, testing is one part of QC, and QC works alongside QA.

Manual testing means a person works through the app the way a customer would. This hands-on approach catches confusing screens and odd behavior that scripted checks tend to miss. Automated testing uses small programs to repeat the same steps quickly on every new version. Both kinds deliver the same result: evidence about how the product works right now.

QA vs QC vs Testing at a Glance

QA vs QC vs testing comes down to three focuses: the process, the product, and the hands-on checks in between.

The ISTQB adds that QA “is the responsibility of everyone on a project,” so no single hire or vendor can own quality alone.

How Does the Software Quality Assurance Process Fit With Testing?

On a well-run team, QA, QC, and testing work as a loop. QA sets the rules, testing gathers evidence, and QC turns the findings into a release decision. After each launch, the team reviews what went wrong and adjusts the plan for the next cycle. Keeping that loop running from one release to the next is the job of the software quality assurance process, and our guide to the QA process walks through each step.

How We Split QA, QC, and Testing for DrAnsay

We set up all three jobs from scratch for DrAnsay, a German online prescription platform with 700,000 patients. DrAnsay had no internal QA team at the start, and recurring bugs kept reaching patients while they ordered prescriptions.

Here’s how the work divided across QA, testing, and QC:

• Quality assurance: We began by exploring the web and mobile apps and turned the findings into a test plan. Our engineers also reviewed feature documents and designs ahead of development, so gaps surfaced before anyone wrote code. Test cases, plans for re-checking existing features, and bug tracking all moved into one tool, Qase.io, so everyone saw the same picture.
• Testing: Our engineers worked through the prescription order flow by hand on web and mobile. We also wrote more than 40 automated tests with Playwright, a widely used browser automation tool, for the most important user journeys. Those tests run daily and report to the team’s Slack channel.
• Quality control: The results told the DrAnsay team what had to be fixed before each new version could go live.

We reported more than 150 bugs, and 60+ of them never reached production. DrAnsay’s orders grew by 15%, and abandoned checkouts fell by 18%.

A single round of testing right before launch finds bugs late. For that reason, we involve QA from the first feature descriptions and keep checking through all the stages of software testing.

What Happens When QA or QC Fails?

Two big outages from 2025 show the difference between a process gap and a missed defect.

Cloudflare is a network provider that many websites rely on for speed and security. On November 18, 2025, the company had its worst outage since 2019, by its own account. A change to database permissions caused an internal settings file to double in size. The program that loads it had a limit of 200 entries and crashed once the oversized version spread across the network. Cloudflare’s fix is a process change: the company plans to check files its own systems create as strictly as input from users. The outage is a QA lesson, because the gap sat in the rules about what gets inspected.

In October 2025, a major failure hit one US region of Amazon Web Services (AWS), the cloud platform behind many apps. AWS traced the cause to what its report calls a latent race condition. That term describes a hidden timing bug that appears only when two automated processes update the same records at once. AWS’s fixes include an additional test suite, meaning a new set of repeatable checks, for one of the company’s recovery systems. The AWS outage is a QC lesson, since a defect got past the safeguards already in place.

Your own incidents can be sorted the same way. After any serious bug, ask whether the process allowed the risk or the checks missed the defect. The answer tells you if your QA, your QC, or both need work.

Is Quality Engineering Replacing QA?

No, quality engineering (QE) is a broader way of organizing the same three jobs. QE often appears in job ads and vendor pitches. The ISTQB glossary describes quality engineering as practices in which “stakeholders share joint responsibility” for quality. Stakeholders here means everyone with a say in the software, from developers and testers to product owners.

The idea grows out of the QA principle that quality is the whole team’s job. In a QE setup, developers write automated checks for their own code, testers help shape features early, and product owners agree on what must pass before release. QA, QC, and testing still happen inside QE, so the definitions earlier in this guide hold.

What Are You Hiring When You Hire a QA Engineer?

Job titles add to the confusion. In our experience, the typical “QA engineer” spends most of the week on hands-on work: writing test cases, running the checks, and reporting bugs. Process work takes up the remaining hours, and its share usually grows with seniority. So a hire with this title covers plenty of QC but only part of QA.

A testing-only engagement can still be exactly the right choice. For Chesapeake Technology, we test SonarWiz, desktop software that more than 4,000 organizations use to map the seabed. The client already had its own test cases, so our engineers focused on running them. SonarWiz is a complex product that reads over 60 sonar data formats. The initial engagement alone turned up more than 50 bugs, among them a small metadata error that shifted map coordinates by thousands of kilometers.

Vendors aren’t always precise with labels either, and that includes us. Our case study describes the project for Elsewhen, a London digital product consultancy, as a QA audit. In practice, we tested a redesigned website for functionality, visuals, accessibility, search visibility, and speed. Of the bugs we reported, 41% concerned design consistency, and 20% affected users with disabilities. Every check looked at the product itself, so by the ISTQB definitions, the project was QC.

Before you hire a person or a vendor for quality testing software work, ask a few direct questions:

• Will you review our requirements and release process, or only test what we hand you?
• Who writes the test cases, and who keeps them up to date?
• How do test results reach our developers, and who decides whether a release ships?
• What changes in our process if the same kind of bug keeps coming back?

The answers show you whether you’re buying QA, QC, testing, or a mix of all three.

The Right Terms Set the Right Expectations

Knowing the difference between QA, QC, and testing tells you what to expect from a new hire, a vendor, or a review of how your team works. When you shop for quality testing software services, look for three things:

• A process that prevents defects
• Checks that catch the bugs that slip through
• Regular reviews that turn each missed bug into a lasting fix

At QAwerk, one team covers the process side and the hands-on testing, so you don’t have to coordinate several providers. To find out whether your project needs more QA, QC, or testing, talk to our QA engineers.

FAQ

What is the difference between QA, QC, and testing?

In quality testing software, QA, QC, and testing are three connected jobs. Picture a restaurant kitchen: QA is the recipes and hygiene rules that keep bad dishes from being made, QC is the head chef’s call on whether each plate is good enough to serve, and testing is the tasting that guides the chef. QA prevents defects, while QC and testing find them.

Is testing part of QA or QC?

Testing belongs to quality control. According to the ISTQB, the international board that certifies testers, testing is a major form of QC. Examining the software itself is exactly what QC exists to do. QA works one level up and decides when testing happens, how much is enough, and what changes when the same bugs keep returning.

Does a QA engineer do quality assurance or testing?

Most QA engineers do both kinds of work, in different proportions. On a typical team, junior and mid-level specialists spend the bulk of their time on hands-on testing. Senior engineers and QA leads take on more process work, such as reviewing feature requirements and setting release criteria. Titles vary widely, so read the listed duties in a job description or vendor proposal to see the real split.

Can one team handle both QA and QC?

Yes, and for small and mid-sized companies, a single team is often the simplest setup. The people who test each release also see where bugs come from, so they can fix the underlying process without a handoff between vendors. Before signing, confirm that the agreed scope covers planning and review work alongside test runs.

Do small teams need a separate QA process?

A small team needs a lightweight QA process. Three habits usually handle the basics: a short test plan, one shared place to track bugs, and a clear rule for what must pass ahead of each release. Without that routine, testing turns into random clicking, and the same problems return in every new version.