"QA" and "QC" get thrown around as if they mean the same thing. They don't. Quality assurance is about the process that prevents defects; quality control is about checking the product to catch them. One is preventive, the other is detective. Teams that blur the two usually end up doing a lot of QC and calling it QA.
Here is the distinction, in plain terms.
What is Quality Assurance (QA)?#
Quality assurance is the set of practices that keep defects from happening in the first place. It is process-oriented and proactive: code review standards, test strategy, definition of done, CI gates, environment parity. QA asks "are we building this the right way so quality is baked in?"
It runs across the whole lifecycle, not at the end. If QC keeps finding the same class of bug, that is a QA problem: the process let it through.
What is Quality Control (QC)?#
Quality control is the act of checking the actual output against requirements. It is product-oriented and reactive: running test cases, executing automated suites, verifying a release behaves as expected. QC asks "does the thing we built actually work?"
Running a Playwright suite against a staging build is QC. Manually testing a checkout flow before release is QC. It is where defects get caught.
QA vs QC: the core difference#
| Dimension | Quality Assurance (QA) | Quality Control (QC) |
|---|---|---|
| Focus | The process | The product |
| Goal | Prevent defects | Detect defects |
| Approach | Proactive | Reactive |
| When | Throughout the lifecycle | After something is built |
| Examples | Standards, reviews, CI gates | Running test cases and suites |
| Owns the win | Fewer defects created | Defects caught before users see them |
A simple way to remember it: QA builds the system that makes good output likely; QC confirms the output is good.
Where each fits in delivery#
In practice they work as a loop. QA defines what "tested" means and how the pipeline enforces it. QC executes against real builds and feeds results back. When QC trends show a recurring failure, QA adjusts the process so it stops recurring. Skip QA and your QC effort grows forever, because nothing upstream is reducing the defect rate.
So what does a "QA tester" actually do?#
The title is a bit of a misnomer. Most people called a QA tester spend their day on QC work: writing and running test cases, automating regression suites, filing defects. The genuinely valuable part of the role is the QA half, shaping the process so the same bugs stop reaching them. The strongest QA engineers automate the repetitive QC so they can spend time on prevention.
How automation changes the balance#
The grind in QC is writing and maintaining test scripts. That is where AI test generation helps: instead of hand-writing every case, you point a tool at your app and it produces runnable tests you can edit. ObserveOne's Autopilot generates Playwright suites from a URL, runs them on a real browser, and self-heals selectors when the UI changes, so the QC execution stays cheap and your team's time goes to QA, deciding what should be covered and why.
The short version#
QA is the process that prevents defects. QC is the checking that catches them. You need both: QA so quality is designed in, QC so nothing slips out. Calling QC "QA" does not make the process better, it just hides that the process was never defined.