Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 5 of 5

Ongoing regression in Run

8 min

Go-live is not the last time the system changes. Fixes from hypercare, new requirements, SAP corrections, feature pack stacks and the next base release all change production. Each change needs evidence that what worked before still works. That evidence comes from regression testing, and setting it up is part of the transition to Run, not an afterthought.

Where regression comes from

  1. UAT and SIT casesProven end-to-end test cases from the project
  2. Select the coreProcesses that are critical, frequently used or often affected by change
  3. Add hypercare lessonsEach incident caused by a testing gap becomes a new test case
  4. MaintainUpdate cases when processes or configuration change
  5. Run per releaseBefore each transport release, feature pack or upgrade
Building the regression suite from project assets and hypercare lessons.
The Sign-Off Table · thesignofftable.com/academy/sap-pmo-302

The project's SIT and UAT cases are the starting point, but not all of them belong in a regression suite. Choose the processes that are business critical, used every day, or most exposed to change, such as order-to-cash for Great Lakes Fleet Services, procure-to-pay with Lakeside Components, production of CMC-ALT-100, intercompany sales between company codes 1710 and 1810, and the period-end close. In SAP Cloud ALM, keeping those test cases assigned to the solution processes makes it easy to select the right ones when a change touches a process.

Close the loop with hypercare

Every hypercare incident caused by a gap in testing is a free lesson. When Contoso's billing block for fleet customers turned out to be a pricing scenario nobody had tested, Priya added a test case for it, linked it to the same solution process, and put it in the regression suite for the next release. Over the first months, these additions make the suite reflect how the business really uses the system.

The release rhythm

For SAP S/4HANA Cloud Private Edition and on-premise, SAP ships a new base release every two years, with feature pack stacks in between, plus corrections through SAP notes and support packages. Contoso's own changes add to that. Group them into a release calendar, so the business runs one regression cycle per release rather than a test for every transport. Public Edition customers receive SAP's updates on SAP's schedule, which makes a ready regression suite even more important.

  1. MonthlyContoso minor releaseFixes and small changes; risk-based regression of affected processes
  2. As neededSAP notes and correctionsTargeted tests of the corrected function and its neighbours
  3. PeriodicallyFeature pack stack updateFull core regression; new features tested if adopted
  4. About every two yearsNew base release upgradeProject-scale testing, with the regression suite as the backbone
A post-go-live release calendar for Contoso and the regression each event needs.
The Sign-Off Table · thesignofftable.com/academy/sap-pmo-302

Scope regression by risk

Core regressionHigh criticality, low impact: run the core end-to-end cases every release
Full regression and business checkHigh criticality, high impact: full end-to-end cases plus key-user confirmation
Smoke testLow criticality, low impact: a quick check that the process still runs
Targeted regressionLow criticality, high impact: test the changed process and its direct neighbours
Scoping regression for a release by criticality and change impact.
The Sign-Off Table · thesignofftable.com/academy/sap-pmo-302

Automating the stable core of the suite pays off quickly once releases come every month, but only if the cases are maintained and owned. SAP's own tools can help: in Public Edition, the Test Automation Tool provides automated test processes; in Private Edition and on-premise, programs use SAP Cloud ALM test management with manual or automated cases. Whatever the tool, an automated test nobody maintains is worse than none, because it reports green on a process it no longer tests.

Environments and data for regression

A regression suite is only as good as the system it runs in. Keep the quality system close to production: the same transports, the same configuration and representative data, refreshed on a schedule agreed with the Basis or SAP operations team. Plan the test data each core case needs, such as an active fleet customer, a supplier with open purchase orders, stock of CMC-ALT-100 in plants 1710 and 1720, and protect personal data in any copy of production according to your privacy rules. Many failed regression runs are caused by stale data or missing transports, not by real defects; each one costs time and erodes trust in the suite.

What would you do?

Three months after go-live, Contoso's application team proposes to stop regression testing for monthly releases because "nothing has broken since hypercare". What should Priya argue?

Key points
  • Build the regression suite from proven SIT and UAT cases, focused on critical and change-exposed processes.
  • Turn every hypercare incident caused by a testing gap into a regression case.
  • Plan regression against a release calendar: minor releases, SAP corrections, feature packs and upgrades.
  • Scope each release by criticality and change impact; keep automated cases maintained and owned.

Check your understanding · not graded

Lesson check

  1. 1. What should happen to a hypercare incident caused by a gap in testing?

  2. 2. How often does SAP ship a new base release for SAP S/4HANA Private Edition and on-premise?

  3. 3. Why group changes into a release calendar?

  4. 4. Why is an unmaintained automated test dangerous?