Lesson 5 of 5
Handover
12 min
Listen to this lesson
The worst way to start functional testing is on a system that is not finished. Testers raise defects that are really missing follow-up steps, the defect log fills with noise, and confidence drops before the real testing begins. A clear technical acceptance between Sam's team and Priya's prevents this. It applies to every converted system: sandbox, CMD, CMQ, each mock and finally production.
Technical acceptance criteria
| Area | Criterion | Evidence |
|---|---|---|
| SUM | Run completed; every stop and ignored error explained | SUM evaluation and run log |
| Custom code | SPAU and SPAU_ENH complete; readiness ATC has no open in-scope errors | ATC result, transport list |
| Data migrations | Finance migration completed and reconciled; silent data migrations finished in all clients | Migration monitors, reconciliation file |
| Platform | bgRFC, output, jobs, RFC destinations and printers set up | Checklist with owner and time |
| Access | Test users and roles in place; Fiori launchpad opens for each test role | Login test per role |
| Smoke test | A short set of key transactions works end to end | Smoke test results in the test tool |
Contoso's technical acceptance checklist for a converted system.
The smoke test is short on purpose: perhaps fifteen transactions across finance, purchasing, sales and production, run by the test team, not by Basis. At Contoso it includes posting a journal entry in company code 1710, creating a purchase order for Lakeside Components, creating and delivering a sales order for Great Lakes Fleet Services from shipping point 1710, and a goods receipt of rotor CMC-RTR-200 into storage location 171S, which is not managed in EWM. If the smoke test fails, the system goes back to Sam's team, not into the defect log.
| # | Smoke test step | App or transaction | Pass when |
|---|---|---|---|
| 1 | Post a journal entry in company code 1710 | Post General Journal Entries (F0718) | Document posted; ledger 0L updated |
| 2 | Display Great Lakes Fleet Services as a business partner | BP, partner 17100001 | Customer role and sales area 1710 / 10 / 00 present |
| 3 | Create a purchase order for Lakeside Components | ME21N, supplier 17300001 | PO saved; output on NEU as before |
| 4 | Receive rotors CMC-RTR-200 | MIGO, movement 101 into 171S | Material document and accounting document posted |
| 5 | Create a sales order for 50 CMC-ALT-100 | VA01, sold-to 17100001 | Price 240.00 per piece; confirmation output on NAST as before |
| 6 | Deliver from shipping point 1710 | VL01N, picking from 171A | Goods issue posted |
| 7 | Bill the delivery | VF01 | Invoice posted; output control produces EDI and email |
| 8 | Run MRP for plant 1710 | MD01N (MRP Live) | Run completes; 171S not planned |
| 9 | Check an interface | WE02 for an inbound ORDERS IDoc in test | IDoc status 53 (posted) |
Part of Contoso's smoke test set, run by the test team on each converted system.
Record the handover in the same place as the test results. In SAP Cloud ALM, Contoso keeps the technical acceptance checklist, the smoke test run and the known-issues list together with the test plan for the cycle, so anyone looking at a later defect can see what state the system was in when testing started. The same record, repeated for each conversion, shows the steering committee that each environment was fit for purpose before anyone tested on it.
- Technical checksBasis confirms SUM, follow-ups and platform checklist
- Data checksFinance reconciliation and migration monitors reviewed
- Smoke testTest team runs the short end-to-end set
- AcceptanceSam and Priya sign the handover with any known issues listed
- Functional testingRegression, integration and user acceptance cycles start
What to hand over besides the system
- The list of known issues and workarounds, so testers do not raise duplicates.
- The list of changed behavior from simplification items relevant to Contoso, so testers know which differences from ECC are expected.
- The finance reconciliation results and SAP's Data Transition Validation comparisons, if used.
- Runtimes from the conversion, which go to Luis for the cutover plan.
- The test data situation: the system is a converted copy of production, so the data is real and must be protected.
- Did the smoke test pass?Yes → next question · No → back to Basis; do not start testing
- Are all technical acceptance criteria met?Yes → accept and start testing · No → next question
- Are the gaps known, owned and not blocking the planned tests?Yes → accept with a known-issues list · No → hold the handover and agree a date
What would you do?
CMQ has been converted. Everything on the checklist is done except that two interfaces to the plant systems are not yet connected; the plan has integration testing of those interfaces in week three. Testing of finance and sales could start tomorrow. What should Priya decide?
Data Transition Validation for business evidence
Data Transition Validation (DTV, SAP Note 3117879) compares business data before and after a conversion using reports or transactions as instruments, and SAP includes it in the standard license. The pattern from SAP's guide: agree the comparison reports with the business and the auditors in the prepare phase, create a DTV project with test specifications, extract from the source during ramp-down, then validate in the converted system. Contoso uses it for trial balances by company code, open customer and supplier items, and stock values for plants 1710 and 1720, so Dan's sign-off rests on a comparison rather than on screenshots.
- Never start functional testing on an unfinished system; use a technical acceptance gate.
- Criteria: SUM documented, custom code done, migrations complete, platform set up, access, smoke test.
- A failed smoke test sends the system back to Basis, not into the defect log.
- Hand over known issues, expected differences, reconciliation results and runtimes too.
Check your understanding · not graded
Lesson check
1. Why use a technical acceptance gate before functional testing?
2. What should happen when the smoke test fails on a newly converted system?
3. Which evidence shows silent data migrations are complete?
4. Why hand testers a list of changed behavior from simplification items?
5. When does Contoso extract source data for Data Transition Validation?