Choosing the scenarios

The first draft of every end-to-end test plan is too big. Contoso's order-to-cash key user Maria listed the variants she knows: four sales order types, three pricing situations (list price, customer-specific agreement, promotion), two delivering plants (1710 Detroit and 1720 Chicago), three shipping methods and two payment terms. That is 4 × 3 × 2 × 3 × 2 = 144 combinations, before returns, credit holds and partial deliveries. Each end-to-end run takes most of a day across five teams. Testing all of them is not rigor; it is a schedule that will never finish.

Selecting scenarios is a risk decision. The goal is to cover every hand-off and every variant at least once somewhere in the test levels from lesson 1, while spending end-to-end runs only where the combination itself carries risk. A good selection is small enough to finish inside the cycle with time to retest, and explicit enough that a process owner can see what was left out and why.

Three questions for every candidate

• How bad is it if this fails in production? Revenue, cash, compliance, customer impact, safety. A failed customer invoice to Great Lakes Fleet Services is worse than a wrong text on a picking list.
• How likely is it to fail? New or changed process compared with ECC, custom code, new interfaces, complex pricing or tax, many teams involved, migrated data used for the first time.
• How often does it happen? High-volume flows run thousands of times a month; a weak spot will surface on day one. Use real volumes from the current ECC system, not guesses.

Variants: cover each, combine few

A variant that only changes behavior inside one step, such as a different pricing condition, rarely needs its own end-to-end run. Prove it at unit or string level, then let one end-to-end scenario carry it through to billing and accounting. A variant that changes the path of the process, such as a third-party order that skips the warehouse, a delivery from the second plant, or an order that stops on a credit block, does need a chain of its own, because different documents and hand-offs appear.

When several path-changing variants exist, combine them so each appears in at least one scenario, and pair the ones that interact. Pairwise thinking is enough for most SAP programs: you do not need every combination, you need every pair that could plausibly break together, such as "Chicago plant" with "customer-specific pricing" if Chicago has its own pricing procedure.

Do not forget the unhappy paths. Production rarely fails on the clean order; it fails on the order that is changed after delivery, the invoice that exceeds its price tolerance, the return that needs a credit memo, or the payment that arrives short. At least one scenario per major process should exercise an exception path end to end, because exceptions create the documents and postings that nobody looks at until month-end close. For Contoso that meant adding a customer return with credit memo for Great Lakes Fleet Services and a supplier invoice with a price variance that stops on a payment block.

Where candidates come from

Start from the program's process hierarchy, for example the solution processes and scope items held in SAP Cloud ALM or modelled in SAP Signavio, so that nothing in scope is forgotten. Add the current system's transaction volumes, the incident history from the last two years, the list of custom developments and the interface inventory. A scenario that touches a custom enhancement and a new interface goes to the top of the list. Then ask the people who run the process today which situations cause manual work, and which reports finance checks at month-end. Those answers often reveal a scenario no document mentions, such as an intercompany stock transfer between Detroit and Chicago that is booked by hand every quarter. Finally, think ahead to regression: the end-to-end scenarios you pick now become the core of the regression pack after go-live, so choose ones that are worth maintaining.