Lesson 5 of 5
Moving and testing extensions
9 min
An extension is not finished when it works in development. It has to reach production intact, be proven in the quality system, and keep working through every later change and upgrade. This lesson pulls the course together into a test approach for extensions, and compares how this works in SAP S/4HANA Public Edition and in private cloud or on-premise systems.
The path to production
- Day 1Build in developmentKey user creates and publishes the field, logic or query; unit checks by the key user
- Day 1Register for transportAssigned to a package and transport request (or added to a software collection)
- Day 2Import to qualityTransport imported into QAS; extension appears in client 100
- Days 2 to 5TestFunctional, integration and regression scenarios run with target roles
- Release windowImport to productionImported with the related changes after sign-off
What to retest for each kind of extension
| Extension | Retest | Contoso example |
|---|---|---|
| UI adaptation | Scenarios that use the app, with the target role; variants that might need hidden fields | Domestic and export sales orders after hiding incoterms fields |
| Custom field | Capture, save, copy forward, print, report, API where enabled; existing documents without the field | Order to invoice with the fleet contract number; invoice form; old orders still open |
| Custom logic | Positive and negative cases; performance on large documents; interaction with other logic | Fleet and non-fleet orders; order with 200 items |
| Custom analytical query | Reconciliation with standard totals; authorization filters | Open fleet orders total equals standard sales order list for the same filter |
Retest needs by extension type.
Into the regression library
Every extension adds a permanent risk: an SAP upgrade, a new extension or a configuration change could break it. So every extension should add or update at least one scenario in the regression library, the set of scenarios that is run before each upgrade and major release. Without this, extensions are tested once at creation and then forgotten until a user finds the problem.
- Extension approvedRequirement and owner recorded in the extension inventory
- Scenarios writtenPositive, negative and downstream scenarios linked to the extension
- First test passedEvidence filed with the transport
- Added to regressionScenarios tagged with the extension name in the regression library
- Rerun on changeRun before each upgrade and whenever related configuration or extensions change
Public Edition compared with private cloud and on-premise
| Topic | SAP S/4HANA Cloud Public Edition | Private cloud and on-premise |
|---|---|---|
| Key user extensibility | Available; central way for business-led changes | Available once the key user tools and transport are set up |
| Developer extensibility | ABAP Cloud with released APIs only | ABAP Cloud recommended; classic ABAP also possible |
| Classic modifications | Not possible | Technically possible; discouraged as level D |
| Transport of key user items | Export Software Collection and Import Collection | Adaptation Transport Organizer with Register Extensions for Transport |
| Upgrades | Scheduled by SAP for all customers | Planned by the customer |
| Testing consequence | Regression must be ready for each SAP-scheduled upgrade | Regression scheduled with each customer upgrade or feature pack |
When SAP changes underneath you
Released extension points and data sources come with a stability promise, but SAP can still deprecate an extension point and offer a successor, add mandatory fields to an object, or change the standard logic that runs before and after your custom logic. Read the release information for each upgrade with your extension inventory beside it: every extension that touches a changed area moves to the front of the regression queue. This is where the inventory pays for itself.
What would you do?
Contoso plans an SAP S/4HANA feature pack upgrade. Grace asks Priya how much regression testing the 14 key user extensions need. What is the best answer?
- Extensions move development → quality → production; keep dependent items together.
- Retest needs differ: UI adaptations, fields, logic and queries each fail in their own ways.
- Every extension adds or updates scenarios in the regression library, rerun before upgrades.
- Public Edition: software collections, SAP-scheduled upgrades, no modifications. Private cloud and on-premise: ATO transports, customer-planned upgrades.
Check your understanding · not graded
Lesson check
1. After adding a custom field to the sales order, what should be added to testing?
2. Why keep a field, its logic and its form change in the same transport or collection?
3. In Public Edition, which apps move key user extensions between systems?
4. What should a release sign-off show for extensions?