Is software testing QA or QC?

Testing is QC. Running test cases against a build to find defects is a detection (control) activity. QA is the broader, upstream process work — coding standards, design reviews, and workflow rules — that reduces how many defects testing has to catch in the first place.

Which comes first, QA or QC?

QA comes first in the lifecycle because it shapes the process before code is written, while QC needs something built to inspect. In practice both run continuously: QC findings feed back into QA process changes, and QA changes reduce future QC workload.

Can the same team do both QA and QC?

Yes, and small teams usually do. The distinction is about the activity, not the org chart. The same engineer can define a definition-of-done rule (QA) in the morning and file a reproducible bug report (QC) in the afternoon.

QA vs. QC: Quality Assurance vs. Quality Control Explained

Quality assurance (QA) and quality control (QC) are not synonyms, even though teams use them interchangeably. QA is process-oriented and proactive: it prevents defects by improving how a product gets built — standards, reviews, and workflows. QC is product-oriented and reactive: it finds defects in what has already been built, through testing and inspection. In one line: QA asks “are we building it the right way?” and QC asks “did the thing we built come out correct?”

What is the difference between QA and QC?

The cleanest way to separate them is by when they act and what they act on. QA acts on the process, before and during development, to stop defects from being created. QC acts on the output, after something exists, to catch defects that were created anyway. This split traces back to general quality-management vocabulary (the same distinction used in manufacturing and codified in the ISO 9000 family), and it maps cleanly onto software.

Three properties fall out of that timing difference:

Direction: QA is preventive; QC is detective. QA lowers the defect injection rate; QC lowers the defect escape rate.
Object: QA improves the system that produces the product (how you plan, review, and ship). QC inspects the product itself (this build, this release, this feature).
Ownership: QA responsibility is spread across everyone who touches the process. QC is often concentrated in a testing step, though anyone who files a bug is doing QC.

What does quality assurance (QA) actually include?

QA is everything you do so that fewer defects get made. It is upstream, and most of it does not involve running the product at all. Typical QA activities:

Standards and conventions. Coding style, linting rules, architecture guidelines, and a shared definition of done so “finished” means the same thing to everyone.
Reviews. Design reviews, code reviews, and acceptance-criteria reviews that catch bad assumptions before they become code.
Process design. Branching strategy, CI gates, release checklists, and rules for how work moves from idea to production.
Feedback loops. Turning each escaped defect into a process change — a new lint rule, a new checklist item, a new test tier — so the same class of bug cannot recur.

A useful test: if the activity would still make sense on a product with zero users and zero builds shipped, it is probably QA. You are shaping how the work happens, not inspecting a result.

What does quality control (QC) actually include?

QC is everything you do to find defects in a concrete build. It is downstream and hands-on. Typical QC activities:

Test execution. Running unit, integration, and end-to-end tests against a build to confirm it behaves as specified.
Exploratory and manual testing. A person using the product to surface issues that scripted tests never thought to check.
Bug reporting. Capturing a defect with enough evidence — steps, environment, screenshot, console, and network state — that a developer can reproduce and fix it without a round trip.
Inspection and sign-off. Verifying a release against its acceptance criteria before it ships.

QC only works when its output is reproducible. A defect that cannot be reproduced is not really controlled — it just becomes a “cannot reproduce” ticket that consumes triage time and gets closed unfixed. This is why the quality of a bug report is a QC concern in its own right.

QA vs. QC: a side-by-side comparison

Goal: QA — prevent defects. QC — find defects.
Focus: QA — the process. QC — the product.
Timing: QA — before and during development. QC — after something is built.
Nature: QA — proactive. QC — reactive.
Example: QA — adding a code-review requirement. QC — running the test suite and filing the bugs it exposes.
Metric it moves: QA — defect injection rate. QC — defect escape rate (how many bugs reach users).

Note that verification and validation cut across both: verification (“built it right”) leans QC when it means testing, while validation (“built the right thing”) often starts in QA-style requirements review.

Where QA and QC overlap

The line is real but not a wall. Three places where they meet:

Automated testing sits on the boundary. Writing a test is a QA act — you are hardening the process so a regression cannot slip through again. Running that test against a build is a QC act. A single bug-to-regression-test workflow does both.
Bug reports feed the process. A QC finding is data for QA. If the same defect class keeps appearing in reports, that is a signal to change a standard or add a gate, not just to fix another ticket.
Shift-left blurs timing. Practices like static analysis and CI gates move detection earlier, so QC-style checks start behaving like QA-style prevention. The activity is still detection; it just happens sooner.

How to apply both QA and QC on a software team

Label your work. For each quality practice you run, ask whether it prevents defects (QA) or finds them (QC). Teams over-invest in QC because it is visible and under-invest in QA because prevention is invisible when it works.
Strengthen QC evidence. Make it trivial to capture a reproducible report — the exact URL, browser, console, and network activity at the moment of failure. In-app tools like Klavity Snap attach that state automatically, which is what keeps a QC finding from decaying into “cannot reproduce.”
Automate the repeatable QC checks. Move stable, high-value verification into an automated suite so humans spend their time on judgment. Self-healing end-to-end tests such as Klavity AutoSim keep that suite green when the UI shifts, instead of failing on a renamed selector.
Close the loop into QA. Every escaped defect should produce one process change — a checklist item, a new test tier, a lint rule — and persona-driven review with tools like Klavity Sims can surface the usability gaps your scripted checks were never designed to catch. That is prevention informed by detection.

Done well, the two reinforce each other: QC tells you what is escaping, QA changes the process so it stops escaping, and QC verifies the change held. Treat them as one loop, not two departments.