Lesson 5 of 5
Mapping simplification items to test scope
11 min
Listen to this lesson
Every relevant simplification item with business impact changes something a user, a report or an interface will meet after conversion. Each of those changes needs a test that proves the converted system behaves as decided. Mapping items to processes and test cases is how the item log becomes regression scope, and it is where test leads add most value in a conversion.
From item to test
- Relevant itemFrom Readiness Check or the SI check
- Affected processesWhich business processes, roles, reports and interfaces touch it
- Expected changeWhat should be different after conversion, and what must stay the same
- Test typeProcess test, data validation, UI and role test, interface test, custom code regression
- Test case and evidenceLinked in SAP Cloud ALM; run in each mock conversion
| Item at Contoso | Affected process | Expected change | Test |
|---|---|---|---|
| Business Partner Approach | Customer and supplier maintenance; order-to-cash; procure-to-pay | Maintenance in BP; XD01/XK01 redirected; same numbers if so decided | BP completeness and roles; create and change customers and suppliers by role |
| Storage Location MRP | MRP in plant 1710 | Spare stock in 171S handled by an MRP area | MRP comparison on frozen data |
| Simplified data model in SD | Order-to-cash reporting and custom reports | Status and document flow read from new structures | Regression of SD reports and Maria's order-to-cash scenarios |
| Inventory management data model | Stock reporting and valuation | Same quantities and values from new tables | Stock and value before-and-after comparison |
| Finance conversion items | Close, reporting, asset accounting | Balances unchanged; new structures after migration | Reconciliation of balances by company code 1710 and 1810 |
Mapping examples from Contoso's item log to tests.
Two kinds of tests come out of the mapping. Change tests prove that the decided change works: the business partner screens, the MRP area, the successor app. Sameness tests prove that what should not change did not: balances, stock values, document flows, outputs. Conversions fail sign-off more often on sameness than on change, because nobody wrote down what should stay the same.
| Change test | Sameness test | |
|---|---|---|
| Question | Does the new behavior work as decided? | Did what should stay the same stay the same? |
| Expected result | From the item note and Contoso's decision | From the source system before conversion |
| Typical evidence | Process run with documents in the converted system | Before-and-after comparison of reports and balances |
| Example | Supplier created in BP with the supplier role | Open AP balance for Lakeside Components unchanged |
Run the mapped tests in every mock conversion, not just the last one. Mock 1 shows whether the decisions work at all; mock 2 shows whether fixes held and nothing new broke; the dress rehearsal confirms the timed subset inside the cutover window. An item whose tests pass only in the final mock has had no chance to fail early, which is the whole point of mocks.
Some items also change what testers themselves do. After conversion, test data creation for customers and suppliers runs through business partner maintenance, and test scripts that called retired transactions must be updated. Review the regression library against the item log before mock 1, or the first cycle will be spent fixing scripts instead of finding defects.
Worked example: testing the Business Partner Approach
- Change test: in CMQ, create a supplier in transaction BP (or the Fiori app) with the roles FLVN00 (FI vendor) and FLVN01 (purchasing), then a purchase order for it. Check that XK01 redirects to BP and that the supplier number follows the agreed number range.
- Change test: change Great Lakes Fleet Services (17100001) in BP with the customer roles FLCU00 and FLCU01, then create a sales order in sales area 1710 / 10 / 00.
- Sameness test: compare the number of customers in EP1 (4,850) with the entries in link table CVI_CUST_LINK in the converted system, and do the same for suppliers with CVI_VEND_LINK.
- Sameness test: for a sample including one-off aftermarket customers, compare address, tax number, payment terms and bank details before and after, with the same report variants.
Tools that help
The Conversion Guide describes Data Transition Validation (DTV), included in the standard license, which compares business data before and after a conversion using business reports or transactions; reports are agreed with the business and auditors in the preparation phase. In SAP Cloud ALM, items can be logged as requirements or follow-ups and linked to test cases, so traceability from item to evidence stays in one place.
What would you do?
The order-to-cash team tested business partner maintenance thoroughly and calls the Business Partner Approach item "covered". Priya sees no test of the customer master data itself after conversion. What is missing?
- Map each relevant item to processes, expected change and test type.
- Write change tests and sameness tests; sameness is where sign-off usually fails.
- Use before-and-after comparisons, such as DTV, for data and balances.
- Keep item-to-test traceability, ideally in SAP Cloud ALM.
- Prove the Business Partner Approach with BP role tests and CVI_CUST_LINK and CVI_VEND_LINK comparisons.
Check your understanding · not graded
Lesson check
1. Why map relevant simplification items to processes?
2. What does a sameness test prove?
3. Which tool compares business data before and after a conversion using reports?
4. An item is marked "no impact". What should the log record?
5. Which comparison proves that every EP1 customer became a business partner in the converted system?