Lesson 2 of 6
Anatomy of a good scenario
10 min
A business test scenario is a short document that lets someone who did not write it run a business process and decide, without guessing, whether the result is right. That last part matters most. A scenario that only lists clicks tells a tester what to do but not what "right" looks like, so every tester decides for themselves.
The parts of a scenario
| Part | What it holds | Contoso example |
|---|---|---|
| ID and title | A unique, stable identifier and a title that states the business outcome | O2C-010 Sell alternators from stock to a fleet customer at contract price |
| Purpose | One or two sentences on what business risk the scenario covers | Proves that a standard fleet order is priced, shipped, billed and posted correctly |
| Scope item and requirement links | The standard process it is based on and the requirements it proves | BD9; requirements O2C-R-004 (fleet pricing) and O2C-R-011 (billing) |
| Business roles | Who performs each step, by role, not by name | Internal sales representative, warehouse clerk, billing clerk |
| Preconditions | What must be true before step 1 | Customer exists in sales area 1710 / 10 / 00; 60 units of CMC-ALT-100 unrestricted in plant 1710, storage location 171A |
| Test data | The specific records and values to use | Customer Great Lakes Fleet Services; 50 units; requested delivery date in the open period |
| Steps | Numbered actions, each in one app or transaction | Step 3: Create outbound delivery for the order from shipping point 1710 |
| Expected results | What the system must show after each step, with values | Delivery created for 50 units; picking status not yet started |
| Evidence | What the tester captures to prove the result | Document numbers, document flow, journal entries |
The parts of a business test scenario.
Scenario, test case, test step
Projects use these words differently, so agree them early. In this course a scenario is an end-to-end business story, such as selling 50 alternators to a fleet customer. It contains one or more test cases, often one per process step or per role, and each test case has steps. SAP Cloud ALM uses the term test case for a set of activities and actions; Solution Manager projects often say test script. The labels matter less than consistency.
Weak and strong, side by side
| Part | Weak | Strong |
|---|---|---|
| Title | Sales test 1 | O2C-010 Sell alternators from stock to a fleet customer at contract price |
| Preconditions | System available | Customer extended to sales area 1710 / 10 / 00 with contract price; 60 units in stock at 171A |
| Step | Create order | Create a standard sales order in Manage Sales Orders for 50 units of CMC-ALT-100, sold-to Great Lakes Fleet Services |
| Expected result | Order saved | Order created; net price per unit equals the fleet contract price; schedule line confirmed for the requested date; no incompletion log |
| Evidence | Screenshot | Order number recorded; pricing screen captured; document flow at the end of the scenario |
Look at what the strong version does. A stranger can tell exactly which data to use. The preconditions say what must already exist, so a failure at step 1 caused by missing stock is recognized as a setup problem, not a defect. Every expected result names something the tester can check against a value. And the evidence is chosen to prove the outcome, not just the click.
Rules of thumb
- One action per step. If a step says "create the order and the delivery", split it. A failure needs a precise location.
- Write roles, not names. "Billing clerk" survives staff changes; "ask Maria" does not.
- State values, not just fields. "Check the price" is an instruction; "net price 240.00 USD per unit" is an expected result.
- Keep data out of the steps. Put customers, products and quantities in a data section so the scenario can be rerun with fresh data.
- Name the evidence. Say which document numbers and screens the tester records.
What would you do?
Priya receives a scenario from a key user. The steps are clear, but every expected result reads "No error message". What is the most useful feedback?
- A scenario lets someone else run a process and judge the result without guessing.
- Core parts: ID and title, purpose, links, roles, preconditions, test data, steps, expected results, evidence.
- One action per step, roles not names, values not fields, data kept separate from steps.
- Agree on the terms scenario, test case and step at the start of the project.
Check your understanding · not graded
Lesson check
1. What is the main job of the preconditions section?
2. Which step is written best?
3. Why should scenarios name business roles rather than people?
4. Why keep test data in a separate section from the steps?