Test Scenarios

Why it matters

The most expensive gaps are situations nobody thought of, and a pile of detailed test cases hides them. Teams that jump from a story to test cases often write many cases for the main path and none for the refund that fails or the user who changes their mind. A scenario list shows the scope at a level where such gaps stand out.

Scenarios are also the cheapest way to agree on scope: the product owner and developers can review them before anyone writes steps, and a scenario whose expected result nobody can state is a requirement question found before coding.

What a test scenario is, and what it is not

A good scenario names an actor, a situation and the outcome that matters, and traces to its source: a user story, an acceptance criterion, a step in a business flow or a risk. It does not depend on screens or concrete data, so it survives a redesign.

"Test scenario" is not a key term of the ISTQB Foundation syllabus, and teams use it in different ways. The nearest ISTQB terms are the test condition, a testable aspect of a component or system identified as a basis for testing, and the test procedure, a sequence of test cases in execution order. A scenario often combines several test conditions into one situation a user goes through from start to end. Teams that use the word for an ordered sequence of test cases mean something close to a test procedure.

• Good: "A customer tries to cancel an order that has already gone out for delivery."
• Too vague: "Test order cancellation." It names a feature, not a situation.
• Too detailed: "Open order 1042, tap Cancel, tap Yes, check the message." That is a test case.

Scenario versus test case

The scenario answers "which situation do we test?"; the test case answers "exactly how, with which data, and what result?". One scenario usually expands into several test cases, one per variation of data, state, role or boundary, and each case traces back to its scenario and through it to the requirement.

• Detail: a scenario is one line; a test case has preconditions, data, steps and an expected result.
• Purpose: scenarios agree on scope and expose gaps; test cases make execution repeatable.
• Readers: product owners review scenarios; test cases are for whoever executes them, a person or a tool.
• Change: a redesigned screen changes test cases, while scenarios usually stay the same.

TS-04  A customer tries to cancel an order that has already gone out for delivery

TC-04.1  Order "Out for delivery", paid by card
         Expected: refused; the app gives the reason and a link to support;
                   order status and payment unchanged
TC-04.2  Order "Out for delivery", cash on delivery
         Expected: refused with the same message as TC-04.1; status unchanged
TC-04.3  Order "Delivered", paid by card
         Expected: refused; order status and payment unchanged

Try it: Test Scenario Generator

Deriving scenarios from stories and flows

A user story names one goal, and its acceptance criteria state the rules. Walk the flow a user follows to that goal, using the story, any flow diagram and the states the main object passes through, and ask at every step what else can happen.

Look for three kinds of flow. The main flow, often called the happy path, is the usual way to the goal. An alternative flow is another valid route with no error: another payment method, or a user who changes their mind and stops. An exception flow is what happens when something goes wrong: a rule refuses the action, a dependency such as a payment provider fails, or data changes while the user acts. Most exception flows end without reaching the goal, but some recover and rejoin the main flow.

• Write the main flow as a few short steps from the user’s point of view.
• At each step, ask which other choice, data, state or role is possible, and what can go wrong. Every answer that changes the outcome is a candidate scenario.
• Make sure every acceptance criterion has a scenario.
• Give each scenario an id, a flow type and a source. If you cannot state its expected result, write a question for the product owner.

Try it: User Story → Test Scenarios

Worked example: cancelling a grocery order

The story below comes from a grocery delivery app. Its main flow: the customer opens the order, taps Cancel and confirms; the order becomes Cancelled, a card payment is refunded and a confirmation arrives. Walking that flow gives the six scenarios under the story: one main, two alternative and three exception flows.

TS-05 and TS-06 have no expected result in the criteria: nothing says what happens when the refund fails, or which moment counts for a late cancellation, opening the dialog or confirming it. Both became questions for the product owner before anyone wrote a test case.

GRO-31  Cancel an order
As a customer, I want to cancel an order I placed,
so that I do not pay for something I no longer need.

AC1  An order can be cancelled until it is out for delivery.
AC2  Cancelling refunds the full amount paid to the card used for payment;
     a cash-on-delivery order needs no refund.
AC3  An order that is out for delivery cannot be cancelled: the app says why
     and shows a link to support.
AC4  After cancelling, the customer gets a confirmation in the app and by SMS.
Order statuses: Placed > Packed > Out for delivery > Delivered, or Cancelled

Scenarios
TS-01  main         AC1, AC2, AC4
       Cancel a card-paid order before it is out for delivery: cancelled,
       full amount back to the card, confirmation in the app and by SMS
TS-02  alternative  AC1, AC2, AC4
       Cancel a cash-on-delivery order: cancelled, no refund, confirmation sent
TS-03  alternative  no criterion (confirm step of the flow)
       Open the cancel dialog, then keep the order: the order stays as it was
TS-04  exception    AC1, AC3
       Try to cancel an order that has gone out for delivery: refused, with the
       reason and a link to support
TS-05  exception    no criterion
       The refund to the card fails at the payment provider: expected result?  Q1
TS-06  exception    AC1, AC3
       The order goes out for delivery while the cancel dialog is open:
       which moment counts, opening the dialog or confirming it?  Q2

Scenario coverage: is anything missing?

Scenario coverage asks whether every item of the test basis you chose, such as acceptance criteria, flows, states, roles or risks, is exercised by at least one scenario. Map them in a table with one row per scenario and one column per item: a simple traceability matrix. An item with no scenario is a gap in your tests; a scenario with no item is a gap in the requirement or work outside the story, and it deserves a question.

• Criteria coverage: 4 of 4. AC1 is exercised by four scenarios, and AC2, AC3 and AC4 by two each.
• Flow coverage: 6 of 6, but only for the flows on the list; a flow nobody thought of is not in the denominator.
• Coverage counts items, not depth: AC2’s key checks, the exact amount and the same card, belong in its test cases.
• This is coverage on paper: the criteria are exercised only when the test cases derived from the scenarios have run, and shown to be met only when those tests pass.

Try it: Requirements → Test Scenarios Try it: Requirements → Test Cases

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• Gherkin Reference — CucumberCucumberThe Gherkin syntax for executable specifications: Feature, Rule, Scenario, Given/When/Then steps, Background, Scenario Outline and Examples.