Test Scenarios vs Test Cases: Understanding the Difference and When Each Matters? | Amber Insights #016

Introduction

“Test that two patients cannot book the same appointment.”

It sounds clear. One tester opens two browser windows and books in sequence. Another sends overlapping requests. A third checks only the messages displayed on screen. All three might describe their work as testing the same scenario. They have not necessarily investigated the same behaviour.

The difference lies in the design beneath the sentence: the starting state, the timing, the observations, and the rule used to judge the result.

Issue 015 explored how Quality Engineers turn requirements and risks into meaningful scenarios.

This issue takes the next step: deciding when a scenario is sufficient for discussion, when a detailed case is needed, and how to connect both to credible test evidence.

The aim is not more documentation. It is enough precision for the investigation to answer the question that matters.

01. Agree the meaning before counting the artefacts

For this series, a test scenario describes a situation or behaviour worth investigating, together with its intended outcome or an explicit unresolved question.

A test case defines a particular check through its preconditions, inputs, actions, and expected results. Depending on context, it also needs timing, environment, observation, and clean-up details.

The distinction helps separate selection from execution. A scenario asks what deserves investigation and why. A case explains how a specific investigation will be performed and assessed.

This is a working convention, not a claim that every organisation uses identical terminology. ISTQB distinguishes test analysis, which identifies test conditions, from test design, which develops test cases and associated testware. That supports the distinction without making our local use of “scenario” a universal standard.

Question	Scenario	Detailed test case
What does it establish?	The behaviour, condition, or risk to investigate.	One defined way to investigate it.
What detail matters?	Purpose, scope, expected outcome, or open question.	Starting state, data, actions, observations, and expected results.
Who uses it?	People agreeing on coverage and priorities.	People or tools implementing and performing a check.
What does it prove alone?	No execution result.	No execution result until performed and assessed.

One scenario can produce several cases. A case can contribute evidence to more than one requirement or risk. Neither relationship should be forced into a neat one-to-one count simply because a reporting tool prefers it.

02. Preserve the booking example and its limits

The appointment-booking example in Issues 014 and 015 used five possible acceptance criteria:

1. B1: The patient can view appointment slots available for booking.

2. B2: The patient can select an eligible appointment slot.

3. B3: The system must prevent two patients from successfully booking the same slot.

4. B4: A successful booking must generate a confirmation.

5. B5: If the selected slot becomes unavailable before confirmation, the patient must receive an appropriate message.

   
   

These belong to our teaching example. They are not verified requirements for a real healthcare service. They do not define eligibility policy, authentication, cancellation, the confirmation channel, or an API contract.

Issue 015's S04 asks what happens when two patients compete for one slot. Its S05 asks what happens when the booking commits, but the response is lost. Those are different questions: competing allocations and uncertainty after an allocation.

For the worked cases below, we add three illustrative test-design assumptions, not new agreed product requirements:

• A1: A test fixture can create synthetic patients P-A and P-B who satisfy the example's eligibility policy, plus an available slot S-100 with no bookings. No real patient data is used.

• A2: An authorised test interface can submit reservations, correlate each response with a request, and inspect authoritative persisted allocations for S-100 after processing completes. The concrete interface and schema depend on the implementation.

• A3: A controlled harness can coordinate overlapping attempts, observe relevant timing, and determine when the resulting processing has finished. The environment is otherwise healthy for the normal-success experiment.

These assumptions make an example easier to discuss. A real team must confirm the facilities and policy behind them before adopting the cases. If the facilities do not exist, the case is blocked, or needs redesign; it is not ready because its steps look complete.

03. Move from a scenario to a small family of cases

Start with the question: Can two eligible patients receive successful bookings for the same slot?

Booking once and then trying again is useful, but it exercises an already-booked state. It does not establish how overlapping attempts are handled.

A browser journey adds another useful question: Does the patient see the correct result?

That does not replace inspecting the allocation outcome.

Case	Deliberate variation	Evidence sought
TC-016-01	One patient reserves an available slot.	Successful allocation and the defined confirmation.
TC-016-02	A second patient submits after the first booking is complete.	No second allocation; appropriate unavailability feedback.
TC-016-03	Two eligible patients submit overlapping attempts.	No double allocation; correlated outcomes under contention.
TC-016-04	A reservation commits but its response is lost.	Behaviour after uncertainty; expected recovery remains unresolved.

The first three are not interchangeable. The fourth must not acquire an invented expected result, such as “retry creates no duplicate”, merely because that sounds desirable. The retry contract still requires a product and engineering decision.

Figure 1: Relationship between related booking scenarios and their corresponding test cases, highlighting the distinct conditions required to validate booking allocation, stale selection, overlapping attempts, and recovery behaviour.

04. Write a case that another person can assess

A long list of clicks can be less useful than a short case with a clear starting state and a strong observation. Consider this deliberately bounded example.

TC-016-02 — reject a booking after the selected slot is taken

Basis: B3 and B5; related to Issue 015's stale-slot scenario S03 and competing-allocation scenario S04.

Purpose: Investigate the stale-selection condition without claiming concurrency coverage. Level: service/integration check, with patient-facing feedback checked at the relevant interface. Assumptions: A1–A2.

Design status: illustrative; local adoption requires the unavailability and confirmation decisions below.

Action or preparation	Expected observation
Create fresh S-100, eligible P-A, and P-B. Confirm no existing allocation.	Fixture state is independently confirmed, rather than inferred from a previous test.
Have P-B view and select S-100 while it is available.	The test records that P-B's selection predates the conflicting booking.
Reserve S-100 for P-A and wait for its processing to complete.	One authoritative allocation exists for P-A and the agreed confirmation outcome is observed.
Submit P-B's reservation using the earlier selection.	P-B receives the appropriate unavailability feedback; no second successful booking is reported.
Inspect allocations and correlate both responses to the requests.	Exactly one allocation remains, owned by P-A. No allocation belongs to P-B.
Retain evidence, then remove only this run's synthetic fixture data.	Evidence remains interpretable and the next run can establish its own starting state.

“Appropriate feedback” is still not a sufficiently precise message oracle for a production test. The Product Owner must agree on the observable outcome and recovery guidance; engineering must identify where and how it can be observed. No email, HTTP status code, or exact message text is prescribed here because the teaching criteria did not specify them.

The oracle is the basis for deciding whether an observation is correct. A message oracle may be unresolved even while a narrower allocation check is executable. Report those subchecks separately rather than calling the entire case passed.

The case also needs an agreed observation bound: how long may processing take, and what signals completion? An arbitrary sleep is a weak substitute. Record a timeout as an unmet observation or failure according to the agreed contract, with diagnostic evidence; do not silently stretch it until the test passes.

05. Add precision where timing changes the question

TC-016-03 requires more than “click at the same time”. Human clicks and two requests launched close together do not guarantee that the relevant server operations overlap.

An authorised harness might use a coordinated start plus instrumentation around the contested decision or commit boundary. The exact arrangement depends on the architecture.

Document its limits: a synchronised client start may increase the chance of overlap without proving it occurred at the vulnerable boundary. OWASP's process-timing guidance treats execution timing between processes as an application-specific business-logic testing concern.

For our healthy, controlled experiment under A1–A3:

1. Reset the fixture and verify that S-100 has no allocations.

2. Prepare one eligible request for P-A and one for P-B, with distinct correlation identifiers.

3. Release the attempts using the agreed coordination method and retain timing evidence.

4. Wait for both attempts to reach a defined completion state. An inconclusive response needs investigation, not an assumed rejection.

5. Compare both responses with the authoritative allocation state.

The safety invariant is at most one successful allocation for S-100. Under the separate normal-success assumptions of this experiment, expect one successful booking and one appropriate losing outcome.

If both attempts fail, double allocation may have been avoided, but the normal-success expectation has not been demonstrated. A safety assertion alone would miss that difference.

Retain the winner's identity, allocation identifier, each response, and evidence that the tested overlap was achieved. Do not always expect P-A to win: the order of legitimate concurrent winners is not defined by B3.

Repeat with fresh state and varied scheduling when the risk warrants it. Ten clean runs are evidence about those executions, not proof that every possible interleaving is safe.

Investigate the allocation mechanism with engineering as well; an external test need not reveal every internal race.

06. Use concrete data without inventing a policy

Issue 015 introduced illustrative W1: a booking is permitted when the slot starts at least 24 hours after the server's booking-decision time, measured in UTC at one-second precision. W1 was not an agreed requirement inherited from Issue 014.

Suppose the controlled decision time is 2030-01-10 10:00:00 UTC. All other eligibility conditions are held valid. For this teaching experiment, the controlled clock must govern the actual decision, not just the browser display.

Case	Slot start UTC	Lead time	Expected under W1
TC-016-05	2030-01-11 09:59:59	23:59:59	Reject as too soon.
TC-016-06	2030-01-11 10:00:00	24:00:00	Permit booking if other conditions hold.
TC-016-07	2030-01-11 10:00:01	24:00:01	Permit booking if other conditions hold.

Use a fresh available slot for each case. Otherwise, TC-016-06 could book the slot that TC-016-07 later needs, turning a time-boundary investigation into an accidental availability check.

This small family demonstrates parameterisation: the procedure stays similar while the values and expected outcome change. It does not cover every time-related risk.

Local-time presentation, daylight-saving transitions, timestamp precision, and clock skew need their own scope decisions where relevant. Issue 017 will develop equivalence partitioning and boundary value analysis in depth.

The discipline is to state which variable changes, which conditions remain fixed, and what rule justifies each expected result.

07. Do not confuse a format with a level of detail

Some teams keep scenarios in a spreadsheet and detailed cases in a test-management tool. Others express concrete examples in Gherkin or code. The storage format does not determine whether the investigation is well designed.

Cucumber uses Scenario as a synonym for Example; its Given, When, and Then steps describe context, an event, and an outcome. A Scenario Outline runs a parameterised example for each data row. This is why a Gherkin “Scenario” can be much more concrete than the broad coverage scenario used in this series.

For our stale-slot example, an original behavioural outline could read:

Feature: Protect a selected appointment from double allocation
  Scenario: Another patient books the selected slot first
    Given P-B selected S-100 while it was available
    And P-A has since completed a booking for S-100
    When P-B submits the earlier selection
    Then P-B is informed that S-100 is unavailable
    And S-100 has exactly one allocation, belonging to P-A

This is illustrative Gherkin, not delivered automation. Step definitions, fixture creation, observation bounds, and the agreed feedback contract are still needed. Executable syntax does not resolve an ambiguous requirement, and a step called “the booking is correct” would simply conceal that ambiguity.

For browser automation, Playwright recommends isolated tests and user-facing locators; its web-first assertions retry while waiting for an expected condition. Those facilities can support implementation, but they cannot decide which outcome is right.

A locator for a confirmation message checks the interface. An allocation query checks a different observation. Choose each because the case needs that evidence, with authorised access and privacy controls, rather than because the tool makes it convenient.

08. Choose documentation depth through risk and reuse

Detailed cases are valuable when another person must reproduce an investigation, data, or sequencing is consequential, evidence must be reviewed, or checks will be repeated across changes. They are especially useful when a vague procedure could produce a reassuring but misleading result.

Detail also has a maintenance cost. Document the behavioural contract, essential data, and evidence more durably than incidental screen coordinates or a volatile CSS class. Link reusable setup instructions to a controlled version so that a change cannot silently alter what an old result meant.

A concise scenario can be enough to begin a discussion or guide experienced exploration of a low-risk change. It is not automatically enough for repeatable execution. For exploratory testing, a time-bounded charter, relevant data, session notes, and retained observations can provide a more suitable record than pretending every action was scripted in advance.

Manual versus automated is a separate decision from scenario versus case. A human can execute a detailed case. An automated check can implement a poorly specified case. Some investigations need controlled service-level coordination; others need a person to examine language, recovery guidance, or usability.

For the booking example, keep the broad risk discussion, use precise cases for allocation and timing, and retain exploratory room for how the patient understands an uncertain outcome. One form of evidence does not make the others redundant.

09. Keep decisions, execution, and coverage separate

The editable case register accompanying this article deliberately separates a design from its execution status. The cases are not run. TC-016-04 remains decision-blocked; its omission from an executable set must remain visible.

Case ID	Scenario or basis	Deliberate condition	Expected result or decision	Design status	Execution status	Decision owner
TC-016-01	S02; B3–B4	Single eligible reservation; fresh slot	One allocation and agreed confirmation; confirmation definition pending	Illustrative; local adoption pending	Not run	Product Owner
TC-016-02	S03/S04; B3/B5	P-B selects; P-A books; P-B submits	One allocation for P-A; no P-B allocation; agree feedback contract	Illustrative; feedback decision pending	Not run	Product Owner
TC-016-03	S04; B3; A1–A3	Overlapping eligible requests; verified timing	At most one allocation; healthy experiment expects one winner; correlate outcomes	Illustrative; harness/completion decisions pending	Not run	Engineering Lead / Product Owner
TC-016-04	S05; R2	Commit succeeds; response lost	Recovery/status/retry oracle unresolved	Decision blocked	Not run	Product Owner
TC-016-05	S09; illustrative W1	Decision 2030-01-10 10:00:00 UTC; fresh slot next day 09:59:59	Reject under W1; not adopted real-world requirement	Illustrative; W1 adoption pending	Not run	Product Owner
TC-016-06	S09; illustrative W1	Same controlled decision time; fresh slot next day 10:00:00	Permit under W1 if other conditions hold	Illustrative; W1 adoption pending	Not run	Product Owner
TC-016-07	S09; illustrative W1	Same controlled decision time; fresh slot next day 10:00:01	Permit under W1 if other conditions hold	Illustrative; W1 adoption pending	Not run	Product Owner

Case or scope	Missing decision or dependency	Suggested accountable owner
TC-016-01 to TC-016-03	Confirmation meaning, losing feedback and observable completion.	Product Owner, with engineering and QE.
TC-016-03	Coordination and observation facilities; evidence of overlap.	Engineering Lead, with QE.
TC-016-04	Status lookup, retry semantics and recovery after lost responses.	Product Owner, with Engineering Lead.
TC-016-05 to TC-016-07	Whether W1 is adopted; precision and decision-clock control.	Product Owner, with policy and engineering.

These are illustrative role assignments, not appointments to a real delivery team. The QE records the decision source, version, owner, and date, then revisits affected cases.

Figure 2. A case becomes evidence through a recorded execution. A changed rule can require design revision, and a new run; an old pass does not verify the changed behaviour.

Traceability supports change analysis and connects the test basis with testware and results. Exhaustive testing is generally impractical; linking every requirement to a case does not establish that important risks were selected or investigated.

Suppose six of seven selected cases are designed, and four have passed. Reporting “six covered” hides whether coverage means designed, implemented, executed, or passed.

Reporting “four passed” still needs the case versions, environment, and remaining gaps. A blocked recovery decision may matter more than several straightforward passes.

A useful status statement would say: “The selected stale-slot and controlled boundary checks passed in the stated environment. Overlap was not demonstrated in the concurrency run, and recovery behaviour remains undecided. The results do not establish concurrent-allocation safety or safe retry.”

This is an illustrative report, not a claim that these cases have been executed.

10. Review the investigation before approving the case

Ask a colleague to explain what defect the case could expose. Then ask what could go wrong while every assertion still passes.

If the answer is “two records might exist even though one request failed”, the allocation observation is too weak. If the answer is “the second request may not overlap the first”, the timing evidence is insufficient. If the answer is “we do not know whether a retry should return an existing booking”, the expected result needs a decision.

Before execution, check that the case has a defensible purpose, an identifiable test basis, controlled preconditions, discriminating data, meaningful expected results, an observation route, and a clean-up strategy. Make unresolved decisions visible. Afterwards, retain actual results and evidence against the version that was run; do not overwrite them with the next revision's expectations.

Good test design connects three things: the question worth asking, a method capable of investigating it, and evidence strong enough to support the conclusion.

Scenarios keep us focused on the first. Detailed cases help make the second repeatable. Quality Engineering judgement is what keeps both honest about the third.

About the author

Amber Idumwonyi is a senior Quality Engineering leader and founder of LEMP. Her work spans enterprise software delivery, UK public-sector technology programmes, test strategy, automation, accessibility, governance, and technology workforce development. Amber Insights shares practical Quality Engineering knowledge for technology professionals and those developing their skills.

Read More:

• Amber Insights | Issue 013 – User Stories Explained: What Quality Engineers Need to Look Beyond

• Amber Insights | Issue 014 –  Acceptance Criteria: Turning Business Expectations into Testable Outcomes

• Amber Insights | Issue 015 –  From Requirements to Test Scenarios: How Quality Engineers Build Meaningful Coverage

• Explore LEMP's Software Testing programme and learn how you can get started.