Lesson 5 of 5
Testing per path
9 min
Every path needs testing, but not the same testing. The path decides what is new, what is carried forward and what is transformed, and therefore where defects are most likely to hide. A test strategy copied from a different kind of program tests the wrong things thoroughly and the right things barely.
Where the testing weight falls
| Test focus | New implementation | System conversion | Selective data transition |
|---|---|---|---|
| Process testing | Every process, as new design | Regression of existing processes plus changed areas | Reused processes regressed; redesigned ones tested as new |
| Data | Data migration testing in mock loads: rules, reconciliation, owner validation | Before-and-after comparison of converted data; consistency checks | Selection correctness, completeness of document chains, reconciliation by unit and period |
| Custom code | Only new extensions | All adapted custom code, especially code reading changed tables | Selected code that was transferred and adapted |
| Technical rehearsal | Mock loads and cutover timing | Repeated conversion rehearsals with downtime timing | Transformation runs and their timing |
| User acceptance | Large; users learn new processes | Focused on changed areas and key reports | Mix, depending on redesign |
New implementation: test everything as new
In a greenfield program, nothing is proven. Every configured process needs unit, integration and acceptance testing, every interface needs end-to-end testing with partner systems, and every migrated object needs mock loads with reconciliation and owner sign-off. The data migration test workstream is often the largest single risk area, because history stays behind and users will judge the new system by whether their open orders, balances and stock arrived correctly.
System conversion: prove that nothing broke
In a conversion, processes are carried forward, so regression testing is the core: what worked in ECC must still work. Around it sit three conversion-specific activities. Comparison testing: balances, open items, stock values and key reports are captured before conversion and compared after it, per company code and ledger. Custom code testing: adapted programs are tested for correct results, not just for running without error. Conversion rehearsals: the technical conversion is run end to end with timing, data validation and sign-off, so that go-live weekend is a repeat, not a premiere.
- BeforeCapture trial balance, open items, stock, key reports in ECC
- ConvertRehearsal or production conversion runs
- AfterSame reports and figures captured in SAP S/4HANA
- CompareDifferences per company code, ledger and account listed
- ExplainEach difference explained by a known change or raised as a defect
- SignFinance and process owners sign the comparison
Selective data transition: prove the selection
A selective data transition adds a question the other paths do not have: did we move exactly what we selected, and is it consistent? Tests check that the right company codes, periods and objects arrived, that document chains are complete (order, delivery, invoice, payment), that nothing outside the selection leaked in, and that reconciliation holds per organizational unit and period. Reused processes need regression; redesigned ones need full testing.
One program can need more than one profile. Contoso's main program is a conversion, so its test strategy centers on regression, comparison and conversion rehearsals. Its Wave 2, loading Alternadores del Norte from a non-SAP legacy ERP into the converted system as company code 1910, follows the new implementation profile instead: mock loads, data reconciliation and owner validation for the Mexican entity, plus regression of the existing processes that the new company code touches.
Where SAP tools fit
| Tool | Used mainly in | Role in testing and validation |
|---|---|---|
| SAP Readiness Check | Conversion, also planning other paths | Shows which simplification items and code areas need test focus |
| Simplification Item Check | Conversion | Consistency checks that must pass before conversion runs |
| Software Update Manager with DMO | Conversion | Runs the conversion that rehearsals time and validate |
| SAP S/4HANA Migration Cockpit | New implementation | Simulation and message logs as evidence for migration tests |
| SAP Landscape Transformation technology | Selective data transition | Runs the table-level transfers whose selection tests prove |
| SAP Cloud ALM | All paths | Test plans, execution, defects and evidence |
SAP tools by path and how they support testing and validation.
What would you do?
Contoso's first test strategy draft for its system conversion is copied from a greenfield program: it plans full design testing of every process and three mock loads with the Migration Cockpit, but has no before-and-after comparison. What should Priya change?
- New implementation: test every process as new; data migration mock loads are a major risk area.
- System conversion: regression, before-and-after comparison, custom code results and timed conversion rehearsals.
- Selective data transition: selection correctness, document chain completeness, reconciliation by unit and period.
- Match the test strategy and SAP tools to the path; a one-size strategy is a warning sign.
Check your understanding · not graded
Lesson check
1. Which test activity is central to a system conversion but not to a greenfield program?
2. Which path places the greatest emphasis on data migration mock loads?
3. What does selection testing in a selective data transition check?
4. Which SAP tool supports test plans, execution, defects and evidence across all paths?