# Software Quality Assurance Plan: [Project or product name]

> Complete Software Quality Assurance Plan (SQAP). The structure follows
> the SQA plan content described in IEEE 730-2014: purpose and scope,
> organisation and independence, SQA activities across the life cycle
> (product assurance and process assurance), standards, reviews and audits,
> problem reporting, tools, supplier control, records, training, risk and
> metrics. Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- SQA checks that the project's products and processes conform to the plans,
  standards and requirements that apply. It does not replace testing; it
  checks that testing (and everything else) is done as planned.
- Size the plan to the project. A small team can merge roles, but must still
  show who is independent enough to report non-conformance honestly.
- Fill section 2 (organisation and independence) first. If no one can
  escalate a quality issue outside the delivery chain, fix that before anything else.
- Every activity in section 4 should produce a record listed in section 12.
-->

## Document control

<!-- Guidance: Identify the plan so every copy traces to one version. Status moves Draft -> In review -> Approved -> Superseded. -->

| Field | Value |
|---|---|
| Document ID | [SQAP-PROJECT-001] |
| Project / product | [Project name] [release or contract number] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@sqa-lead] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Contract or quality requirements | [Contract clause / customer quality requirement / internal QMS procedure] |
| Related documents | [Project management plan], [SCM plan], [V&V plan], [Test strategy], [Risk register] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| SQA lead | [@name] | [Approved / Rejected / Approved with comments] | YYYY-MM-DD |
| Project manager | [@name] | [Decision] | YYYY-MM-DD |
| Head of quality | [@name] | [Decision] | YYYY-MM-DD |
| Customer representative (if contractual) | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: One row per published version. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial draft |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Added supplier audit for the outsourced mobile client |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved at project kick-off |

## Contents

<!-- Guidance: Keep in sync with headings. -->

1. [Purpose and scope](#1-purpose-and-scope)
2. [Organisation and independence](#2-organisation-and-independence)
3. [Standards, practices and conventions](#3-standards-practices-and-conventions)
4. [SQA activities by life-cycle phase](#4-sqa-activities-by-life-cycle-phase)
5. [Product assurance](#5-product-assurance)
6. [Process assurance](#6-process-assurance)
7. [Reviews and audits schedule](#7-reviews-and-audits-schedule)
8. [Problem reporting and corrective action](#8-problem-reporting-and-corrective-action)
9. [Tools, techniques and methods](#9-tools-techniques-and-methods)
10. [Supplier and subcontractor control](#10-supplier-and-subcontractor-control)
11. [Risk management](#11-risk-management)
12. [Records collection, maintenance and retention](#12-records-collection-maintenance-and-retention)
13. [Training](#13-training)
14. [Metrics](#14-metrics)
15. [Glossary and references](#15-glossary-and-references)

## 1. Purpose and scope

<!-- Guidance: State what the plan covers (products, phases, organisations) and what it does not. Name the quality requirements the project must meet. -->

### 1.1 Purpose

This plan defines how [organisation] will provide objective evidence that
[project name] produces software, documentation and services that conform
to their requirements, and that the project follows its agreed
processes. It is the reference for all SQA tasks, reviews and audits.

### 1.2 Scope

| Aspect | In scope | Out of scope |
|---|---|---|
| Products | [Web application, REST API, mobile app, user documentation] | [Third-party SaaS used as-is] |
| Life-cycle phases | Concept to transition into operations | Operations after warranty period |
| Organisations | [Internal teams, supplier X] | [Customer IT department] |
| Processes | Requirements, design, construction, testing, configuration management, release | [Corporate procurement] |

### 1.3 Quality requirements and objectives

| ID | Quality objective | Measure | Target |
|---|---|---|---|
| QO-01 | *Example:* Deliverables pass review first time | Percentage of documents approved without major findings | >= 80% |
| QO-02 | *Example:* Process conformance | Audit findings of major severity per quarter | 0 |
| QO-03 | *Example:* Product quality in operation | Severity-1 incidents in first 90 days after release | 0 |
| [QO-nn] | [Objective] | [Measure] | [Target] |

### 1.4 Tailoring

[State which parts of the organisation's quality management system or of
this template are tailored for the project, why, and who approved it.
Example: "Formal inspection replaced by pull-request review for code with
risk class C, approved by head of quality YYYY-MM-DD."]

## 2. Organisation and independence

<!-- Guidance: Show who does SQA, who they report to and how they escalate. Independence (technical, managerial, financial) is what makes SQA findings credible. -->

### 2.1 Organisation

```mermaid
flowchart TB
  sponsor["Project sponsor"]
  hq["Head of quality"]
  pm["Project manager"]
  sqa["SQA lead"]
  dev["Development teams"]
  test["Test team"]
  scm["Configuration manager"]
  sponsor --> pm
  sponsor --> hq
  hq --> sqa
  pm --> dev
  pm --> test
  pm --> scm
  sqa -. "audits and reviews" .-> dev
  sqa -. "audits and reviews" .-> test
  sqa -. "audits and reviews" .-> scm
```

The SQA lead reports to the head of quality, not to the project manager,
so that findings can be escalated without depending on the delivery chain.

### 2.2 Responsibilities

| Role | SQA responsibilities |
|---|---|
| Head of quality | Approves this plan; receives escalations; assigns SQA staff |
| SQA lead | Plans and performs SQA activities; reports findings; tracks corrective actions |
| Project manager | Provides resources and access; ensures corrective actions are implemented |
| Technical leads | Apply standards; host reviews; respond to findings |
| Test manager | Provides test evidence; participates in product assurance |
| Configuration manager | Supports configuration audits; maintains baselines |
| Supplier quality contact | Delivers supplier quality records; hosts supplier audits |

### 2.3 Independence

| Dimension | Arrangement | Residual concern |
|---|---|---|
| Technical | SQA staff did not author the products they assess | None |
| Managerial | SQA lead reports to head of quality | Shared sponsor; escalation path to quality board |
| Financial | SQA budget set by quality department | None |

### 2.4 Escalation

Unresolved findings are escalated in this order: technical lead (5
working days) -> project manager (5 working days) -> head of quality ->
project sponsor. Escalations are recorded in the finding log.

## 3. Standards, practices and conventions

<!-- Guidance: List the standards that apply to products and processes. SQA checks conformance against exactly these, so be specific (name, version). -->

| Area | Standard, practice or convention | Version | Conformance checked by |
|---|---|---|---|
| Requirements | [SRS template based on ISO/IEC/IEEE 29148] | [x.y] | Document review |
| Design | [Architecture description template, ADR practice] | [x.y] | Design review |
| Code | [Coding standard], [lint configuration] | [x.y] | Static analysis, code review |
| Testing | [Test strategy TS-ORG-001] | [x.y] | Test readiness review, test audit |
| Security | [Secure development standard], OWASP ASVS level [2] | [x.y] | Security review |
| Accessibility | WCAG 2.2 level AA | 2.2 | Accessibility audit |
| Documentation | [Style guide] | [x.y] | Document review |
| Configuration management | [SCM plan SCMP-xxx] | [x.y] | Configuration audit |

## 4. SQA activities by life-cycle phase

<!-- Guidance: Plan SQA tasks for each phase of the project's life cycle. For iterative models, map phases to recurring events (sprint, release) instead of calendar stages. -->

| Phase | SQA activity | Input | Output (record) | Responsible |
|---|---|---|---|---|
| Initiation | Review project plans for quality requirements | Project plan, contract | Plan review report | SQA lead |
| Initiation | Confirm standards and tools are defined | This plan, standards list | Readiness checklist | SQA lead |
| Requirements | Participate in requirements review; check traceability | SRS, stakeholder needs | Review record, traceability check | SQA lead, analysts |
| Design | Check design review is held and findings closed | Architecture, ADRs | Review record | SQA lead |
| Construction | Sample code reviews for conformance to coding standard | Pull requests | Sampling report | SQA engineer |
| Construction | Check CI quality gates are enforced | Pipeline configuration | Gate audit record | SQA engineer |
| Testing | Test readiness review; audit test execution against plan | Test plan, test logs | Audit report | SQA lead |
| Release | Physical and functional configuration audit support | Release baseline | Audit report | SQA lead, CM |
| Release | Confirm completion criteria and open findings before go-live | Test completion report | Release quality statement | SQA lead |
| Transition | Check handover documents and training records | Runbooks, user guides | Handover checklist | SQA engineer |
| Closure | Lessons learned; SQA effectiveness review | Finding log, metrics | Closure report | SQA lead |

## 5. Product assurance

<!-- Guidance: Product assurance checks the work products: are they complete, conformant and acceptable? Say which products are assessed, how, and against which criteria. -->

### 5.1 Products subject to assurance

| Product | Assessment method | Criteria | Frequency |
|---|---|---|---|
| *Example:* Software requirements specification | Formal review with checklist | Template conformance, testable requirements, traceability | Each baseline |
| *Example:* Source code | Sampling of merged pull requests (10% or at least 5 per sprint) | Coding standard, review evidence, tests present | Each sprint |
| *Example:* Release package | Physical configuration audit | Contents match release baseline and release notes | Each release |
| *Example:* User documentation | Review against style guide | Accuracy, completeness, accessibility | Each release |
| [Product] | [Method] | [Criteria] | [Frequency] |

### 5.2 Conformance evaluation

Each assessment produces a result of Conformant, Conformant with minor
findings, or Non-conformant. Non-conformant products are not baselined
until the findings are closed or a waiver is approved (section 8.4).

### 5.3 Acceptability of products

[Describe how SQA checks that products meet customer acceptance criteria,
for example by reviewing the UAT plan and witnessing a sample of acceptance tests.]

### 5.4 Life-cycle support and measurement of products

Product quality measures (defect density, test coverage, static analysis
violations) are collected as described in section 14 and reviewed at each
phase gate.

## 6. Process assurance

<!-- Guidance: Process assurance checks that people follow the defined processes. Sample real work, not slide decks. -->

| Process | What SQA checks | Method | Frequency |
|---|---|---|---|
| Requirements management | Changes go through change control; traceability maintained | Audit of change log and trace matrix | Monthly |
| Design | Decisions recorded as ADRs; reviews held | Sample of ADRs and review minutes | Each release |
| Code review | Every merge has an approved review by someone other than the author | Repository settings check and sampling | Each sprint |
| Testing | Tests executed per plan; results recorded; defects triaged | Audit of test logs | Each test cycle |
| Configuration management | Baselines, branching and change control per SCM plan | Configuration audit | Each release |
| Release management | Go/no-go criteria applied and recorded | Witness go/no-go meeting | Each release |
| Supplier management | Supplier follows agreed process | Supplier audit (section 10) | [Twice per contract] |

### 6.1 Assessment of the project's life-cycle model

[Confirm that the project's chosen life-cycle model and its plans are
consistent with the organisation's processes and the contract, and that
the plans themselves are adequate. Record the result in the plan review report.]

### 6.2 Assessment of the environment for development

[Check that development, build and test environments are controlled:
access, versions, backups, and that tools are qualified where required.]

## 7. Reviews and audits schedule

<!-- Guidance: List every formal review and audit with timing and participants. Use the gantt for orientation, the table for detail. -->

| ID | Review or audit | Type | Timing | Participants | Exit criteria |
|---|---|---|---|---|---|
| RA-01 | Plan review | Management review | Week 2 | PM, SQA lead, head of quality | Plans approved |
| RA-02 | Requirements review | Technical review | End of requirements phase | Analysts, architects, test lead, SQA | No open major findings |
| RA-03 | Design review | Technical review | Before construction of each increment | Architects, leads, SQA | ADRs approved |
| RA-04 | Process audit: code review and CI gates | Audit | Monthly | SQA engineer, tech lead | Findings logged |
| RA-05 | Test readiness review | Technical review | Before system test | Test manager, PM, SQA | Entry criteria met |
| RA-06 | Functional and physical configuration audit | Audit | Before release | CM, SQA, test manager | Baseline verified |
| RA-07 | Supplier audit | Audit | Month 3 and month 8 | Supplier, SQA lead | Findings agreed |

```mermaid
gantt
  title SQA reviews and audits
  dateFormat YYYY-MM-DD
  section Reviews
  Plan review            :milestone, r1, 2026-01-12, 0d
  Requirements review    :milestone, r2, 2026-02-20, 0d
  Design review          :milestone, r3, 2026-03-13, 0d
  Test readiness review  :milestone, r5, 2026-06-01, 0d
  section Audits
  Monthly process audits :a1, 2026-02-02, 150d
  Supplier audit 1       :milestone, a2, 2026-04-01, 0d
  Configuration audit    :milestone, a3, 2026-06-26, 0d
```

## 8. Problem reporting and corrective action

<!-- Guidance: Define how product problems (defects) and process problems (non-conformances) are reported, tracked and closed, and how SQA verifies the fix. -->

### 8.1 Problem types

| Type | Example | Tracked in | Owner |
|---|---|---|---|
| Product defect | Function fails a test | Issue tracker, project `[KEY]` | Development |
| Document finding | Requirement not testable | Review record | Document author |
| Process non-conformance | Merge without review | SQA finding log | Process owner |
| Supplier non-conformance | Deliverable missing test evidence | Supplier finding log | Supplier manager |

### 8.2 Finding severity

| Severity | Meaning | Response time |
|---|---|---|
| Major | Requirement, contract or standard clearly not met; risk to product or customer | Corrective action plan within 5 working days |
| Minor | Isolated lapse with limited effect | Corrective action within 20 working days |
| Observation | Improvement opportunity | Considered at next retrospective |

### 8.3 Corrective action process

Every major or minor finding follows the loop below. SQA closes a finding
only after checking that the action removed the cause, not just the symptom.

```mermaid
flowchart LR
  A["Finding raised"] --> B["Root cause analysis"]
  B --> C["Corrective action planned"]
  C --> D["Action implemented"]
  D --> E{"SQA verifies effectiveness"}
  E -- "effective" --> F["Finding closed"]
  E -- "not effective" --> B
```

### 8.4 Waivers

A non-conformance that will not be corrected requires a waiver with the
reason, the risk, the compensating measure and approval by [the head of
quality and the product owner]. Waivers are listed in the release
quality statement.

## 9. Tools, techniques and methods

<!-- Guidance: Name the tools and methods SQA uses and any that need qualification (tools whose output is trusted without manual checking). -->

| Purpose | Tool or method | Qualification needed? |
|---|---|---|
| Finding and action tracking | [Issue tracker, SQA project] | No |
| Static analysis | [Tool] with ruleset [name] | Yes, ruleset reviewed annually |
| Code coverage | [Tool] | No |
| Document review | Checklist-based review, [review tool] | No |
| Audit | Sampling with audit checklist; interviews | No |
| Root cause analysis | Five whys, cause-and-effect diagram | No |

## 10. Supplier and subcontractor control

<!-- Guidance: Any software or service built or supplied by another party needs quality requirements in the contract and evidence that they are met. -->

| Supplier | Product or service | Quality requirements flowed down | Evidence required | Assurance method |
|---|---|---|---|---|
| *Example:* [Supplier A] | Mobile client development | Coding standard, test strategy, security standard | Test reports, static analysis reports, review records each sprint | Supplier audit twice per contract; sampling of deliveries |
| *Example:* [Open-source component] | Libraries | Dependency policy | SBOM, vulnerability scan | Automated scan in CI |
| [Supplier] | [Product] | [Requirements] | [Evidence] | [Method] |

Acceptance of supplier deliveries requires: delivery checklist complete,
evidence received, and no open major findings.

## 11. Risk management

<!-- Guidance: Record risks to quality and to SQA itself, with mitigation. Link to the project risk register rather than duplicate it. -->

| ID | Risk | L (1-5) | I (1-5) | Mitigation | Owner |
|---|---|---|---|---|---|
| QR-01 | *Example:* Schedule pressure leads to skipped reviews | 4 | 4 | Reviews are CI-enforced merge checks; SQA monthly sampling | [@pm] |
| QR-02 | *Example:* Single SQA engineer for two teams | 3 | 3 | Prioritise high-risk components; borrow from quality pool during release | [@head-of-quality] |
| QR-03 | *Example:* Supplier does not share test evidence | 2 | 4 | Contract clause with payment milestone tied to evidence | [@procurement] |
| [QR-nn] | [Risk] | [L] | [I] | [Mitigation] | [@name] |

## 12. Records collection, maintenance and retention

<!-- Guidance: List the records that prove SQA was done. Auditors ask for these first. -->

| Record | Format and location | Owner | Retention |
|---|---|---|---|
| Review records and checklists | [Wiki / document system path] | Review moderator | [Project life + 3 years] |
| Audit reports | [Path] | SQA lead | [Project life + 3 years] |
| Finding and corrective action log | [Issue tracker project] | SQA lead | [Project life + 3 years] |
| Waivers | [Path] | Head of quality | [Project life + 3 years] |
| Release quality statements | [Path] | SQA lead | [Product life] |
| Supplier audit reports | [Path] | SQA lead | [Contract term + 3 years] |

Records are protected from unauthorised change by [access control and
version history] and backed up [daily].

## 13. Training

<!-- Guidance: List the skills SQA staff and project staff need for this plan and how they will get them. -->

| Audience | Training | Method | By when |
|---|---|---|---|
| SQA staff | Project domain and architecture overview | Briefing by architect | Week 2 |
| SQA staff | Internal auditor skills | Course | Before first audit |
| Developers | Coding and security standard | Workshop, 2 hours | Week 3 |
| Reviewers | Review checklist use | Walkthrough | Before requirements review |
| [Audience] | [Training] | [Method] | YYYY-MM-DD |

## 14. Metrics

<!-- Guidance: Choose a small set of measures that show whether SQA and the quality objectives are on track. State who reviews them and the threshold that triggers action. -->

| Metric | Definition | Target | Action threshold | Reviewed by |
|---|---|---|---|---|
| Review effectiveness | Major findings found in review / major defects found later in the same product | >= 2.0 | < 1.0 | SQA lead |
| Finding closure time | Median days from finding raised to verified closure | <= 15 | > 30 | Head of quality |
| Overdue corrective actions | Count of actions past due date | 0 | > 3 | Project manager |
| Process conformance | Sampled items conformant / sampled items | >= 95% | < 90% | SQA lead |
| Escaped defect rate | Severity-1 and severity-2 defects found in production per release | 0 | > 1 | Quality board |

Review effectiveness is calculated as

$$RE = \frac{F_{\text{review}}}{F_{\text{later}} + 1}$$

where $F_{\text{review}}$ is major findings found in reviews and $F_{\text{later}}$ is major defects in the same product found in test or operation; adding one avoids division by zero.

## 15. Glossary and references

<!-- Guidance: Define terms used in this plan and list referenced documents with versions. -->

| Term | Meaning in this plan |
|---|---|
| Product assurance | Activities that check work products conform to requirements and standards |
| Process assurance | Activities that check the project follows its defined processes |
| Finding | A documented result of a review or audit: non-conformance or observation |
| Waiver | Approved, recorded decision to accept a non-conformance |

References: [Project management plan], [SCM plan], [V&V plan], [Test
strategy], [Organisation QMS procedures], IEEE 730-2014, *IEEE Standard
for Software Quality Assurance Processes*.

## Standard and licence note

Structure aligned with IEEE 730-2014, *IEEE Standard for Software Quality
Assurance Processes*, SQA plan content. This template is original text
written for this collection and reproduces no text from the standard;
obtain the standard from IEEE for its normative requirements. Template
licence: MIT.