Few questions in testing generate as much debate as “what’s the difference between a test scenario and a test case?” The honest answer is subtle: the two concepts sit at different levels of abstraction in the testing process, and the terms are used loosely in the industry. This article gives you the official definitions, a concrete worked example, and clear guidance on when to write each.
The official ISTQB definitions first
Start with what the glossary actually says, because both terms are formally defined — and one of them is not what most people expect.
A test case is the most concrete unit of testing: exact inputs in, expected result out. It is what a tester (or an automated framework) actually executes, step by step, and it is built from test conditions — the testable aspects of the system that test analysis identifies.
Test scenario — in the ISTQB glossary, this is a synonym for test procedure specification: a document specifying a sequence of actions for the execution of a test. Also known as test script or manual test script.
This is the key insight most articles miss: formally, “test scenario” is not a first-class testing phase — it is the ISTQB name of the document that sequences actions for executing tests. In everyday QA language, though, the word is used much more loosely to mean “a high-level description of a user flow or capability that we want to verify.” That industry sense is broad and business-flavored; the formal sense is narrow and document-flavored. Both are worth knowing, and the confusion comes from mixing them.
What a test case actually contains
Because a test case is the executable unit, it has a fixed structure. From the definition, every test case carries four or five pieces:
- Preconditions — the state that must hold before you can run it (a user exists, you are on the login page, the session is empty)
- Inputs — the concrete values you feed in (username
jdoe, passwordS3cret!) - Actions (where applicable) — the steps you perform (click “Sign in”)
- Expected results — the observable, predicted outcome based on the test basis
- Postconditions — the state that should hold after it completes (the session is created; the dashboard is shown)
Without the expected result — the counterpart verified against an independent test oracle — a test case is not verifiable and you cannot tell a pass from an inconclusive run. The expected result is what turns an action into a test.
What a test scenario / procedure specifies
A test scenario (procedure specification) is the sequence: it orders multiple test cases into the flow you would actually execute, and includes the setup and wrap-up actions around them. Where a test case answers “given this input, what output?", a scenario answers “in what order do I run the cases, and what must I do before and after, so the whole flow makes sense?”
It is a document — readable by people, including business stakeholders — not just a list of runnable steps.
A worked example: the checkout flow
Let’s make it concrete with an e-commerce checkout. Here are the levels, from the coarsest to the finest grain.
1. Test scenario (the flow you want to prove):
“Guest checkout with a discount code completes successfully.”
That’s one sentence. It names a capability and an outcome, it is understandable to product and business people, and it does not say how to test it. This is the industry sense of a test scenario. To execute it you must unfold it into specific conditions and cases.
2. Test conditions (the testable aspects the flow touches):
- Adding an item to the cart
- Applying a valid 10% discount code
- Entering a shipping address
- Making a payment with a valid card
- Order confirmation screen
These come from test analysis of the requirement and the test basis. Each condition can be verified by one or more test cases.
3. Test cases (the executable units under each condition):
Taking the “valid 10% discount code” condition, you might design these cases:
| Test case | Precondition | Input | Expected result |
|---|---|---|---|
| TC-01 Apply valid code | Cart has an item; checkout page open | Code SAVE10 | 10% deducted; message “Discount applied” shown |
| TC-02 Apply expired code | Same as above | Code SAVE10 (expired) | Error message; no discount applied |
| TC-03 Apply code with minimum-spend not met | Cart total below €50 threshold | Code SAVE50EMIN | Error explaining threshold; discount not applied |
Three cases, one condition. Now the scenario / procedure organises them in execution order and adds the glue:
Pre-step: open the site and add an item to the cart. Run TC-01, TC-03, TC-02 (in an order that makes sense — for example, the happy path first, then the valid-but-failing, then the outright invalid). Post-step: verify the confirmation screen and the final total.
This is the exact relationship: a scenario is broader and spans several test cases; each test case is a single, concrete, executable check.
Side-by-side comparison
| Test scenario (industry sense) / test procedure specification (formal) | Test case | |
|---|---|---|
| Level of abstraction | Broad, flow-level, user-capability | Narrow, unit-level, executable |
| Answer the question | “What user flow or capability should work?” | “Given this exact input, what exact output?” |
| Audience | Business, product, and QA reviewers | Testers executing and automation code |
| Granularity | One flow → spawns several cases | Fixed structure: preconditions, inputs, actions, expected + postconditions |
| Formal ISTQB status | Synonym of test procedure specification | First-class glossary term |
| Verifiable on its own? | No — needs unfolding into cases | Yes — has an expected result |
| Typical output | A document / charted flow | A row in a test case management tool or an automated spec |
When to use each (best practice)
Use test scenarios when you are thinking about coverage at the user or system level: capturing real, end-to-end usage that stakeholders can review, designing user acceptance testing, or planning what the suite must prove before you write the fine-grained steps. Scenarios make great test charters for exploratory testing too, because they point the tester at the journey without over-specifying.
Use test cases when you need everything explicit and reproducible: regression suites, boundary and input validation, automated tests, and anything where an expected result must be compared against test execution output. Automation requires the test-case level — a script implements the inputs, preconditions, expected results, and postconditions programmatically.
The practical workflow is top-down: start with scenarios to agree what to cover, then derive test conditions, then design test cases for each condition using test techniques such as equivalence partitioning and boundary value analysis (that is the test design activity). Keep traceability between requirement, condition, and case so you can prove coverage and defend a release decision.
Common traps
“Test scenario” as a word has two meanings. Be explicit which one you mean. If you say “scenario” but you’ve written step-by-step executable instructions, call it a procedure or a script. If you say “scenario” but you’ve only named a flow without stating expected outcomes, it is a coverage idea, not a runnable test — keep it as a charter, and be honest that it is not yet executable.
A test case without an expected result is not a test. It will produce “actual results” you cannot judge. Pair it with a test oracle so the expected result is an independent prediction, not just whatever the last run happened to output.
Don’t collapse the levels. Writing “one scenario = one test case” hides risk: a single flow can exercise many conditions, and each condition can need many cases (valid, invalid, boundary). Collapsing into a single case-per-flow is a classic cause of under-coverage and of bugs that escape because a subsystem was never really exercised.
FAQ
Is a test scenario the same as a test script? Overlapping, not identical. Formally, the test scenario definition notes it is also known as test script or manual test script. In practice “test script” leans toward the automated form of a test procedure, while “scenario” leans toward the manual, sequence-of-actions form.
Can one test case belong to several scenarios? Yes. A case verifies a specific condition; that condition can appear in multiple flows. Reusing well-designed cases across scenarios is normal and a sign of good decomposition — you test the condition once, not once per journey.
Which do I write first? Scenarios, almost always. Agree the flows and coverage with stakeholders first (cheap to review, catches misunderstandings about what the system should do), then design the cases. Writing cases before the scenarios exist tends to over-invest in details you might discard.
Is a scenario the same as a use case? No. A use case describes how an actor interacts with a system to achieve a goal — a requirements artifact. A test scenario (procedure specification) is a testing artifact that sequences actions for the execution of a test. Use cases are a common source of scenario steps, but the two live in different documents and serve different phases.
Related terms
- test condition — the testable aspects a scenario’s flow touches and cases are built from
- test case — the executable unit: preconditions, inputs, actions, expected results, postconditions
- test design — the activity that derives and specifies test cases from test conditions
- test procedure — a sequence of test cases in execution order plus setup/wrap-up actions
- test procedure specification — the formal term for which “test scenario” is a synonym
- test script — the alternative, often automated, name for a scenario/procedure
- expected result — the predicted outcome that makes a test case verifiable
- test execution — running the test on the system and producing actual results
- test oracle — the independent source that gives you the expected result to compare against
- traceability — how you prove requirement → condition → case coverage
- test technique — the procedures (equivalence partitioning, boundary value analysis) you use to design the cases
- exploratory testing — a context where scenarios serve as test charters rather than scripts
Editorial metadata: first-party article · written by Adam Hepner, September 24, 2026 · pending editorial review before publication. Definitions quoted from the issue’s source glossary entries (test case, test scenario).
