Lesson 5 of 5
Test checkpoints for every move
9 min
Every move in the public edition landscape is a chance to catch a problem before it reaches the business. Because SAP operates the systems and the apps do much of the work, it is tempting to treat imports as routine clicks. Luis treats each one as a checkpoint with an owner, an exit criterion and evidence. In a two-tier model, those checkpoints are also what Contoso's auditors and Dan, the finance process owner, will look for when the Mexican entity's numbers roll up into Contoso's group reporting.
- Gate 1: ready to exportBuilt and unit tested; collection Check clean; developer checks passed
- Gate 2: imported into testImport Collection log clean; contained objects match the release list
- Gate 3: tested in testFunctional, integration and regression cases passed on this exact version
- Gate 4: approved to forwardProcess owner sign-off; business interruption risk reviewed; import slot agreed
- Gate 5: live in productionImported; smoke test passed; users informed
| Checkpoint | Evidence | Owner |
|---|---|---|
| Ready to export | Collection name and version, Check result, workbench request numbers, unit test results | Key user or developer |
| Imported into test | Import Collection log, list of contained objects, import date and time | Administrator |
| Tested in test | Test results against the collection version and request numbers; defects closed or accepted | Test lead (Priya) |
| Approved to forward | Sign-off by the process owner; business interruption column reviewed | Process owner and release manager |
| Live in production | Import log; smoke test results; communication sent | Release manager (Luis) |
What each checkpoint should leave behind.
Testing the right thing
The most common checkpoint failure is testing something other than what will move. In the public edition the identifiers are the collection version and the request numbers. If a key user exports a new collection version after testing started, the tested version is no longer the one waiting to be forwarded. Priya's rule for the working example: test evidence must name the collection version and the workbench and customizing request numbers it ran against, and forwarding is approved only for exactly those.
Testing should also match what changed. A custom field needs tests on every app, form, report and interface that uses it. Custom logic needs tests on the business process that triggers it, including error paths. A developer extension needs tests of its service through the UI or API that consumes it. Configuration from CBC needs process tests across the affected scope, not only the changed screen.
- Is the version waiting to be forwarded the one that was tested?Yes → continue · No → retest the new version first
- Did all in-scope tests pass, or are open defects formally accepted?Yes → continue · No → hold
- Is any SAP upgrade preparation or regression window about to start?No → continue · Yes → forward only if the import completes before export and import are disabled, or wait
- Is the business interruption risk high?No → forward and import in the agreed slot · Yes → schedule the production import off-peak and warn users
Checkpoints around SAP's own changes
SAP's upgrades and hotfix collections are moves too, just not yours. After the test system is upgraded, the regression window is the checkpoint: run the regression pack for key processes, every customer extension and every integration, and log findings before production follows. After a content upgrade, test the processes the new content touches before importing it into production. For hotfix collections, a smaller smoke pack run on a schedule catches surprises early. This is where an automated regression pack, such as one built with the Test Automation Tool, pays for itself, because the window is fixed whether or not the team is ready.
What would you do?
In the working example, a software collection was imported into the test tenant on Monday. On Wednesday the key user fixed a label and exported a new version. Priya's test evidence from Tuesday names the earlier version. Luis wants to forward on Thursday. What should happen?
- Treat every move (export, import into test, forward, import into production) as a checkpoint with an owner and evidence.
- Test evidence must name the collection version and request numbers; forward only exactly those.
- Test everything a change touches: apps, forms, reports, interfaces and the processes behind them.
- SAP's upgrades, content upgrades and hotfix collections are checkpoints too; keep smoke and regression packs ready.
- Check the upgrade calendar before forwarding so imports finish before export and import are disabled.
Check your understanding · not graded
Lesson check
1. Which identifiers should public edition test evidence name?
2. A collection was changed after testing. What should happen before forwarding?
3. What is the main checkpoint after SAP upgrades the test system?
4. Why check the business interruption risk before importing into production?