Quality Control and Quality Assurance
Chapter Twenty-Four
Syllabus topic Module 1, "Definition of Quality and Quality Assurance: Distinction between Quality Assurance (QA), Quality Control (QC)"
Pages 129 to 134 of 622
In one line
Quality control checks the product to find what is wrong with it; quality assurance works on the process, so that there is less to find, and gives everyone justified confidence that the product will meet its requirements.
In the wording a student can write in an examination: quality assurance (QA) is a "process that is focused on providing confidence that quality requirements are fulfilled" (ISO/IEC/IEEE 12207:2026); quality control (QC) is the "tasks to evaluate the quality of services as delivered or the quality of developed or manufactured products" (the same standard). QA is process-oriented and preventive: it defines, audits and improves the way work is done. QC is product-oriented and corrective: it examines what has been built and finds its defects. Testing is, in the ISTQB syllabus's words, "a major form of quality control", and reviews of work products are another.
Two terms that are often confused
In everyday use the two terms blur. ASQ's glossary warns that they have "many interpretations" and that in practice they are often used interchangeably, for anything done to ensure quality. The ISTQB syllabus notes a second confusion, between quality assurance and testing: people often use the two terms as if they meant one thing, but "testing and QA are not the same." By the standards' definitions, testing is quality control.
The difference matters because the two do different jobs, need different skills, and fail in different ways. A project with excellent testing and no quality assurance finds its defects expensively, late, and over and over again. A project with fine process documents and no quality control has no evidence that the product works.
Quality control: checking the product
The standard definition is short: QC is the "tasks to evaluate the quality of services as delivered or the quality of developed or manufactured products" (ISO/IEC/IEEE 12207:2026). An older definition in the same vocabulary adds what follows the evaluation: "monitoring service performance or product quality, recording results, and recommending necessary changes" (ISO/IEC/IEEE 24765).
The object of quality control is always a product: code, a design, a requirements document, a test plan, a build, a released system. Its methods examine that product:
- Testing, which runs the software and compares what it does with what it should do.
- Reviews and inspections of work products, which read them for defects without running anything (Chapters Twenty-Eight and Twenty-Nine, on reviews and inspection).
- Other checks that the syllabus lists beside testing: formal methods, simulation and prototyping.
The ISTQB syllabus describes testing, and with it this whole side of quality work, in one sentence: "Testing is a product-oriented, corrective approach that focuses on those activities supporting the achievement of appropriate levels of quality." It then places testing inside quality control: "Testing is a major form of quality control, while others include formal methods (model checking and proof of correctness), simulation and prototyping."
Quality Control and Quality Assurance
A note for readers who meet older copies. The release notes of version 4.0.1 record that, in this section, the word QC was replaced with testing, "because the section compares QA with testing, not with QC". An older copy may therefore call QC product-oriented and corrective where version 4.0.1 says it of testing. The two versions agree on the substance: the product-oriented, corrective side of quality work is quality control, and testing is its largest part.
Quality assurance: confidence from the process
Quality assurance is defined by what it gives: confidence. ISO/IEC/IEEE 12207:2026 calls it a "process that is focused on providing confidence that quality requirements are fulfilled"; ISO/IEC/IEEE 15288:2023 places it as the "part of quality management focused on providing confidence that quality requirements are fulfilled". The word itself has a standard meaning: assurance is "grounds for justified confidence that a claim has been or will be achieved" (ISO/IEC/IEEE 15026-1:2025). QA's product, in other words, is evidence that the organisation's way of working can be trusted to produce what was promised.
The ISTQB syllabus gives its method: "QA is a process-oriented, preventive approach that focuses on the implementation and improvement of processes. It works on the basis that if a good process is followed correctly, then it will generate a good product." And its scope: "QA applies to both the development and testing processes, and is the responsibility of everyone on a project."
Its typical activities act on the way work is done:
- Defining processes and standards: how requirements are written, how code is reviewed, what a test plan must contain, when a change may be released.
- Training people to follow them.
- Audits: an audit is an "independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria" (ISO/IEC/IEEE 12207:2026). A QA audit asks whether the process was followed, and produces findings about the process.
- Measuring and improving the process, using the data that quality control produces, which is the subject of the worked example below.
Prevention and detection
The simplest way to hold the two apart is by what they do to a defect. Quality assurance tries to stop a defect from being made; quality control tries to find the defects that were made anyway.
ExamReg shows the difference on a single kind of defect. Suppose the fee form keeps accepting impossible input, such as a negative number of backlog papers. Quality control finds each instance: a tester enters -1, the form accepts it, a defect report is written, the developer fixes that field, and the test is added to the regression suite. Next release, a different form has the same kind of defect, and the cycle repeats. Quality assurance asks why the same kind keeps appearing, and changes the process: a shared validation component that every form must use, a rule in the coding standard, and an item on the code review checklist. The defect stops being made.
Quality Control and Quality Assurance
Neither replaces the other. Prevention is never perfect, so detection is always needed; and detection alone is expensive, because each defect is found only after it has been built, and a process that keeps making the same mistake keeps paying for it.
The same results, used twice
The ISTQB syllabus names the point where the two meet: "Test results are used by QA and testing. In testing they are used to fix defects, while in QA they provide feedback on how well the development and test processes are performing." The program below reads the ExamReg release 2.0 defect data, fixed once for this whole book, first as quality control reads it and then as quality assurance does.
found_by = {"requirements review": 16, "design review": 24, "code review": 34,
"unit testing": 44, "integration testing": 32, "system testing": 28,
"acceptance testing": 10, "after release": 12}
by_type = {"input validation": 58, "logic and computation": 44, "interface": 30,
"user interface": 24, "data and database": 18, "documentation": 12,
"performance": 8, "security": 6}
total = sum(found_by.values())
assert total == sum(by_type.values()) == 200 # ExamReg release 2.0
# Quality control reads the data for the PRODUCT: what is wrong, and was it caught in time?
escaped = found_by["after release"]
print(f"QC: {total} defects in release 2.0; {total - escaped} found before release;"
f" {escaped} found by students after it")
# Quality assurance reads the same data for the PROCESS: where do defects come from,
# and which activities catch them?
reviews = sum(n for activity, n in found_by.items() if activity.endswith("review"))
tests = sum(n for activity, n in found_by.items() if activity.endswith("testing"))
print(f"QA: caught by reviews {reviews} ({reviews / total:.0%}), by tests {tests}"
f" ({tests / total:.0%}), by students {escaped} ({escaped / total:.0%})")
commonest = max(by_type, key=by_type.get)
print(f"QA: the commonest kind is {commonest}: {by_type[commonest]} of {total}"
f" ({by_type[commonest] / total:.0%})")QC: 200 defects in release 2.0; 188 found before release; 12 found by students after it
QA: caught by reviews 74 (37%), by tests 114 (57%), by students 12 (6%)
QA: the commonest kind is input validation: 58 of 200 (29%)Quality control's reading is about this release. There were 200 defects; 188 were caught before release and 12 reached students. Every one must be fixed and its fix confirmed, and the 12 in production come first, because students are meeting them now.
Quality Control and Quality Assurance
Quality assurance's reading is about the next release. Reviews caught 74 defects, 37 per cent, before any code ran, which says the review process is earning its time. But 12 escaped, 6 per cent of the total, and the commonest kind of defect, input validation, is 58 of 200, 29 per cent: nearly three in every ten defects are the same kind of mistake. That is a process signal, not a product one. The response is the one in the last section: a shared validation component, a coding rule and a review checklist item, followed by a check in release 2.1 that the count has fallen. Chapter Eighty, on using defect data to improve the process, takes this analysis much further.
A review is quality control; checking that reviews happen is quality assurance
One pair of activities causes more confusion than any other, because both involve reading documents.
- A code review of the fee function reads the product and finds its defects. It is quality control, of a static kind.
- An audit at the end of a sprint, which checks whether every change to the fee rules actually went through a code review as the process requires, reads records of the process. It is quality assurance.
The rule that settles every such case is to ask what the activity examines. If it examines the product, it is quality control; if it examines or changes the way the product is made, it is quality assurance.
QA and QC side by side
| Quality assurance (QA) | Quality control (QC) | |
|---|---|---|
| Standard definition | "process that is focused on providing confidence that quality requirements are fulfilled" | "tasks to evaluate the quality of services as delivered or the quality of developed or manufactured products" |
| Focus | The process | The product |
| Aim | Prevent defects; give justified confidence | Find defects so they can be corrected |
| Approach | Preventive, proactive | Corrective, reactive |
| When | Throughout, starting before the product exists | Once a work product exists to examine |
| Typical activities | Process definition, standards, training, process audits, process improvement | Testing, reviews and inspections of work products |
| Who | Everyone on the project, often led by an SQA group | Testers, reviewers and inspectors |
| Output | Defined processes, audit findings, improvements | Defect reports, test results, pass or fail decisions |
| Question it asks | Is the work being done in a way that will produce quality? | Does this product meet its requirements? |
Worked contrast: the ExamReg project's quality activities
| Activity on the ExamReg project | QA or QC | Why |
|---|---|---|
| Writing the coding standard, with its rules for validating input | QA | Defines how code is written, before the code exists |
| Training the developers on the payment gateway's interface | QA | Prevents defects by building skill |
| Deciding that every change to a fee rule must be code reviewed | QA | Sets the process |
| Code reviewing the fee function against the checklist | QC | Examines the product and finds its defects |
| Running the late-fee test cases on build 2.0.1 | QC | Examines the product by running it |
| Checking the hall ticket PDF against its specification | QC | Examines a product against its requirements |
| Auditing whether every fee change in the sprint was reviewed | QA | Examines whether the process was followed |
| Analysing release 2.0's defects by type and changing the standard | QA | Improves the process from the product's data |
Quality Control and Quality Assurance
What it does not mean
Quality assurance is not another name for testing. Testing is quality control; QA is about the process, and a tester's job title does not change that.
Quality control is not only testing. Reviews and inspections of documents and code examine the product too.
Quality assurance does not make quality control unnecessary. A good process lowers the number of defects made; it never lowers it to zero.
Quality assurance is not one department's job alone. In the syllabus's words, it "is the responsibility of everyone on a project", even when a separate SQA group leads it.
Quick revision
- QA: "process that is focused on providing confidence that quality requirements are fulfilled" (ISO/IEC/IEEE 12207:2026); "part of quality management" (ISO/IEC/IEEE 15288:2023). Process-oriented, preventive.
- QC: "tasks to evaluate the quality of services as delivered or the quality of developed or manufactured products" (ISO/IEC/IEEE 12207:2026). Product-oriented, corrective.
- Assurance: grounds for justified confidence that a claim has been or will be achieved.
- Testing is "a major form of quality control"; so are reviews and inspections of work products (ISTQB v4.0.1, section 1.2.2).
- QA prevents defects; QC detects them. Both are needed.
- The same test results serve both: QC uses them to fix defects, QA as feedback on the process.
- A review of the product is QC; an audit of whether reviews happen is QA.
- ExamReg release 2.0: 188 of 200 defects caught before release, 12 after; reviews caught 74 (37 per cent); input validation is 58 of 200 (29 per cent), a process signal.
Test yourself
1. Define quality assurance and quality control as the standards do. Quality assurance is a process focused on providing confidence that quality requirements are fulfilled (ISO/IEC/IEEE 12207:2026), and part of quality management (ISO/IEC/IEEE 15288:2023). Quality control is the tasks that evaluate the quality of delivered services or of developed or manufactured products (ISO/IEC/IEEE 12207:2026).
2. Distinguish QA from QC under five headings. Focus: QA the process, QC the product. Aim: QA prevents defects and gives confidence, QC finds defects to be corrected. Approach: QA preventive, QC corrective. Timing: QA throughout, from before the product exists; QC once a work product exists. Activities: QA defines, audits and improves processes; QC tests, reviews and inspects work products.
Quality Control and Quality Assurance
3. Is testing quality assurance or quality control? Explain. Quality control. It examines the product by running it and finds defects so that they can be corrected; the ISTQB syllabus calls it product-oriented and corrective, and a major form of quality control, while QA is process-oriented and preventive.
4. How can the same test results be used for both QA and QC? QC uses them to fix defects in the product. QA uses them as feedback on the process: for example, finding that 58 of ExamReg's 200 defects were input validation defects shows a weakness in how code is written and reviewed, which QA corrects with a shared validation component, a coding rule and a checklist item.
5. Classify with reasons: a code review of a module, and an audit of whether code reviews were held. The code review is quality control, because it examines the product for defects. The audit is quality assurance, because it examines whether the process was followed.
The rest of this subject
These notes are cut from the University's printed syllabus. Open the syllabus itself, or the past papers, for the same subject.