# Organizational Test Policy: [Organisation or business unit]

> Organisation-wide test policy: a short, stable document, approved by
> senior management, that says why the organisation tests, what it
> expects testing to achieve, and the principles every project follows.
> It sits above the organisational test practices (test strategy) and
> the project test plans. The structure follows the test policy
> information item of ISO/IEC/IEEE 29119-3:2021 (clause 6.2). Replace
> every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Keep it short: two to four pages once filled. A policy states
  objectives and principles; techniques, tools, levels and criteria go in
  the test strategy (`quality/test-strategy`), and dates and people go in
  the test plan (`quality/test-plan-29119`).
- Write every statement so a project can show it complied. "Testing is
  important" cannot be audited; "every release has an approved test
  completion report" can.
- Get a senior sponsor to approve it. A policy signed only by the test
  team carries no weight when a deadline presses.
- Review it yearly or when the organisation's risk profile changes (new
  regulation, new product line, an incident that testing should have
  caught).
- The worked example describes Quillfern Systems, a fictional software
  vendor of about 300 people.
-->

## Document control

<!-- Guidance: The policy changes rarely, so the approval and next review date matter more than the version number. -->

| Field | Value |
|---|---|
| Document ID | [POL-TEST-001] |
| Applies to | [All software products and internal systems of Quillfern Systems] *(Example)* |
| Version | [1.0] |
| Status | [Draft / Approved / Superseded] |
| Owner | [@head-of-quality] |
| Approved by | [Chief technology officer] |
| Effective from | YYYY-MM-DD |
| Next review | YYYY-MM-DD |
| Classification | [Internal] |
| Last updated | YYYY-MM-DD |
| Related documents | [Quality policy], [Information security policy], [Organisational test practices TS-ORG-001] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Policy owner | [@name] | [Proposed] | YYYY-MM-DD |
| Executive sponsor | [@name] | [Approved] | YYYY-MM-DD |
| Engineering leadership | [@name] | [Endorsed] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Draft for consultation |
| 1.0 | YYYY-MM-DD | [@name] | Approved |

## 1. Purpose and scope

<!-- Guidance: Say what the policy is for and what it covers: products, internal systems, suppliers, AI components. Name what is out of scope and why. -->

This policy sets the objectives and principles of testing for
[organisation]. It applies to [all software the organisation builds,
buys and configures for customers or for its own operations], including
work done by suppliers on its behalf.

*Example:* Out of scope: hardware certification testing, which follows
the separate product compliance procedure.

## 2. Objectives of testing

<!-- Guidance: 29119-3 clause 6.2.2. State what testing is for in this organisation, linked to business goals. Three to six objectives, each measurable in section 9. -->

| ID | Objective | Linked business goal |
|---|---|---|
| OBJ-01 *(Example)* | Give decision makers timely, accurate information on product quality and residual risk before every release | Predictable releases |
| OBJ-02 *(Example)* | Find defects as early as possible, when they are cheapest to fix | Lower cost of quality |
| OBJ-03 *(Example)* | Confirm that products meet accessibility, security and privacy obligations | Market access and trust |
| OBJ-04 *(Example)* | Prevent defects from recurring by feeding causes back into development | Fewer production incidents |
| [OBJ-nn] | [Objective] | [Goal] |

## 3. Test process

<!-- Guidance: 29119-3 clause 6.2.3. Name the test process framework the organisation uses and the few rules everybody follows. Do not describe the process in detail here; point to it. -->

- Testing follows the organisation's test process, documented in
  [organisational test practices, TS-ORG-001], based on the processes of
  ISO/IEC/IEEE 29119-2:2021 and tailored per project.
- Every project of [size or risk threshold] has a test plan approved
  before test execution starts and a test completion report before
  release.
- Testing is risk-based: the depth of testing follows product risk, and
  the residual risk is stated and accepted by the product owner.
- *Example:* Teams using continuous delivery meet these rules through
  pipeline gates and an automatically generated completion summary,
  approved per release train.

## 4. Test organisation structure

<!-- Guidance: 29119-3 clause 6.2.4. Who is responsible for testing, and how independent testers are from developers for each kind of product. -->

| Role | Responsibility | Independence |
|---|---|---|
| Head of quality *(Example)* | Owns this policy and the test practices; reports test performance to leadership | Reports outside product lines |
| Test lead per product *(Example)* | Plans and reports testing; owns the test plan and completion report | Part of the product team |
| Developers *(Example)* | Unit and integration tests for every change | None |
| Independent assessors *(Example)* | Accessibility conformance and penetration testing for high-risk releases | External or separate team |
| [Role] | [Responsibility] | [Independence] |

## 5. Tester training and competence

<!-- Guidance: 29119-3 clause 6.2.5. The competence the organisation expects and how it provides it. Certifications are optional evidence, not the goal. -->

- Every tester and developer completes [induction training on the test
  process and defect reporting] within [one month] of joining.
- Test leads hold or obtain [a recognised testing qualification or
  equivalent experience] within [12 months].
- Specialist skills (accessibility, security, performance) are kept by
  [named roles], with [n] days of training per year.

## 6. Tester ethics

<!-- Guidance: 29119-3 clause 6.2.6. The behaviour expected of everyone who tests: honesty in reporting, confidentiality of data, freedom to raise bad news. -->

- Report results truthfully, including results that delay a release.
- Nobody may be pressured to change a verdict or a defect severity
  without evidence; disputes go to [the head of quality].
- Use production personal data in testing only with approval under
  [data protection policy], and prefer synthetic or masked data.
- Protect confidential information found during testing, and report
  security vulnerabilities only through [the vulnerability process].

## 7. Standards

<!-- Guidance: 29119-3 clause 6.2.7. The external and internal standards that testing follows. Cite the edition so audits can check the version. -->

| Standard | Use in this organisation |
|---|---|
| ISO/IEC/IEEE 29119-2:2021 and 29119-3:2021 *(Example)* | Test process and documentation model, tailored |
| WCAG 2.2 level AA and EN 301 549 *(Example)* | Accessibility test basis for customer-facing products |
| [Internal coding and security standards] | Review and test basis |
| [Sector standard] | [Use] |

## 8. Other relevant policies

<!-- Guidance: 29119-3 clause 6.2.8. Policies that testing must respect or that depend on testing. -->

- [Quality policy] and [quality management system manual]
- [Information security policy] and [vulnerability disclosure policy]
- [Data protection policy] for test data
- [Change management policy] (`ops/change-enablement-policy`) for release approval
- [AI use policy] for AI-assisted test design and AI components under test

## 9. Measuring the value of testing

<!-- Guidance: 29119-3 clause 6.2.9. How the organisation will know testing meets the objectives in section 2. Choose few measures, define them and report them to leadership. -->

| Measure | Definition | Objective | Target *(Example)* |
|---|---|---|---|
| Defect detection percentage | Defects found before release / (before release + found in production within 90 days) | OBJ-02 | >= 90% |
| Escaped severe defects | S1 and S2 defects found in production per quarter | OBJ-01, OBJ-04 | Falling trend |
| Releases with an approved completion report | Count / all releases | OBJ-01 | 100% |
| Accessibility conformance | Products with a current conformance report | OBJ-03 | All customer-facing products |
| [Measure] | [Definition] | [Objective] | [Target] |

## 10. Test asset archiving and reuse

<!-- Guidance: 29119-3 clause 6.2.10. What is kept, where, for how long, and how teams reuse it. Retention must match legal and contractual needs. -->

- Test plans, completion reports and conformance reports are kept for
  [the life of the product plus two years] in [repository].
- Automated tests live with the code and follow the code's retention.
- Reusable assets (test data generators, environment definitions,
  checklists) are published in [shared library] with an owner.
- Test data containing personal data is deleted at the end of the test
  cycle unless a documented exception applies.

## 11. Test process improvement

<!-- Guidance: 29119-3 clause 6.2.11. How the organisation learns: retrospectives, assessments, root cause analysis of escaped defects, and who decides on changes. -->

- Each project records lessons in its completion report; the head of
  quality reviews them [quarterly] and updates the test practices.
- Every escaped S1 defect gets a root cause analysis that asks why
  testing did not find it (`dev/postmortem`).
- An assessment of the test process against [model or internal
  baseline] runs every [two years].

## 12. Compliance and exceptions

<!-- Guidance: Say how compliance is checked and how a project asks for an exception. An exception process keeps the policy honest. -->

| Item | Rule |
|---|---|
| Compliance check | [Internal audit or quality review of a sample of releases per year] |
| Exception request | [Written request to the head of quality stating the rule, the reason, the risk and the compensating measure] |
| Exception approval | [Head of quality, and the product owner for risk acceptance] |
| Exception register | [Link] |

## 13. References

<!-- Guidance: Link the documents below this policy so readers can find how it is applied. -->

- Organisational test practices: Test Strategy (`quality/test-strategy`)
- Project level: Test Plan (`quality/test-plan-29119`), Test Completion Report (`quality/test-completion-report`)
- Quality planning: Software Quality Assurance Plan (`quality/sqa-plan`)
- ISO/IEC/IEEE 29119-3:2021, *Software and systems engineering: Software testing: Part 3: Test documentation*. Official text: ISO, IEC and IEEE, purchase or licensed access: https://www.iso.org/standard/79429.html
- ISO/IEC/IEEE 29119-2:2021, *Part 2: Test processes*. Official text: IEEE, purchase or licensed access: https://standards.ieee.org/ieee/29119-2/7498/

## Standard and licence note

Structure aligned with ISO/IEC/IEEE 29119-3:2021, *Software and systems
engineering: Software testing: Part 3: Test documentation*, test policy
information item (clause 6.2: objectives of testing, test process, test
organisation structure, tester training, tester ethics, standards, other
relevant policies, measuring the value of testing, test asset archiving
and reuse, test process improvement). The standard is copyrighted and is
cited by name, edition and clause number only; no text or example from
it is reproduced, and all wording here is original. Check the current
edition before claiming conformance. Official text: ISO, IEC and IEEE,
purchase or licensed access, at the links in section 13. Template
licence: MIT.