Quality Management Plan¶
At a glance
- Purpose: State what "good enough" means for this project, how it will be verified, and who is accountable — before defects define it for you.
- Use it when: During planning, and revisited when quality problems appear. It is the project's answer to the question "how will we know the deliverable is acceptable?".
- Owner: The project manager with the quality or test lead; the product owner agrees the acceptance criteria.
- Related: Module 09 · Lab 20
How to use this template¶
- Translate the quality requirements into measurable quality attributes. Where an existing quality model (for example ISO/IEC 25010) is used, name the characteristics you actually intend to measure.
- Distinguish clearly between quality assurance — building the process so defects are less likely, such as reviews, standards, and pipeline gates — and quality control — detecting defects in the product, such as testing and inspection.
- Budget the cost of quality in both directions: prevention and appraisal, against the internal and external failure costs avoided. A plan that only lists testing is only half a plan.
- Define exit criteria numerically: defect density, severity thresholds, coverage targets, and the acceptance conditions for release.
- Assign ownership of each activity. Quality without a named owner becomes the tester's problem alone.
Field descriptions¶
| Field | What goes in it | Watch out for |
|---|---|---|
| Quality attribute | A characteristic that will be measured | "High quality" or "user-friendly" |
| Measure and target | The method and the threshold | Targets with no measurement method |
| Assurance activity | Process-level activity that prevents defects | Listing only test execution |
| Control activity | Detection and verification | Testing with no acceptance criteria |
| Owner | Who is accountable for each activity | Everything owned by the test lead |
| Cost of quality | Prevention, appraisal, and expected failure cost | Ignoring the cost of rework in the estimate |
| Exit criteria | Conditions for release | Criteria that cannot be checked objectively |
| Standards | Named industry or organisational standards actually used | Citing a standard the project does not follow |
Blank template¶
# Quality Management Plan — [Project name]
| | |
| --- | --- |
| **Version** | [1.0] |
| **Owner** | [Who] |
| **Agreed with** | [Product owner, technical lead, sponsor] |
| **References** | [Named standard or organisational policy actually applied] |
## 1. Quality attributes
| Attribute | Why it matters here | Measure | Target | Owner |
| --- | --- | --- | --- | --- |
| [e.g. Response time] | [User-facing effect] | [Method and conditions] | [Threshold] | [Who] |
| [e.g. Accessibility] | [Who depends on it] | [Method] | [Level of conformance] | [Who] |
## 2. Quality assurance — preventing defects
| Activity | When | Who | Evidence it happened |
| --- | --- | --- | --- |
| Peer review of every change | Before merge | Author's colleague | Review record |
| Coding and documentation standards | Continuous | Technical lead | Lint and review results |
| Requirements walkthrough with users | Per requirement set | Business analyst | Review notes and sign-off |
| Pipeline gate: tests and static checks must pass | Every commit | Automated | Build result |
## 3. Quality control — detecting defects
| Activity | Scope | When | Who | Entry and exit criteria |
| --- | --- | --- | --- | --- |
| Unit testing | [Components] | Continuous | Developers | [Coverage and pass conditions] |
| Integration testing | [Interfaces] | Per increment | Testers | [Conditions] |
| System and performance testing | [Whole system] | Before UAT | Testers | [Conditions] |
| User acceptance testing | [Agreed scenarios] | Before release | Users | [Written acceptance criteria] |
## 4. Defect management
| Severity | Definition | Target response | Who may accept as a known issue |
| --- | --- | --- | --- |
| P1 | [Blocking or data-loss effect] | [Immediate] | [Nobody below sponsor] |
| P2 | [Major function impaired] | [Within a sprint] | [Product owner] |
| P3 | [Cosmetic or minor] | [Backlog] | [Product owner] |
Defects are recorded in the [Defect Log](defect-log.md).
## 5. Cost of quality
| Category | Planned effort or cost | Basis |
| --- | --- | --- |
| Prevention | [Reviews, standards, training] | [Estimating basis] |
| Appraisal | [Testing, inspection, audits] | [Estimating basis] |
| Internal failure expected | [Rework during the project] | [Assumed defect rate and fix time] |
| External failure to avoid | [Defects reaching users] | [Why this is the priority] |
## 6. Release exit criteria
| Criterion | Threshold | Verified by |
| --- | --- | --- |
## 7. Assumptions and limitations
[What the plan assumes — availability of test environments, realistic data, user participation in UAT —
and what it does not cover.]
Worked example¶
From Lab 20, invented figures for teaching. A team chooses between two quality strategies for a 40-day build:
| Item | Option A — Test at the end | Option B — Review and test continuously |
|---|---|---|
| Prevention (reviews, standards) | 2 days | 5 days |
| Appraisal (testing) | 12 days | 12 days |
| Internal failure (rework) | 18 days | 7 days |
| Total | 32 days | 24 days |
| External failure risk | High — defects found by users after release | Low — the release is demonstrated on realistic data |
Option B appears more expensive in its first two rows and is 8 days cheaper overall, because the avoided rework is larger than the added prevention. This is the central arithmetic of the cost of quality, and it is also where over-claiming starts — so two cautions belong in the plan:
- The rework figures are estimates with a stated basis, not measured history. A project should replace them with its own observed defect and fix rates as soon as it has any.
- Prevention does not reduce appraisal needs. Option B still needs the same 12 days of testing; skipping it because "we review as we go" is a common and expensive misreading.
The exit criteria that go with the choice are deliberately numeric:
| Criterion | Threshold | Verified by |
|---|---|---|
| Open P1 and P2 defects | Zero | Defect log review |
| Acceptance scenarios passed | All agreed scenarios | UAT record |
| Upload of a 5 MB file under the agreed conditions | Completes without error | Test record |
| List screen with 500 records | Responds within the agreed time | Performance test |
Common mistakes¶
- Quality defined only by testing. Testing detects defects; reviews, standards, and clear requirements prevent them.
- Unmeasurable attributes. "User-friendly" cannot be verified, so it cannot be planned for either.
- Plan written and not used. A quality plan that does not appear in the schedule is a document, not a control.
- Quality owned by one role. When testing is the tester's only concern, defects arrive there instead of being prevented earlier.
- Exit criteria that cannot fail. "All features tested" is satisfied by running the tests.
- Ignoring the cost of quality in estimates. The rework avoided by prevention has to appear somewhere or the estimate is optimistic by construction.
- Citing a standard the project does not follow. Referencing a quality standard without applying it is inaccurate documentation.