Ask ten people what a "QA engineer" does and nine of them will say something like: "they test the app." That's not wrong — but it's like saying a surgeon "cuts people open." Technically true, deeply incomplete.
Let's set the record straight.
Learning Objectives
By the end of this lesson you will be able to:
- Define Quality Assurance, Quality Control, and Testing as three distinct concepts
- Explain the relationship between QA, QC, and Testing using concrete examples
- Articulate why 100% defect-free software is a theoretical impossibility
The Three Concepts You're Probably Mixing Up
Quality Assurance (QA)
QA is process-oriented. It's about setting up and improving the practices, standards, and workflows that prevent defects from being introduced in the first place. QA asks: "Are we building things the right way?"
Examples of QA activities:
- Establishing code review procedures
- Defining a Definition of Done for stories
- Creating testing standards for the team
- Conducting retrospectives to improve the development process
Notice that none of those involve clicking a button in a live application. QA happens upstream — before and during development.
Quality Control (QC)
QC is product-oriented. It's about examining a deliverable — an artifact, a build, a release — to check that it meets requirements. QC asks: "Does this specific thing we built meet the standard?"
Examples of QC activities:
- Reviewing a completed feature against acceptance criteria
- Running a regression suite before a release
- Performing a formal inspection of a requirements document
Testing
Testing is a specific activity within QC. It means executing the software — with data, user actions, or automated scripts — to find defects and verify behavior. Testing asks: "Does the system do what it should do, and does it avoid doing what it shouldn't?"
The relationship in one sentence: QA improves the process that produces the product; QC checks the product; Testing is one of the ways QC is done.
Why Can't Software Be 100% Perfect?
Every developer who has ever worked on a non-trivial product has heard the question: "Can we just test everything?" The answer is no — and here's why.
The Combinatorial Explosion
Consider a simple login form with just two fields and one button. Even this trivial interface has an effectively infinite number of possible input combinations when you account for different character sets, lengths, browser states, network conditions, and user behaviors. A 10-field form multiplies this into an astronomical number of test cases.
Time and Cost Constraints
Every testing decision is a trade-off. The business decides how much testing is "enough" based on risk tolerance, time-to-market pressure, and budget. A medical device gets exhaustive testing. A marketing landing page gets a smoke test.
The Pesticide Paradox
If you run the same tests repeatedly, they stop finding new bugs. The system has been "vaccinated" against those specific checks. New defects hide in the places you haven't tested yet.
The honest truth: The goal of testing is not to prove software is perfect. It's to reduce risk to an acceptable level, given the constraints you're operating in.
Pro Tips
Don't say "QA" when you mean "Testing." These are not synonyms. A QA engineer does much more than test — they influence the entire process. Using precise language demonstrates professional credibility.
When someone says "we don't have time to test," translate it as: "we've decided to move this risk to production." That framing clarifies the conversation.
Summary
- Quality Assurance focuses on the process that builds the product — it prevents defects.
- Quality Control focuses on the product itself — it detects defects in deliverables.
- Testing is a specific QC activity where software is executed to find defects.
- Software can never be 100% tested due to combinatorial complexity, time constraints, and the pesticide paradox.
- The goal of testing is risk reduction, not perfection.