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

Lesson 2 of 6

What SAP tests and what you test

9 min

Listen to this lesson

0:00 / 5:10

SAP runs a software-as-a-service product, so it tests its own software heavily before each release. That does not move your testing to SAP. SAP's learning material is explicit that partners and customers perform regression testing in the test system before content moves to production. The useful question is not "who tests?" but "which risks does SAP's testing cover, and which remain mine?"

Post-upgrade tests: SAP runs standard automates for you

The embedded Test Automation Tool ships with standard test automates aligned to the manual test scripts in SAP Signavio Process Navigator. On top of that, SAP offers post-upgrade tests: after each release upgrade, and only with the customer's consent, SAP runs standard test automates in the customer's system. They cover standard, unchanged processes. They use data the tool retrieves from the system or from a test data container.

  1. Give consent in the Test Your Processes app: open the Post-Upgrade Tests tab and select the badge icon to reach the consent screen.
  2. Adjust the scope and assign data variants in the Manage Upgrade Tests app. A test execution variant must be maintained there for the tests to run.
  3. After the upgrade, trigger the tests (the play icon) and review the results in the Analyze Automated Test Results app, with logs and screenshots for failed steps.
Post-upgrade tests only run after consent, scope and an execution variant are in place, and their results land in Analyze Automated Test Results.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-305
SAP: product qualitySAP's own development and release testing of the standard software
SAP with your consent: post-upgrade testsStandard automates run in your system on standard, unchanged processes
You: configurationYour scope items, organizational data, output, workflow and roles
You: extensionsCustom fields, logic, apps and developer extensions
You: integrations and acceptanceInterfaces, connected systems, business sign-off
Shared responsibility for upgrade quality. The lower three layers are always yours.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-305

Why post-upgrade tests are not your regression

Post-upgrade tests are a fast signal that standard processes still run. They cannot know about the field your key user made mandatory, the approval step you added, or the outbound interface to your logistics provider. SAP Learning lists the reasons a post-upgrade test may not run at all: an inactive business process, a failure in the data-picking logic, a failed execution pre-check, custom logic or custom fields not maintained in the automate, a missing execution variant, or a default test user without the required roles. Any of those leaves a gap you must close with your own tests.

A post-upgrade test that did not run, or that only covered the standard flow, leaves a gap Contoso has to close with its own tests.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-305
  1. Is the process a standard scope item you have not changed?Yes → candidate for post-upgrade tests, plus your own smoke check · No → it needs your own automate or manual test
  2. Did you add fields, logic or steps to it?Yes → copy the standard automate, adapt it and own it · No → standard automate may be enough
  3. Does it cross an interface or another system?Yes → add an integration test with the partner system · No → continue
  4. Is it critical for close, cash or compliance?Yes → add key-user acceptance and evidence for sign-off · No → automated evidence is enough
Deciding, process by process, what SAP's testing covers and what you add.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-305

What else the upgrade can change

  • New or changed apps and fields that alter screens your automates and testers use.
  • Features enabled at the major release that you did not activate earlier but are relevant to your active scope.
  • Business roles and catalogs, which may need new apps assigned; RASD helps here.
  • Key user extensions: SAP notes that importing extensions from a previous release into an upgraded system may not be possible, so time your extension transports with care.

What would you do?

In the what-if, Dan says: "SAP runs post-upgrade tests, so finance doesn't need to test the August release." Contoso has customized the supplier invoice approval and added a custom field to journal entries. What should Priya reply?

Key points
  • SAP tests its product; customers test their configuration, extensions, integrations and business acceptance.
  • Post-upgrade tests run standard automates on standard, unchanged processes, only with consent.
  • Consent is given in Test Your Processes; scope and data variants are managed in Manage Upgrade Tests.
  • Check which post-upgrade tests ran and why others did not; close every gap with your own tests.

Check your understanding · not graded

Lesson check

  1. 1. Which processes do SAP's post-upgrade tests cover?

  2. 2. Where does a customer give consent for post-upgrade tests?

  3. 3. Which is a documented reason a post-upgrade test may not run?