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

Lesson 5 of 5

Planning testing per edition

8 min

The previous lessons give you the inputs. This lesson turns them into a test plan: what to regression test, how often, who owns it, and what a process owner should expect to see before signing off an upgrade in each edition.

What SAP tests and what you test

SAP tests its standard software. It does not test your configuration, your data, your extensions, your integrations or your business roles. Those are the customer's responsibility in every edition, including Public Edition. Many first-time cloud customers assume otherwise and discover it in the first upgrade. The reason is simple: SAP cannot know that Contoso bills fleet customers with a custom contract ID field, that its revenue account determination uses a specific combination of settings, or that a warehouse system receives deliveries through an interface. Those combinations exist only in the customer system, so only the customer can prove they still work after a change. Public Edition reduces what can differ from standard; it does not reduce it to zero.

AreaPublic EditionPrivate EditionOn-premise
Standard software qualitySAPSAPSAP
Technical upgrade executionSAPSAP, per the RISE roles and responsibilities, timing agreed with customerCustomer or its partner
Business process regressionCustomer (key users, test lead)CustomerCustomer
Extensions and integrationsCustomerCustomerCustomer
Business roles and launchpad contentCustomerCustomerCustomer
Sign-off for production useCustomer process ownersCustomer process ownersCustomer process owners
Who owns what in an upgrade. Check your contract's roles and responsibilities for details.
The Sign-Off Table · thesignofftable.com/academy/sap-xpr-304

Sizing the regression set

Size the regression set by two factors from the earlier lessons: upgrade cadence (how often you must run it, and how long you have) and extension footprint (how much non-standard behavior can break). A Public Edition customer with few extensions needs a compact, fast, ideally automated core set run twice a year. A Private Edition customer with many classic extensions needs a broader set, run less often but with deeper coverage of the custom parts.

Lean and periodicFew extensions, infrequent upgrades: core business processes plus extension checks at each upgrade
Broad and periodicMany classic extensions, infrequent upgrades (typical Private Edition after ECC): wide regression plus deep extension tests
Lean and frequentFew extensions, twice-yearly upgrades (typical Public Edition): compact, automated core set
Broad and frequentMany extensions and frequent change: invest in automation and reduce the extension footprint
Regression strategy by upgrade frequency and extension footprint.
The Sign-Off Table · thesignofftable.com/academy/sap-xpr-304

Tools

SAP provides its own tooling. SAP Cloud ALM offers test management for planning, executing and tracking tests and defects in any edition. Public Edition customers can use the Test Automation Tool, with SAP-delivered standard test scripts that customers adapt to their own configuration. In Private Edition and on-premise, SAP Solution Manager (for those still using it) and eCATT are further options. Whatever the tool, the content of the regression set is a business decision. Key users decide which scenarios represent the business: the processes with the most volume, the most money, the most regulatory exposure and the most custom behavior. Automation then makes that set cheap to run often. Automating a poorly chosen set only produces fast, irrelevant results.

  1. Read release informationNew features, deprecations, simplification items for your scope
  2. Assess impactMap changes to your processes, roles, extensions and integrations
  3. Select testsCore regression set plus targeted tests for affected areas
  4. Execute in the windowTest system before production, with evidence
  5. DecideProcess owners review results against exit criteria and sign off
An upgrade test cycle that applies to every edition; only the timing differs.
The Sign-Off Table · thesignofftable.com/academy/sap-xpr-304

What would you do?

Contoso is considering Public Edition for a newly acquired subsidiary. Grace asks what changes for testing compared with the Private Edition main system. Which answer is most accurate?

Key points
  • SAP tests its standard software; the customer tests its configuration, data, roles, extensions and integrations in every edition.
  • Size regression by upgrade cadence and extension footprint.
  • Use SAP tooling such as SAP Cloud ALM and, in Public Edition, the Test Automation Tool.
  • Upgrade sign-off needs release review, regression evidence, extension and role checks and open defect status.

Check your understanding · not graded

Lesson check

  1. 1. Who is responsible for regression testing business processes after a Public Edition upgrade?

  2. 2. Which two factors size a regression set across editions?

  3. 3. Which SAP tool provides SAP-delivered test scripts for Public Edition?

  4. 4. What should a process owner check about business roles before signing an upgrade?