Lesson 3 of 6
From variants to scenarios
9 min
Listen to this lesson
A mining model with 300 variants is not a test plan. Most variants differ only in the order of two steps, or in a repeated activity that does not change the outcome. The skill is to turn variants into a manageable set of test scenarios that still represent what the business does, and to pick which of them to automate.
Step 1: map activities to test steps
| Mined activity | Test step | App or transaction (Contoso) |
|---|---|---|
| Order created | Create standard order for sold-to 17100001 | Manage Sales Orders (F1873) or VA01 |
| Credit block set | Order exceeds credit limit; check status | Credit status in the order; Manage Credit Accounts for the credit account |
| Credit released | Release blocked order | Blocked SD documents (VKM1) or the Fiori release app in your release |
| Delivery created | Create outbound delivery from shipping point 1710 | VL01N or the Fiori Create Outbound Deliveries app |
| Goods issue posted | Pick from 171A and post goods issue | Warehouse task confirmation in EWM 1710, then goods issue |
| Invoice created | Bill the delivery | VF01 or the Fiori Create Billing Documents app |
Each mined activity maps to a test step and the app or transaction that performs it. Verify app IDs for your release.
Step 2: group variants into scenarios
- Start from the variants that together cover most cases (Contoso's six variants cover 92%).
- Merge variants whose differences do not change what the system does, for example the same steps where only the order of two independent changes differs.
- Keep variants separate when the difference triggers different system logic: a credit block, a partial delivery, a credit memo request, a cancellation.
- Turn each scenario's attribute spread into data variation: order types, sales areas, customer groups and plants that appear in real cases.
- Record the variant IDs each scenario represents, so coverage can be measured later.
Variant grouping is ordinary test design with better evidence. The equivalence classes and decision tables from sap-tst-201 still apply: variants that the system treats the same belong in one class, and the attributes that change system behavior become the conditions of a decision table. Mining replaces guesses about which classes exist and how big they are.
Step 3: data variation from attributes
Variants tell you the path; attributes tell you the data. If 30% of the credit-block cases come from aftermarket customers in plant 1720 and 70% from fleet customers in plant 1710, the credit-block scenario needs both, because the profit center derivation and the credit segment may differ. Mining makes this explicit: slice each variant by order type, sales area, plant and customer group, and add a data row for every slice with a meaningful share. Wei turns those rows into test data recipes for CMQ and later CMR.
Step 4: pick automation candidates
| Criterion | Why it matters | Contoso example |
|---|---|---|
| High frequency | Runs in every regression; automation pays back fastest | O2C-01 standard order to cash |
| Stable path | Fewer script changes per release | O2C-01 and O2C-04 |
| Many data variations | One script, many rows | O2C-03 across fleet and aftermarket |
| Clear expected results | Assertions can be exact | Prices, credit status, document flow |
| Low frequency but high impact | Usually stays manual or semi-automated, but stays in scope | O2C-05 complaint and credit |
Mining frequency feeds the automation decision; Ravi uses it to rank candidates.
Ravi's automation portfolio has about 400 regression tests, of which 240 are to be automated. Mining gives him an ordering inside that plan: automate the scenarios that represent the most real cases first. The long tail, the 8% of cases spread over hundreds of variants, is reviewed by Maria for business impact, not automated variant by variant.
What would you do?
The mining model shows 40 variants that differ from V1 only by an extra "change sales order" step at different points. Together they hold 9% of cases. A tester proposes 40 new test cases. What is the better approach?
- Map mined activities to test steps and the apps or transactions that perform them.
- Group variants by what the system does differently, not by sequence labels.
- Use attribute slices to define data variation per scenario.
- Rank automation candidates by frequency, stability and data variation; keep high-impact rare paths in scope.
Check your understanding · not graded
Lesson check
1. When should two variants become separate scenarios?
2. What do variant attributes give a test designer?
3. Which scenario is the best first automation candidate at Contoso?
4. Why store variant IDs on each test case?