Lesson 2 of 6
Templates that get used
9 min
Listen to this lesson
Most TCoE standards fail the same way: someone writes a thorough forty-page document, publishes it on a wiki, and projects ignore it. Standards are followed when they are short, prefilled and built into the tools teams already use. This lesson builds Contoso's template set and the tailoring rules that say which template a change needs.
Four change classes, four templates
| Change class | Examples at Contoso | Template | Length |
|---|---|---|---|
| Project | Wave 2 roll-out of company code 1910; a new warehouse process | Project test strategy | 8–12 pages |
| Release event | Feature pack stack update; quarterly enhancement release | Release test plan | 3–5 pages |
| Enhancement | A new pricing condition; a changed output form | Enhancement test plan (in the change record) | One screen |
| Emergency fix | Billing documents blocked in CMP; a legal-change note due tomorrow | Emergency test record | Half a page, completed after the fact |
Contoso's template set by change class. Length is a ceiling, not a target.
- Is it a project with its own budget and SAP Activate phases?Yes → project test strategy · No → next question
- Is it an SAP release event or a planned release bundle?Yes → release test plan · No → next question
- Is production down or a legal deadline imminent?Yes → emergency test record, retrospective within 5 days · No → enhancement test plan
What the project test strategy template covers
The project test strategy follows the organizational practices and is written in SAP Activate Explore, when fit-to-standard has shaped the backlog. Its sections answer the questions a steering group asks: what are the product risks, which test levels and types apply (unit, string, integration, data migration, regression, user acceptance, and any non-functional testing), who does each, which environments and data, what the entry and exit criteria are, how defects are handled, and what evidence goes to the go/no-go. sap-tst-301 teaches how to write one; the TCoE template prefills everything that is standard at Contoso so the project writes only what is specific.
- Prefilled: severity definitions, defect workflow, evidence standard, Cloud ALM conventions, standard gate criteria, the environment landscape (CMD, CMQ, CMP and client 100 for testing).
- Project writes: scope and risks, test levels in scope, schedule, data sources, roles by name, deviations from standards with reasons.
- Always included: the regression impact on shared processes and the plan to hand new tests into the regression pack before project close.
The release test plan
A release test plan is shorter because the TCoE runs it every time. It records the release content (SAP release information, notes, transports), the release assessment result, the regression scope with reasons, the data refresh and environment readiness dates, key users booked, the schedule against the release calendar, and the exit criteria for the readiness assessment. Contoso keeps the plan and its test plans in SAP Cloud ALM, so the document and the execution data stay together.
The emergency test record
Emergency fixes are where standards break first, and where auditors look first. Contoso's emergency record is half a page: what was changed, which test was run before import (even if only a targeted check in CMQ), who approved the import, and what regression follows within five working days. The retrospective is mandatory; it asks whether the emergency could have been prevented and whether the regression pack needs a new test. This matches Contoso's emergency change procedure: emergency changes are built in CMD and transported with an emergency approver and a retrospective.
Design rules for templates
| Rule | Why |
|---|---|
| Prefill every standard answer | Teams write only what is specific; reviews focus on risk |
| Show a worked example beside each section | People copy examples, not instructions |
| Mark mandatory and optional sections | Tailoring becomes a decision, not an omission |
| Store templates where the work happens | SAP Cloud ALM documents and the change record, not a wiki |
| Version every template and log changes | Teams know which version applies; audits can see what was in force |
| Give each template an owner | Someone fixes it when teams complain |
What would you do?
A year after launch, Priya finds that the Wave 2 project wrote a 30-page strategy that copies the organizational practices word for word, and two enhancement teams skipped test plans altogether. What should she change?
- Classify every change (project, release event, enhancement, emergency) and give each class a template.
- Prefill standard answers so teams write only what is specific; mark mandatory and optional sections.
- Store templates where the work happens: SAP Cloud ALM and the change record, not a wiki.
- Emergency fixes get a half-page record and a mandatory retrospective with regression within five days.
Check your understanding · not graded
Lesson check
1. Which template should a feature pack stack update use at Contoso?
2. What makes a template "get used"?
3. What must happen after an emergency fix at Contoso?
4. Which section is always included in Contoso's project test strategy template?