Lesson 1 — Quality Management and Assurance¶

At a glance

Module: 09 — Quality Management
Level: Intermediate
Estimated time: 45 minutes
Example project: the mobile banking app

Learning objectives¶

By the end of this lesson you should be able to:

Distinguish fitness for purpose from conformance to requirements, and explain why both matter.
Contrast quality assurance with quality control, and verification with validation.
Apply the cost-of-quality model to justify preventive work.
Plan quality activities into a schedule rather than appending them to the end.

Prerequisites¶

Module 08 — Risk Management

Introduction¶

Quality in software is not "the absence of bugs". A system that does exactly what was specified, and is unusable in practice, has conformed to requirements and still failed. Conversely, a system that users love but that loses a transaction under load has all the value of a demo.

This lesson gives you two vocabularies for quality — fitness for purpose and conformance to requirements — and the mechanisms that produce both.

1. Two meanings of quality¶

View	Question it asks	Failure looks like
Fitness for purpose	Does it solve the user's real problem?	The system is correct and useless
Conformance to requirements	Does it do what the specification says?	The system is loved and unreliable

Quality management needs both. Requirement quality is where fitness for purpose is won or lost — which is why requirements review is a quality activity, not a scope activity. Module 05's requirement checks are also Module 09's prevention work, and recognising that overlap is the point of managing knowledge areas rather than treating them as separate departments.

2. Assurance and control¶

	Quality assurance (QA)	Quality control (QC)
Focus	The process	The product
Question	Are we working in a way that produces quality?	Is this output acceptable?
Timing	Throughout, designed in	At defined checkpoints
Typical activity	Peer review policy, coding standards, definition of done	Testing, static analysis, inspection
Acts on	How work is done	Whether work is acceptable

QA without QC is a policy nobody checks. QC without QA is a permanent clean-up crew. A project with only QC is one where every defect is found late and expensively; a project with only QA has no evidence.

Two further pairs, often confused:

Verification asks "are we building the product right?" — conformance to specification.
Validation asks "are we building the right product?" — fitness for purpose.

A system can pass every verification test and fail validation completely. UAT exists to catch exactly that.

3. The cost of quality¶

The cost-of-quality model divides quality spending into four categories, and its central finding is that money moves between them predictably.

Category	Meaning	Example
Prevention	Stop defects being created	Training, design review, clear requirements
Appraisal	Find defects after creation	Testing, inspections, static analysis
Internal failure	Defects found before release	Rework, retest, blocked builds
External failure	Defects found after release	Hotfixes, data repair, support, lost trust

Prevention and appraisal are costs of conformance; failures are costs of non-conformance. A defect found in production typically costs far more to fix than the same defect found in review, because by then it has reached users and the surrounding work depends on it. This is the economic argument for shifting effort earlier — and it is why "we have no time to test" is usually the most expensive sentence in a project.

4. Designing quality in¶

Reviews and inspections. A technical review is a structured examination of a work product by peers. An inspection follows a defined process with roles, entry criteria, and recorded defects. Structured review is one of the highest-yield quality activities available, and it needs no special tooling.
Test levels. Unit → integration → system → acceptance. Each answers a different question; a passing unit test says nothing about whether the system meets a user's need.
Static analysis and automated checks. Cheap, repeatable, and best used to catch the mechanical class of defect so that human review time goes to design and logic.
Definition of done. An agreed checklist stating what "complete" means for every item. It is the cheapest quality mechanism in existence, and it converts "I think it's finished" into a test.
Quality metrics. Defect density, defect escape rate, review coverage, and test pass rate. Useful for spotting trends; dangerous when used to rank individuals, which reliably produces under-reporting.

5. Quality and the other constraints¶

Quality is not independent of scope, schedule, and cost — it trades against them. The honest statement is not "we will do all of it well"; it is:which quality attributes matter most, and what will be traded away.

For the banking app, availability and data integrity outrank visual polish. For the analytics dashboard, usability outranks sub-second latency. Making those priorities explicit turns quality from an aspiration into a set of design decisions — and gives you a defensible answer when someone asks why the polish was shipped later.

Key terms¶

Term	Meaning
Fitness for purpose	The product solves the user's real problem
Conformance to requirements	The product does what the specification says
Quality assurance	Process-focused activities that build quality in
Quality control	Product-focused activities that detect defects
Verification	Are we building the product right?
Validation	Are we building the right product?
Cost of quality	Prevention, appraisal, internal failure, and external failure costs
Definition of done	An agreed checklist defining completion
Defect escape rate	Proportion of defects found after release rather than before

Worked example¶

Task: set up quality management for the illustrative mobile banking app release. Figures are assumed for teaching.

Step 1 — Turn ambiguity into attributes. "High quality" becomes: zero unbalanced transactions; a transaction history that is accurate to the second; a balance that is never shown stale without an indicator; and a login flow a first-time user completes without help.

Step 2 — Assign each attribute a mechanism. Balance accuracy → reconciliation test run nightly. Stale balance → a design rule plus a review check. Login usability → moderated testing with five users. Data integrity → an invariant check in the automated suite.

Step 3 — Separate QA from QC.

QA: a code review requirement of one reviewer for all changes to the transaction module; automated invariant checks that run on every commit; a definition of done including "reconciliation test passes".
QC: the reconciliation test itself; the moderated usability session; the release acceptance test.

Step 4 — Budget quality activities, and see the argument. Assume a defect in the transaction path found in review costs 1 unit; the same defect found in internal testing costs about 4; found in production, about 20, plus reputational damage. The review requirement therefore pays for itself if it catches even a small number of transaction defects — the arithmetic is not close.

Step 5 — Put them in the schedule. Reviews need calendar time and cannot be appended. Reserve review time inside each activity's duration, or the schedule will silently reclassify review as optional.

Step 6 — Choose your metrics and state the risk. Track defect escape rate and review coverage at team level. Do not publish per-developer defect counts: that reliably causes defects to be under-reported, which destroys the metric's value and the trust it depends on.

Common misconceptions¶

“Testing improves quality”

Testing detects defects; it does not prevent them. Prevention comes from requirements quality, design review, and clear definitions of done. Testing alone raises the cost of quality by moving spend into appraisal and failure.

“More testing is always better”

Testing has diminishing returns, and beyond a point the defects it finds cost more to fix than they are worth — or are cosmetic. The judgement is which risks justify which tests, not how much testing fits.

“Quality is the tester's job”

Quality is produced by whoever writes the requirements, design, and code. A test team can only report what it finds.

Practical activity¶

Plan quality for one release. Using an example project:

Define three quality attributes in measurable terms, avoiding the word "good".
For each, name one QA mechanism and one QC mechanism.
State your definition of done as a checklist with at least five verifiable items.
Identify one activity where a defect would be most expensive if found late, and justify a prevention investment for it.
Choose two quality metrics and state how you will avoid the misuse you identified above.

What "good" looks like: attributes that could be tested, mechanisms that are concrete rather than aspirational, a definition of done where every item is checkable, and a metrics plan that names its own misuse risk.

Self-assessment¶

A system passes every acceptance test and users abandon it. Which view of quality failed, and from what activity would you have caught it?
Give an example of a QA activity and an example of a QC activity for the same release.
Why is a defect found in production usually much more expensive than the same defect found in review?
Why does publishing per-developer defect counts make a metrics programme worse?
Apply it — mobile banking app. Defects found in testing have risen from 12 to 40 over two sprints, with the release four sprints away. The team proposes adding two testers for the final two sprints. The security review before release is fixed and cannot be moved.

Hint: A strong answer names which category of quality cost the proposal falls into and where the money should go instead.

Show answers

Fitness for purpose failed — the product conformed to its requirements but did not solve the user's real problem. Validation activities would have caught it: user research before building, and usability testing or UAT with real users during development.
QA: a requirement that every change to the payment module receives a peer review. QC: the inspection or test that verifies a particular change is correct.
Because the defect has reached users, so the costs multiply: the fix is urgent rather than planned, surrounding work depends on the faulty output, data may need repair, and trust is damaged. Almost every factor makes late correction more expensive than early correction.
Because it makes reporting a defect personally costly, so defects are under-reported — and a metric based on voluntary disclosure collapses as soon as disclosure is punished. Use defect data at team and process level to find systemic causes.
The proposal buys appraisal — finding defects after they exist — which is the most expensive moment to deal with them and cannot repair a design fault. A rising defect count late in delivery is usually evidence that prevention was missing, so spend the money there: review requirements and acceptance criteria before work starts, add automated checks and code review, and stabilise the test environment. In the cost-of-quality model every defect you find later moves from appraisal into internal or external failure, the two categories that consume value rather than create it. Two other things follow. The security review is a fixed external gate, so freeze scope now instead of discovering failures during it — and do not report the trend as “finding more defects means testing is working better” unless the earlier-stage detection is also rising.

Summary¶

Quality means both fitness for purpose and conformance to requirements; both require work.
QA acts on the process, QC on the product; verification asks "right product built?", validation asks "right product?".
Prevention and appraisal are costs of conformance; internal and external failures are costs of non-conformance, and late defects cost far more.
Reviews, test levels, static analysis, and a definition of done are the practical mechanisms.
Quality trades against scope, schedule, and cost — so state priorities rather than promising everything.

Further learning¶

Module 10 — Team Resources & Communication covers the team conditions that make quality achievable.
A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Project Management Institute — quality management.
Software Engineering at Google, Titus Winters, Tom Manshreck, and Hyrum Wright (eds.) — chapters on code review and testing culture, available online.
ISO/IEC 25010, Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model, International Organization for Standardization.

Next¶

You have completed Module 09. Continue to Module 10 — Team Resources & Communication.