Quality assurance vs quality control is one of the most commonly confused distinctions in project quality management, yet getting it right has significant practical consequences for how quality is planned, resourced, and implemented on projects. QA and QC are complementary disciplines that address quality from opposite ends of the delivery process — QA prevents defects from being introduced, while QC detects defects that have been introduced. Projects that invest in QA alone find defects too late and pay high remediation costs; projects that invest in QC alone find defects after the fact but never improve the underlying processes that generate them. Understanding how QA and QC work together is the foundation of effective project quality management.
Defining Quality Assurance
Quality Assurance (QA) is the systematic set of activities designed to provide confidence that quality requirements will be fulfilled — in other words, building quality into the delivery process proactively before defects occur. QA is process-focused and preventive: it examines whether the methods, tools, standards, and practices being used to create the deliverable are adequate to produce the required quality level. QA activities include process audits, methodology reviews, standards compliance checks, training and competency verification, and lessons-learned integration.
QA answers the question: “Do we have the right processes in place to consistently produce quality outputs?” If the answer is no, QA activities identify and correct process deficiencies before they produce defects. The ISO 9001 quality management standard is built on QA principles — it defines a management system framework for consistently meeting customer requirements and improving processes continuously.
Defining Quality Control
Quality Control (QC) is the set of activities designed to verify that the deliverables produced by the delivery process meet the defined quality requirements — in other words, inspecting output quality after it has been produced to detect defects before they reach the customer. QC is product-focused and reactive: it examines what has already been made to determine whether it meets specification.
QC activities include testing (unit, integration, system, acceptance), inspection (code review, document review, physical inspection), measurement (defect density, test coverage, performance benchmarks), and sampling. QC answers the question: “Does this specific deliverable meet the required quality standard?” If the answer is no, the defect is identified and corrected — but QC alone does not prevent the same defect from recurring in the next deliverable. That prevention requires QA to identify and fix the process that produced the defect.
The Five Key Differences
Understanding the specific dimensions on which QA and QC differ clarifies when to apply each and how to resource them appropriately:
- Focus: QA focuses on processes (how work is done); QC focuses on products (what has been done).
- Orientation: QA is proactive and preventive (stop defects from occurring); QC is reactive and detective (find defects that have occurred).
- Timing: QA occurs throughout the delivery process, especially at the beginning; QC occurs at defined checkpoints after deliverables are produced.
- Responsibility: QA is everyone’s responsibility — every team member contributes to quality by following processes correctly; QC is typically the responsibility of dedicated testers or inspectors.
- Outcome: QA reduces the likelihood of defects; QC identifies defects before they reach customers.
How QA and QC Work Together
The relationship between QA and QC is complementary and reinforcing. QA establishes the processes and standards that, when followed, should produce quality outputs. QC verifies that the outputs actually meet those standards in practice. When QC finds defects, the information feeds back into QA — root cause analysis identifies which process, standard, or practice failed to prevent the defect, and QA activities are updated to close the gap. This feedback loop is the engine of continuous quality improvement: QC data drives QA improvement, which reduces QC defect rates, which improves delivery quality progressively over time.
Without QA, QC becomes the only defence against defects — a reactive strategy that catches problems too late at high remediation cost. Without QC, QA’s effectiveness cannot be verified — processes may look adequate on paper but fail in practice without the measurement that QC provides. Both are necessary; neither is sufficient alone.
“Inspection does not improve the quality of a product. It merely separates the good from the bad. The purpose of quality control is to give information to management to improve the process.” — W. Edwards Deming
QA and QC in Software Projects
In software development, the QA/QC distinction maps clearly to specific practices. QA activities include: defining coding standards and architectural principles, establishing code review processes, implementing a Definition of Done that includes quality criteria, training developers in secure coding practices, and running process retrospectives to identify and eliminate recurring defect patterns. QC activities include: unit testing, integration testing, system testing, performance testing, security scanning, and user acceptance testing. The shift-left movement in software quality management is essentially a QA principle applied to QC activities — moving testing (QC) earlier in the development process to catch defects when they are cheaper to fix, rather than discovering them in production where they are most expensive.
QA vs QC Quick Reference
| Dimension | Quality Assurance (QA) | Quality Control (QC) |
|---|---|---|
| Focus | Process | Product / deliverable |
| Orientation | Proactive, preventive | Reactive, detective |
| Timing | Throughout delivery | After production |
| Goal | Prevent defects occurring | Find defects before delivery |
| Example activities | Process audits, standards, training | Testing, inspection, measurement |
Key Takeaways
- QA is process-focused and preventive — it builds quality into the delivery process before defects occur; QC is product-focused and detective — it finds defects after they are produced.
- Both are necessary and complementary: QA without QC cannot verify that processes are effective; QC without QA catches defects too late without improving the processes that generate them.
- QA is everyone’s responsibility — every team member contributes by following processes correctly; QC is typically performed by dedicated testers or inspectors at defined checkpoints.
- QC defect data feeds back into QA improvement — this feedback loop is the engine of continuous quality improvement that progressively reduces defect rates over time.
- The “shift-left” movement in software quality is a QA principle applied to QC — moving testing earlier in the development cycle to catch defects when they are cheapest to fix.
- Deming’s insight remains fundamental: QC identifies defects; QA improves the processes that create them — only process improvement produces sustainable quality gains.
