Lesson 6 of 6
Handover verification
9 min
Listen to this lesson
The last step of a refresh is the one testers care about: a handover that tells them the system is safe and ready. Without verification, the first tester to log on becomes the smoke test, and the first defect of the cycle is an environment problem. A short, standard checklist run by Basis and a key user, with results recorded, changes that.
A smoke checklist
| Check | How | Expected result |
|---|---|---|
| Outbound email | Trigger a test output with email channel; check SAPconnect | Redirected or blocked; nothing sent externally |
| RFC destinations | Connection tests in SM59 for each interface destination | All point to test partners; none to production hosts |
| Jobs | SM37 for released jobs | Only jobs on the test plan are released, with test variants |
| Client and system settings | SCC4 for client 100 and 200; SE06 | Values match CMQ's standard, not production's |
| Transports | STMS import history and queue | Captured CMQ-only transports re-imported with acceptable return codes |
| Data protection | Spot-check known customers and supplier bank details | Scrambled values; no real personal data |
| Business smoke test | Create a sales order for Great Lakes Fleet Services, deliver, bill; create a PO with Lakeside Components | Documents created, outputs go to test devices |
| Front ends | Log on with SAP GUI and the Fiori launchpad as a test user | Tiles and transactions available for the test roles |
A post-refresh smoke checklist for CMQ. Extend it with your critical interfaces.
- Basis checksSam runs safety, identity, baseline and job checks
- Key user checksMaria runs the business smoke test in the launchpad
- RecordResults with screenshots or exports attached to the refresh record in SAP Cloud ALM
- DecideAll passed → hand over; any safety check failed → system stays closed
- AnnounceHandover message to testers: baseline, known limitations, start time
Known limitations
Not every difference from production can or should be removed. Some interfaces have no test partner; some outputs go to a file instead of a printer; some jobs are deliberately not released. The handover message should list these known limitations plainly, so testers do not raise defects for them and test leads can see which scenarios cannot be fully proven in CMQ. Each limitation needs either an alternative test (for example, checking an interface file's content instead of its delivery) or an explicit note in the sign-off that the scenario was not covered.
When verification fails
If a check fails, fix it and rerun that check and any related ones; do not rerun only the step that was changed. A wrong RFC destination, for example, suggests the partner profile and port for the same partner may also be wrong. Record the failure and the fix in the refresh record: repeated failures of the same check point to a runbook step that needs improving.
What would you do?
During handover checks after a CMQ refresh, the SM59 test shows the destination to the bank interface still points to the production bank gateway. Everything else passed and testers are waiting. What should Sam do?
- Verify before handing over: safety, identity and settings, baseline, function, access.
- Any failed safety check keeps the system closed.
- Record results and attach them to the refresh and the test cycle.
- Automate mechanical checks; keep a key-user business smoke test.
Check your understanding · not graded
Lesson check
1. Which check category always blocks handover if it fails?
2. How do you verify RFC destinations after a refresh?
3. Who should run the business smoke test?
4. What should the handover record include?