Lesson 3 of 6
Adapting standard scripts
10 min
A downloaded SAP test script is written for SAP's reference system. To become Contoso's scenario it needs Contoso's organizational units, Contoso's data, Contoso's roles and Contoso's variants. The skill is to change what must change and keep the rest, so that the script stays recognizable and maintainable.
What to replace
| Element in the standard script | Replace with | Contoso example |
|---|---|---|
| Sample organizational units | Your company code, plants, storage locations, sales area, purchasing organization | Company code 1710, plant 1720 Chicago instead of 1710 when testing the second plant |
| Sample master data | Records that exist in your test client and fit the scenario | Customer Great Lakes Fleet Services; product CMC-ALT-100 |
| Standard business roles | Your project's business roles | Contoso's "Order Desk Specialist" role instead of the SAP template role |
| Apps or transactions | What your users will really use | Contoso keeps VL10 for collective delivery creation alongside Fiori apps |
| Quantities, dates and prices | Values that exercise your rules | 50 units, so the fleet volume discount (from 25 units) applies |
Typical replacements when adapting a standard script.
A repeatable adaptation method
- CopySave the downloaded script under your scenario ID; keep the original for reference
- ParameterizeMove every org unit, customer, product, quantity and date into a data table at the top
- Map roles and appsReplace SAP template roles and apps with the ones Contoso users will have
- Mark deltasAdd Contoso-specific steps for requirements that differ from standard, and label them
- Remove with a reasonStrike out steps not in scope and note why, instead of deleting them silently
- Dry runRun the adapted script once in QAS client 100 and fix wording, data and expected results
Deltas: variants without rewriting
Fit-to-standard workshops end with a list of delta requirements: places where the company needs something the standard process does not do. Each delta should appear in the adapted script as a clearly labeled addition. Keep the standard step numbers and add suffixes, so step 4 stays step 4 and Contoso's extra credit approval becomes step 4a. When SAP updates the standard content after an upgrade, you can compare line by line and see quickly which steps are yours.
Variants: one script or many?
Not every variant needs its own script. A variant that only changes data (another plant, another product) can be a second row in the data table. A variant that changes the steps or the expected outcome (partial delivery, a rejected approval, a credit block) deserves its own scenario ID, because it will pass or fail independently and needs its own expected results.
- Does the variant change the steps?Yes → separate scenario ID · No → next question
- Does it change the expected business outcome?Yes → separate scenario ID · No → next question
- Does it only change data, such as plant or product?Yes → add a row to the data table of the existing scenario · No → discuss with the test lead
What would you do?
Contoso also ships alternators from plant 1720 Chicago, where the standard cost is $156 instead of $150. Maria asks whether she needs a second sell-from-stock scenario for Chicago. What do you advise?
- Replace sample org units, master data, roles, apps and values with your own.
- Move data into a table at the top so the script can be rerun.
- Add delta steps with suffixes (4a, 4b) so the standard structure stays recognizable.
- A variant that changes steps or outcomes needs its own scenario; a data-only variant needs a data row.
- Never copy SAP's example values into your expected results.
Check your understanding · not graded
Lesson check
1. Why number delta steps with suffixes such as 4a?
2. A variant only changes the plant. What is the simplest correct approach?
3. Where do delta requirements usually come from?
4. What should you do with a standard step that is out of scope?