QA, QC and Testing
Quality assurance (QA) and quality control (QC) are two complementary ways of reaching the quality described in the lesson on software quality. QA is process-oriented and preventive: it improves how the team works, so that fewer defects are made. QC is product-oriented and corrective: it examines what was built, finds where it falls short and gets those defects fixed. Testing is a major form of QC.
An example: three releases in a row ship Arabic screens with cut-off button labels. Testing the next release and reporting each cut-off label is QC: it corrects these defects in this product. Adding "every new screen is checked in Arabic on a narrow phone" to the team's definition of done (the checklist a story must meet before the team calls it finished) is QA: it makes the defect less likely on every future screen.
Why it matters
A team that thinks "QA" means "the testers at the end" keeps finding the same kinds of defects, because nobody changes what produces them. A team that writes processes but never checks the product has documents instead of evidence. The ISTQB Foundation syllabus v4.0 notes that test results serve both: in QC they are used to fix defects, and in QA they give feedback on how well the development and test processes are performing.
For you as a tester, the distinction decides what to do with what you find: a defect report fixes one defect, while a pattern of defects shown with evidence can change a whole process.
Quality assurance: improve the process, prevent defects
The ISTQB Foundation syllabus v4.0 describes QA as a process-oriented, preventive approach that focuses on implementing and improving processes. It assumes that a good process, followed correctly, produces a good product. QA covers the development process and the test process, and it is the responsibility of everyone on the project, not of one department. Typical QA activities:
- Agreeing a definition of done and entry and exit criteria (conditions for starting and finishing a piece of work) for stories and releases.
- Standards and templates for user stories, test cases and bug reports.
- Required workflow steps, such as a code review before every merge.
- Root cause analysis of escaped defects, followed by one concrete process change.
- Training, and checking that the team follows what it agreed (a process audit).
Quality control: check the product, correct defects
The same syllabus describes QC as a product-oriented, corrective approach that focuses on the activities supporting the achievement of appropriate levels of quality. Testing is a major form of QC; the other forms it names are formal methods (model checking and proof of correctness), simulation and prototyping.
"Product" means any work product, not only the finished application. Reviewing a requirements document and recording its defects is QC of that document, because a review is a form of static testing: examining a work product without running it, unlike dynamic testing, which runs the software. The next lesson covers static and dynamic testing. Reviews can sit on both sides: reviewing one specification is QC; making reviews compulsory for every specification is QA.
- Running test cases on a build and reporting the failures.
- Re-running a failed test after the fix, to confirm the defect is gone.
- Letting users try a clickable prototype before the feature is built.
Try it: Test Case Generator Try it: Requirements → Test Cases
Worked example: one recurring defect, two responses
QA and QC do not replace each other. QC without QA finds the same defects again and again; QA without QC has no evidence that the product is good or that the process works.
The situation: an online shop has released three versions with a wrong discount at checkout, and each time a customer noticed first. The latest case: a member who gets 10% off uses a 50.00 SAR coupon on a 300.00 SAR basket. The product owner had decided that the 10% applies first (270.00, then 220.00 SAR after the coupon), but checkout applied the coupon first (250.00, then 225.00 SAR).
- QC: the tester reproduces the 225.00 SAR total with the same basket, member account and coupon, reports it with the expected 220.00 SAR, re-runs the test after the fix and adds the case to the regression suite.
- QA: the retrospective (a regular team meeting about how the team works) asks why the defect was made and why it was not caught. The order in which discounts combine lived only in a chat thread with the product owner, so developers and testers each guessed.
- QA: from now on every pricing story states its rules as acceptance criteria with worked numbers, such as the 300.00 SAR basket above, and a tester reviews them before development.
- QA: over the next releases the team checks whether pricing defects still escape. The test results now give feedback on the process, not only on the product.
Quality assurance (QA)
Process-oriented, preventive
- Looks at:
- How the team works: requirements, reviews, release rules
- Aim:
- Fewer defects are made
- Question it asks:
- Will the way we work produce a good product?
- In the discount example:
- Pricing rules become acceptance criteria, reviewed before development
- Who does it:
- Everyone on the project
- Test results:
- Feedback on how well the processes work
Quality control (QC)
Product-oriented, corrective
- Looks at:
- What was built: any work product
- Aim:
- The defects that were made are found and fixed
- Question it asks:
- Is this product good enough, and what must be fixed?
- In the discount example:
- The wrong 225.00 SAR total is reported and fixed
- Who does it:
- Testers, developers, reviewers and users trying prototypes
- Test results:
- Used to fix defects
TestingPart of QC
A major form of QC
- Looks at:
- Work products, by review, and the running software
- Aim:
- Defects are found, with evidence about quality
- Question it asks:
- Where does this work product or build fall short?
- In the discount example:
- The failed test is re-run and joins the regression suite
- Who does it:
- Mostly testers; developers and reviewers too
- Test results:
- Produced here, used by both
Testing has its own column because it is a major form of QC, not a third approach.
Why job titles say QA but usually mean testing
In everyday use "QA" often means testing: "QA engineer", "send it to QA", "the QA environment". The ISTQB syllabus notes that people often use the two terms interchangeably, but they are not the same. Many roles called QA are mainly QC work: designing and running tests, automating checks and reporting defects.
You do not need to correct every job advert. Read the duties, not the title:
- "Execute test cases", "write automated tests" and "report bugs" describe testing, which is QC.
- "Define the test process", "set quality standards" and "run process audits" describe QA in the strict sense.
- Many testing roles include both: mostly QC, plus a voice in how requirements, reviews and releases are run.
Common mistakes
- Treating QA as a phase or a team at the end of development, instead of how the whole team works.
- Expecting more testing alone to keep quality up: testing finds the defects in this release, but unless the process changes, the same kinds of defects keep being made.
- Calling every review "QA": reviewing one document is QC; making reviews a required step is QA.
- Reporting the same type of defect again and again without pointing out the pattern.
- Writing processes that nobody follows or measures: QA that never looks at test results has no feedback.
The QA perspective
Most of a tester's hours go to QC: designing and running tests, reporting defects and re-checking fixes. That work shows you where defects cluster and which ones reach production, which is exactly what QA needs.
Make it visible. Record where each defect was probably introduced (requirement, design, code, configuration, data) if your tracker has a field for it. Bring patterns to the retrospective with numbers, propose one small change — a checklist item, an acceptance-criteria rule, a review step — and ask the QA question: "what would have prevented this, or caught it earlier?" Then check in later releases whether the change worked.
Practice exercise
Sort a month of activities into QA and QC
Below are eight activities from one team's month. The team works in sprints: fixed work cycles of one month or less. Classify each as QA or QC, and say which QC items are testing. Then propose one QC action and two QA actions for the note at the end.
1. Ran the login test cases on build 4.2 and logged two failures.
2. Agreed that no story enters a sprint without acceptance criteria.
3. Reviewed the refund requirements and listed five ambiguities.
4. Ran a short training session for product owners on writing acceptance criteria.
5. Re-ran the failed login test on the build with the developer's fix.
6. Created a bug report template with required fields for the team.
7. Let three customers try a clickable prototype of the new checkout.
8. After a retrospective, agreed that every story must test its API error paths.
Note: 6 of the last 9 production defects involved dates around midnight
in different time zones.- Ask of each activity: does it examine a specific work product, or change how the team works?
- For each QC item, ask whether it reviews a work product or runs the software (both are testing), or uses another form such as prototyping.
- For each QA action, say how the team will know whether it worked.
Show the model answer
QC and testing: 1 (dynamic testing of a build), 3 (a review is static testing) and 5 (confirmation testing of the fix). QC but not testing: 7 (prototyping, which the syllabus lists as a form of QC separate from testing).
QA: 2 (an entry rule), 4 (training), 6 (a standard template) and 8 (a process change agreed in a retrospective).
Time-zone pattern — QC: test the affected date logic around midnight in each supported time zone, report the failures and retest the fixes. QA: every story that stores or shows a date states its time zone in its acceptance criteria, and the code review checklist gains a time-zone item with one agreed storage rule (for example UTC). To see whether it worked, compare production time-zone defects over the next releases with the 6 of 9.
Frequently asked questions
Is testing part of QA or QC?
In ISTQB terms testing is a form of quality control, and a major one, because it examines the product. Its results also feed quality assurance, as evidence of how well the processes work. In everyday speech many people still call testing "QA".
Can the same person do QA and QC?
Yes. ISTQB describes QA as the responsibility of everyone on a project. A tester usually spends most of the time on QC and contributes to QA through process suggestions and retrospectives; a developer does QC when testing their own code and contributes to QA when following and improving the team's standards.
Where does quality management fit?
Quality management is the wider umbrella. The ISTQB glossary defines it as coordinated activities to direct and control an organisation with regard to quality, including a quality policy and quality objectives, quality planning, quality control, quality assurance and quality improvement. QA and QC are two parts of it.
Is QA more important than QC?
Neither replaces the other. Prevention reduces how many defects are made, but no process removes them all, so the product still has to be checked. And without QC results, QA has no evidence that its process changes help.
References
- ISTQB Certified Tester Foundation Level (CTFL) v4.0The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
- ISTQB GlossaryThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
Practise with Mutqan tools
Generate Given/When/Then acceptance criteria and a definition-of-done checklist from a user story.
Generate structured test cases (id, title, preconditions, steps, expected result, priority) from a feature description and field list.
Convert a list of numbered requirements into traceable test cases with a requirement-to-test matrix.
Go deeper
Your progress on this topic
Not started
Mark the topic complete when you have studied it and done the exercise.
Sign in to track your progress
Mark topics complete, continue where you left off and unlock specialisation exams.