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

Lesson 6 of 6

Fit in the release cycle

9 min

Listen to this lesson

0:00 / 4:37

Everything in this course comes together in one recurring event: the release upgrade. SAP Learning describes the Public Edition rhythm: major releases twice a year, in February and August, with customers notified by email six weeks before an upgrade. SAP upgrades the test system first, partners and customers run regression there, and the development and production systems are upgraded three weeks later. That three-week window is when the Test Automation Tool earns its keep.

  1. Upgrade minus 6 weeksNotificationEmail from SAP. Confirm owners, test users, passwords and plans; review release information.
  2. Before test upgradeBaselineRun all plans green on the current release so failures afterwards mean something.
  3. Test system upgradedRegression startsSAP post-upgrade tests (if consented) and your custom plans run; triage begins.
  4. Window, about 3 weeksFix and rerunClassify failures, fix configuration and automates, raise incidents, rerun.
  5. Before production upgradeSign-offEvidence in Cloud ALM; open risks accepted by the process owners.
  6. Dev and production upgradedWatchMonitor production; feed lessons into the automates for the next cycle.
The Public Edition upgrade cycle and where automation runs.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-204

Who tests what

SAP's test strategy guidance for Public Edition splits the work cleanly. With customer consent, SAP runs post-upgrade tests for standard, unmodified processes after each upgrade. The customer is responsible for regression testing of its own configuration and customizations after go-live, using its own automates for customized processes. During implementation, partner configuration experts create or update automates as each process is configured, so that the customer inherits a working suite. Formal end-to-end, integration and data migration tests are documented in SAP Cloud ALM test management.

SAP tests its standard processes with consent; the customer owns regression of its own configuration and customizations.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-204
Rely on SAP post-upgrade testsStandard, low-criticality processes; review SAP results.
Custom automate, run each upgradeCustomized but low criticality; keep it lean.
Post-upgrade test plus targeted manual checkStandard but critical; add a key user check of outputs.
Custom automate plus key user acceptanceCustomized and critical, such as Contoso's order-to-cash; full evidence.
Deciding how each process is covered in the upgrade window.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-204

Linking to SAP Cloud ALM

SAP Cloud ALM is where the upgrade is managed as a whole. SAP describes its test management as orchestrating manual and automated test cases, with integrated test automation providers including the SAP S/4HANA Cloud Test Automation Tool, and with execution results of the tool's test plans visible in Cloud ALM next to manual test plans. In practice, Priya's upgrade test plan in Cloud ALM covers the manual checks (outputs, reports, anything the automates do not reach) and shows the automated results beside them, and defects from either source are tracked in one place.

Priya’s upgrade test plan in Cloud ALM brings manual checks, automated results and defects from both into one view.
The Sign-Off Table · thesignofftable.com/academy/sap-tau-204

Making the window work

  • Baseline before the upgrade: a suite that is already red cannot tell you what the upgrade broke.
  • Keep the suite lean: automate the processes that matter and change; a smaller suite that is always green beats a large one nobody trusts.
  • Owners for every custom automate: named people who update them when configuration changes, not only during the window.
  • Run book: test user passwords, data top-ups, plan start times and triage meetings, written down and rehearsed.
  • Decide fast: classify within a day; raise incidents early; do not let the window end with unanalyzed failures.

What would you do?

In the what-if, the August upgrade notification arrives. Priya discovers that a third of the custom automates have been red since a configuration change in May. What should she do in the six weeks before the test system upgrade?

Key points
  • Public Edition upgrades come twice a year; SAP notifies six weeks ahead and upgrades the test system three weeks before development and production.
  • SAP runs post-upgrade tests for standard processes with consent; customers own regression for their customizations.
  • Establish a green baseline before the test upgrade, then triage and rerun inside the window.
  • SAP Cloud ALM shows automated results next to manual plans and tracks defects for sign-off.
  • Lean suites, named owners and a rehearsed run book make the window work.

Check your understanding · not graded

Lesson check

  1. 1. How long after the test system upgrade are development and production upgraded, according to SAP Learning?

  2. 2. In which months do Public Edition major releases arrive?

  3. 3. Why establish a green baseline before the test system upgrade?

  4. 4. Who is responsible for regression testing of customized processes after go-live?