QA, QC and testing are not the same thing

Software teams use "QA," "QC," and "testing" interchangeably. Someone finds a bug and says QA caught it. A release gets checked before production and the team calls it QC. A tester joins a sprint and suddenly everything related to quality is called "QA."

In everyday conversation that may not look like a big deal. But the three terms describe different activities, and when a team treats them as one, it tends to start thinking about quality only when development is almost finished instead of throughout the process.

Quality assurance focuses on the development process, quality control evaluates the product, and testing is one of the activities used to assess that product. Knowing the difference helps teams organize their work and find quality problems earlier.

QA tries to prevent the problem

Quality assurance is process-oriented and preventive. It is about how software is developed and what a team can do to reduce the likelihood of defects: reviewing requirements, defining acceptance criteria, planning reviews, clarifying responsibilities, and making sure testing is considered early in the lifecycle.

The ISTQB Foundation Level Syllabus notes that QA and testing are often used interchangeably even though they are different concepts. QA is process-oriented and preventive, while testing is product-oriented and corrective.

Take a checkout feature. Before development is complete, the team can already ask:

• Are the requirements clear about what happens when a payment fails?
• Have retry scenarios been considered?
• What happens if the payment succeeds but the confirmation request times out?
• Who decides whether the feature is ready for release?

None of those questions need a finished checkout page. Asking them early is a chance to find missing requirements and risks before they turn into defects in the product.

QC looks at what you actually built

Quality control evaluates whether software work products meet the expected quality requirements. QA looks at the processes used to build software; QC examines the results of those processes. Testing is an important part of QC, but QC covers a broader range of activities.

According to ISTQB, testing involves activities that help discover defects and evaluate the quality of work products. It is more than executing test cases and checking results: it can include reviewing requirements, user stories, designs, and code, identifying product risks, and providing information that supports decisions about quality. Some of those activities are static, meaning the software never has to run.

When a team says "we'll do QA on Friday before release," they usually mean they will test the product on Friday.

If QA is treated as a final testing step, the questions about requirements, risks, and development practices get attention much later than they should.

One checkout, three different questions

The differences get clearer when you look at the same checkout feature from three angles.

• QA asks why payment failure scenarios were missing from the requirements, whether the acceptance criteria were complete, and whether testers were involved early enough to spot risks.
• QC asks whether the feature meets its expected quality requirements: reviewing test results, examining the defects found, and judging whether it is ready for release.
• Testing asks how checkout behaves under different conditions. What if a user double-clicks "Pay"? What if the connection disappears halfway through? What if the session expires while the payment form is open? What if the card is charged but the confirmation page never loads?

Each one contributes to understanding the quality of the feature. Testing can reveal a problem, QC helps evaluate its impact, and QA helps the team look at whether improving the process could prevent a similar problem in future releases.

Testing and checking are not quite the same either

Michael Bolton and James Bach have explored the difference between testing and checking through their work on Rapid Software Testing, and it explains why testing is more than verifying expected results.

In their approach, checking evaluates a product against an existing expectation. If the requirements say valid card details plus "Pay" should produce a successful payment, the team can check that it does. The expected outcome is already defined, so this kind of activity can usually be repeated through automation.

Testing is exploring the product, questioning assumptions, and interpreting what you observe. Bolton stresses the role of human judgment, investigation, and tools in helping stakeholders understand a product and make informed decisions about it.

A tester might start by checking that a payment succeeds with valid card details. While doing it, they notice the payment button stays active while the transaction is processing. That observation leads them to explore whether repeated clicks could create duplicate transactions.

Testers contribute by identifying which scenarios need to be checked, recognizing risks, and asking questions nobody asked during development.

This lines up with ISTQB's description of testing as an intellectual activity that calls for specialized knowledge, analytical skills, critical thinking, and systems thinking.

Why this is more than a vocabulary lesson

Teams do not need to spend meetings debating whether each activity is QA, QC, testing, or checking. But understanding the differences helps them spot gaps in how they approach quality.

A team might have automated checks that pass before every release and still hit unexpected problems in production. Reviewing the test results is useful there, but the team may also need to ask whether the tests cover the important risks, whether the requirements were clear enough, and whether failure scenarios were discussed during development. Those questions involve different responsibilities and activities, and knowing where each fits makes it easier to decide what to improve.

At GetQA, we believe quality should be considered throughout development. Understanding the product, identifying risks, and building useful regression coverage are part of that, and involving testing earlier helps teams address problems before they get harder to fix.

The checkout example shows how the pieces work together: testing surfaces unexpected behavior, QC supports evaluating the product, and QA pushes the team to improve the processes behind the work. When all three are considered throughout development, there are more chances to catch risks early, make informed decisions, and ship more reliable software.

References

• International Software Testing Qualifications Board (ISTQB). Certified Tester Foundation Level Syllabus, Version 4.0.1 (2024). https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/
• International Software Testing Qualifications Board (ISTQB). ISTQB Glossary. https://glossary.istqb.org/
• Bolton, M. On Testing and Checking Refined. DevelopSense, March 29, 2013. https://developsense.com/blog/2013/03/testing-and-checking-redefined
• Bach, J., & Bolton, M. Testing and Checking Refined. Rapid Software Testing, 2013.