Lesson 1 of 6
The test policy
10 min
Listen to this lesson
The charter (sap-tcoe-401) says what the TCoE may do. The playbook says how testing is done at Contoso, by anyone, on any SAP change. Its top document is the test policy: a short, stable statement of why the company tests, what good testing means there and who is responsible. Everything else in the playbook (practices, templates, evidence and defect rules, quality gates) applies the policy to a situation.
Where the policy sits
ISO/IEC/IEEE 29119-2:2021 describes testing as three layers of process. The organizational test process develops, monitors and updates organization-wide test specifications. The test management processes plan, monitor and complete testing for a project or release. The dynamic test processes design, prepare and execute tests. The organizational layer produces two documents that 29119-3:2021 names: the test policy and the organizational test practices. The 2013 edition called the second one the "organizational test strategy," and you will still see that term in older material and in CTAL-TM v3.0, which notes the change.
| Document | Scope | Changes | Contoso owner |
|---|---|---|---|
| Test policy | The whole company: why and what, in principle | Rarely; reviewed yearly | CIO approves; Priya maintains |
| Organizational test practices | All SAP testing: how, in standard terms | Once or twice a year | Priya, approved by the quality council |
| Test strategy | One project or release stream | Per project | Project test lead using the TCoE template |
| Test plan | One release, cycle or test level | Per release or cycle | Test architect or project test lead |
What a test policy contains
A test policy is an executive document. ISO/IEC/IEEE 29119-1:2013 described it as one that sets out the purpose, goals and overall scope of testing in an organization, and that is still the right test: if a clause would change from project to project, it belongs in the practices or a strategy, not in the policy. Contoso's policy fits on one page:
| Clause | Contoso wording (abridged) |
|---|---|
| Purpose | Testing gives the business the evidence it needs to accept change to its SAP systems and protects customers, finances and compliance from the consequences of defects. |
| Scope | All change to SAP S/4HANA, SAP BTP extensions and their interfaces, including SAP release events, notes, enhancements, projects and emergency fixes. |
| Principles | Risk decides depth; business process owners accept change; evidence is stored in SAP Cloud ALM; no change reaches production without a recorded test decision; testing is independent of the people who built the change where risk requires it. |
| Responsibilities | The TCoE sets standards and provides readiness assessments; project and release teams apply them; process owners accept; developers own unit tests and ATC results. |
| Measures | Escaped defects by release and severity, defect detection percentage, regression cycle time, audit evidence lead time. |
| Improvement | The TCoE reviews conformance and results quarterly and proposes changes to the quality council. |
| Approval | Approved by the CIO; reviewed annually. |
Contoso's one-page test policy. Notice what is missing: no tools, no templates, no entry criteria. Those change more often and belong lower down.
The sentence that does the most work is "no change reaches production without a recorded test decision." It does not say every change is tested in full. A recorded decision can be "no test needed: configuration of a report layout, risk low, approved by the process owner." That makes the policy realistic for emergency fixes and tiny changes, while still giving auditors a record for every transport.
Making the policy real
- Approve it at the top. The CIO signs; the quality council endorses. A policy signed only by the TCoE is a team preference.
- Connect it to existing controls. Contoso's change management procedure now cites the policy, so the test decision is a field on every change record.
- Brief partners. System integrator and AMS contracts reference the policy, so their test work is measured against it.
- Keep it short. If it grows beyond two pages, move detail into the practices.
Review the policy on a schedule and on triggers. The schedule is yearly, at the quality council that also reviews the charter. The triggers are events that change what "good testing" must mean: a new deployment model (such as a Public Edition subsidiary), a new regulator or audit finding, a major acquisition such as Wave 2, or a change in who owns acceptance. Between reviews, resist editing the policy to fix a local problem; that is what the practices and templates are for.
What would you do?
At the policy review, Luis asks to add "all regression must be automated and run in CMR within five working days" to the test policy, so that nobody can argue with it. What should Priya recommend?
- ISO/IEC/IEEE 29119-2 has three process layers: organizational, test management and dynamic.
- The organizational layer produces the test policy and the organizational test practices (formerly the organizational test strategy).
- A policy states purpose, scope, principles, responsibilities, measures and improvement on about one page.
- Anything that changes per project belongs in practices, strategies or plans, not in the policy.
- "No change reaches production without a recorded test decision" makes the policy realistic and auditable.
Check your understanding · not graded
Lesson check
1. What does ISO/IEC/IEEE 29119-3:2021 call the document the 2013 edition called the "organizational test strategy"?
2. Which clause belongs in the test policy rather than in a project strategy?
3. Why does "no change reaches production without a recorded test decision" work better than "every change is fully tested"?
4. Who should approve Contoso's test policy?