Lesson 1 of 6
Why a permanent capability
13 min
Most SAP test teams are built for a project and dissolved at go-live. The integrator rolls off, the business testers return to their jobs, the test cases sit in a tool nobody owns, and the automated scripts start breaking with the first change. Six months later a support package or a release upgrade arrives and the company rebuilds a test team from scratch, at short notice and high cost. A test center of excellence (TCoE) is the alternative: a permanent capability that owns how SAP change is tested, every time.
Change never stops after go-live
SAP systems change constantly after go-live, and much of that change is on a schedule you do not fully control:
| Source of change | Typical cadence | Testing implication |
|---|---|---|
| SAP S/4HANA Private Edition / on-premise releases | New base release every two years; feature pack stacks between; support pack stacks for older releases | Planned upgrade projects with full regression |
| SAP S/4HANA Cloud Public Edition | Two major releases a year plus regular hotfix and feature deliveries | Fixed, short regression windows on every upgrade |
| Support packages and SAP Notes | As needed, often for legal or security reasons | Targeted regression on affected processes |
| Internal enhancements and fixes | Continuous, through the change process | Functional tests plus regression of neighbors |
| Integrations and connected cloud apps | Each partner's own cadence | Interface regression when either side changes |
| Organizational change | New plants, company codes, acquisitions | Roll-out testing and regression of shared processes |
Sources of change for Contoso Motor Co. after go-live. Check SAP's published schedules for exact dates.
SAP's learning material on Private Edition notes that SAP S/4HANA moved to a two-year release cycle with seven years of mainstream maintenance and that, under RISE, SAP performs the technical upgrade while planning, preparation and testing remain the customer's responsibility. In Public Edition, SAP upgrades the test system first and then production on a published schedule, which gives customers a fixed window to run regression. Either way, testing is the customer's job, and it recurs.
| Private Edition / on-premise | Public Edition | |
|---|---|---|
| Release rhythm | New base release every two years, feature pack stacks between | Two major releases a year plus regular hotfix and feature deliveries |
| Who runs the technical upgrade | SAP under RISE; customer or partner otherwise | SAP |
| When you test | In a planned upgrade project you schedule | In a fixed window after SAP upgrades the test system and before production |
| Who tests | The customer | The customer |
| Dimension | Project test team | Test center of excellence |
|---|---|---|
| Lifespan | Ends at go-live | Permanent |
| Assets | Built for one project, often abandoned | Maintained regression packs, data recipes, standards |
| People | Mostly external, rolled off | Core internal team plus flexible partner capacity |
| Cost model | Project budget spikes | Predictable run budget plus demand-driven work |
| Knowledge | Leaves with the integrator | Retained and improved |
| Upgrade readiness | Rebuilt each time | Ready on the calendar |
Signs you need one
- Every upgrade or support package starts with "who can test this?"
- Test cases from the implementation are out of date and nobody owns them.
- Key users are pulled into testing at short notice, during close or peak season.
- Production incidents follow releases that were "tested."
- Audit asks for evidence of change testing and it takes weeks to assemble.
- Automated scripts built during the project no longer run, and nobody has time to fix them.
Two or three of these together usually mean the company is paying for testing several times over, in rework, incidents and emergency staffing, without building anything that lasts.
- Change arrivesA support pack, legal change or new plant for Contoso
- "Who can test this?"No standing team; key users pulled in at short notice
- Assets rebuiltOld test cases out of date, scripts broken, data recipes lost
- Rushed regressionThin coverage and weak evidence for audit
- Incidents and reworkDefects reach production, then the team disbands and the cycle repeats
What a TCoE is not
- Not a tool purchase. Tools support the capability; they do not create it. The TCoE should stay tool-neutral in its standards so it can use SAP's tools (such as SAP Cloud ALM and, for Public Edition, the Test Automation Tool) alongside others without being locked into any one.
- Not a gatekeeper that slows everything down. A good TCoE makes change faster by making regression cheap and predictable.
- Not only automation. Strategy, data, environments and business acceptance matter as much as scripts.
- Not a replacement for business ownership. Process owners still accept change; the TCoE gives them the evidence.
What would you do?
Contoso's CFO asks why the company should fund a permanent test team "now that the project is over." What is Grace's strongest answer?
- SAP systems change continuously after go-live, much of it on SAP's schedule.
- Testing of upgrades remains the customer's responsibility even when SAP runs the technical upgrade.
- A TCoE is a permanent capability that keeps regression assets, data, standards and people ready.
- It is not a tool, a gatekeeper or only automation, and it does not replace business ownership.
Check your understanding · not graded
Lesson check
1. What is the main reason to make SAP testing a permanent capability?
2. For Private Edition under RISE, who performs the technical upgrade and who tests?
3. Which statement best describes a TCoE?
4. Why should TCoE standards stay tool-neutral?