QA and QC: two sides of quality you should not confuse

In software development we hear the terms QA and QC all the time. Many people use them as if they were the same thing. Even job postings mix them up. But the truth is they mean different things and confusing them can create real problems for your quality strategy.

This article explains what each one is, what the main difference is, and why you should stop using them interchangeably.

What is QA?

QA stands for Quality Assurance. It is a set of planned and systematic activities. Its goal is to prevent defects before they happen. QA focuses on processes.

When we talk about QA, we think of defining standards, creating development guidelines, training the team, doing code reviews, and improving how software is built. QA asks: Are we doing things right?

A useful analogy is preventive medicine. You do not wait for the person to get sick. You give them a balanced diet, exercise, and regular checkups to avoid illness. QA is exactly that.

What is QC?

QC stands for Quality Control. It is a set of operational activities that inspect the final product. Its goal is to identify defects after the software has been built. QC focuses on the product.

QC includes functional tests, regression tests, usability tests, bug reports, and any verification done on already written code. QC asks: Does the product meet what was requested?

Following the medical analogy, QC would be the blood test or Xray when the patient already has symptoms. You detect the existing problem.

Main difference

The central difference is when they act and the nature of their actions.

An easy way to remember it: QA builds quality, QC verifies it.

Flowchart

The following Mermaid diagram shows how QA and QC relate in a typical development flow.

flowchart LR
    A[Define processes] --> B[QA: Training and standards]
    B --> C[Develop software]
    C --> D[QC: Run tests]
    D --> E{Defects?}
    E -->|Yes| F[Report and fix]
    F --> C
    E -->|No| G[Deliver product]

You do not need HTML or complex tags. This diagram renders correctly on any blog that supports Mermaid.

Why you should not confuse them

Confusing QA with QC brings real consequences. The most serious one is thinking that testing at the end of the project guarantees quality. That is not true.

If you only do QC, you detect errors but you do not prevent them from happening again. Your team will keep making the same mistakes over and over. The cost of fixing grows exponentially the later a defect is found.

If you only do QA, you might have perfect processes but you never verify that the product actually works. You stay with theory without validating practice.

As Gerald Weinberg wrote in his book "Quality Software Management": "Quality is value to some person. It is not an abstract attribute". You cannot assure quality without controlling the product, nor control the product without assuring the processes.

Concrete example

Imagine you develop a payment API.

• QA would be: defining that all developers must write unit tests, establishing a security checklist before writing code, training the team on OWASP, reviewing the architecture before implementation.

• QC would be: running integration tests on the already deployed API, doing penetration tests, verifying that amounts calculate correctly, reporting a bug when an endpoint returns error 500.

Both are necessary. Neither replaces the other.

References

The following sources have been consulted to support these definitions.

International Software Testing Qualifications Board. (2018). ISTQB Certified Tester Foundation Level Syllabus. Version 2018 v3.1. https://www.istqb.org

Pressman, R. S. (2014). Software Engineering: A Practitioner's Approach. 8th ed. McGraw-Hill Education.

ISO. (2015). ISO 9000:2015 Quality management systems — Fundamentals and vocabulary. International Organization for Standardization.

Weinberg, G. M. (1992). Quality Software Management: Systems Thinking. Dorset House Publishing.