·
8 min
Test scenario vs test case: the difference, the ISTQB view and a banking example
Roman Kirchmeier - Autemos
A test scenario describes a business flow you want to check, such as “create and approve a standing order”. A test case fixes the preconditions, inputs and expected results for one variant of that flow, and one scenario usually groups several of them. The official ISTQB glossary has no entry for “test scenario” (checked on 27 September 2026). The 2025 Advanced Test Analyst syllabus covers scenario-based testing with main, extension and exception scenarios. Banks have DORA on top: Art. 25(1) names scenario-based tests as one appropriate test type. For single test case anatomy, see our guide to the test case in ISTQB terms.
TL;DR: A test scenario is a business flow; a test case is one concrete check with inputs and an expected result. The CTAL-TA 4.0 syllabus splits scenarios into main, extension and exception (ISTQB CTAL-TA v4.0, 2025). Automate a few business-critical scenarios and many small test cases.
Figure 1: Test scenario and test case at a glance
What is the difference between a test scenario and a test case?
A scenario answers “Which flow do we check?”, and a test case answers “With which data and which expected result do we check one variant of it?”. The scenario is the coarser unit and sits close to the user story. The test case is finer, repeatable and ends with a clear verdict: pass or fail.
Criterion | Test scenario | Test case |
|---|---|---|
Level | Business flow, close to a story or process | Concrete check of one variant |
ISTQB status | Not a glossary term; CTAL-TA 4.0 teaches scenario-based testing | Glossary term (version 2) |
Content | Goal, actors, sequence of steps | Preconditions, inputs, actions, expected results, postconditions |
Quantity | A few per feature | Several per scenario |
Example | “Create a standing order and have a second person approve it” | “A start date in the past is rejected with an error message” |
Coverage | Executed divided by identified scenarios | Depends on the technique, such as equivalence partitions or boundary values |
Automation | Longer flow across several systems and roles | Short, targeted check, often at API or component level |
The two artifacts need each other. Without test cases, a scenario doesn't say which amounts, dates or roles get checked. Without a scenario, test cases don't show whether an approved payment reaches the core banking system.
What is a test scenario?
A test scenario describes a realistic flow through a system and links several test cases into one coherent business story. The term comes from practice. In the official ISTQB glossary, the lookup returns “Term not found” (ISTQB Glossary, 2026).
Older German glossary versions listed “Testszenario” as a synonym of test procedure specification, a document that sets out a sequence of actions for running a test (GTB glossary 3.21, 2019).
Cem Kaner gives a practical working definition: a scenario is a hypothetical story that helps a person think through a complex problem or system (Kaner, An Introduction to Scenario Testing, 2003). A good one, in his view, has five traits:
It tells a story with an actor, a goal and a flow.
It's motivating: a stakeholder would take a failure in it seriously.
It's credible and could happen in real operation.
It's complex and combines several functions or data.
It's easy to evaluate.
Agile teams meet the word in BDD: the CTFL syllabus names a “Scenario-oriented (e.g., Given/When/Then format used in BDD…)” format for acceptance criteria (ISTQB CTFL v4.0.1, 2024). A Gherkin scenario like that checks a single example, which puts it closer to a test case. Read more on writing testable acceptance criteria and behavior-driven development.
Where do scenarios and test cases sit in the ISTQB hierarchy?
The ISTQB chain runs from test basis through test condition, test case and test procedure to test suite. The scenario has no slot of its own and covers the stretch from test condition to test procedure. Per the Foundation syllabus, analysis produces test conditions, design produces test cases, and implementation produces procedures, scripts and suites (ISTQB CTFL v4.0.1, 2024).
Figure 2: Where the test scenario sits in the ISTQB chain
Test basis: user story, process description or regulatory requirement.
Test condition: “A testable aspect of a component or system that is intended to be tested.” (ISTQB Glossary, 2026). Per CTFL §4.5.2, acceptance criteria can be viewed as test conditions.
Test case: preconditions, inputs, actions, expected results and postconditions, “developed based on test conditions” (ISTQB Glossary, 2026).
Test procedure: “A sequence of test cases in execution order” plus the setup and wrap-up actions around it (ISTQB Glossary, 2026, after ISO 29119-1).
Test suite: the procedures and scripts that run together.
The scenario shows up twice in this chain. In design, it tells you which test conditions belong together. In implementation, it becomes a test procedure; automated, it corresponds to a test script.
Many pages still quote an outdated test case wording from an unofficial glossary copy; the current version 2 says “developed based on test conditions” (test case guide).
How does the ISTQB syllabus treat scenario-based testing?
ISTQB teaches scenario-based testing in the Advanced Test Analyst syllabus (CTAL-TA 4.0, released 2 May 2025), after Foundation 4.0 dropped use case testing. The syllabus sums it up: “Scenario-based testing evaluates the test item's behavior in realistic scenarios.” (ISTQB CTAL-TA v4.0, 2025)
It starts from a scenario model: sequences of actions forming workflows through the test item, following ISO/IEC/IEEE 29119-4 (2021). The syllabus names activity diagrams and use cases as models. A use case holds three scenario types:
Main scenario (“happy path”): the standard route to the goal.
Extension (alternative scenario): a deviation from the main route.
Exception: a sequence in which an unexpected action, such as invalid input, prevents the goal of the main scenario.
Coverage is executed scenarios divided by all identified scenarios: identify four, run three, and you reach 75 percent. Test coverage in practice explains how it differs from code coverage. For simple loops, the syllabus lists four passes: zero times, once, a typical number and the maximum.
How do you turn a banking process into a test scenario with test cases?
A banking process becomes testable in five steps: read the test basis, derive test conditions, name the scenarios, write the test cases and build one automated flow. The example is a standing order in e-banking for a business account that needs two signatures.
Figure 3: Main, extension and exception scenarios in the standing order example
Test basis: the user story reads “As a bookkeeper, I want to set up a monthly standing order so that the office rent is paid on time.” The acceptance criteria: amounts above the single-signature limit need approval from a second authorized signatory, the start date is not in the past, the IBAN is valid.
Test conditions: each acceptance criterion becomes a test condition, plus “a valid order is saved and active”.
Scenarios: main “set up below the limit”. Extension “set up above the limit with approval by a second person”. Exceptions “invalid start date”, “invalid IBAN” and “approval rejected”.
Test cases: at least one with fixed data per scenario, shown in the table.
Automated flow: the extension becomes one automated test across two user sessions and an API check.
ID | Scenario type | Precondition and input | Expected result |
|---|---|---|---|
TC-01 | Main scenario | CHF 1,850, monthly on the 1st, starts next month, valid IBAN, single limit CHF 5,000 | Order saved, status “active” |
TC-02 | Extension | CHF 12,000, otherwise as TC-01 | Status “pending approval”, then “active” after the second person approves |
TC-03 | Exception | Start date yesterday, otherwise valid | Error message at the date field, no order saved |
TC-04 | Exception | IBAN with a wrong check digit, otherwise valid | Error message at the IBAN field, no order saved |
TC-05 | Exception | As TC-02, second person rejects | Status “rejected”, the creator sees the status |
TC-03 and TC-04 each check exactly one invalid input. That follows the German syllabus 4.0.2. It added a rule that invalid equivalence partitions should not be combined in one test case, so one defect can't hide another (ISTQB CTFL Lehrplan 4.0.2, 2025). More patterns: negative testing in software.
TC-02, the full approval route, is the strongest candidate for UI automation. Session A (the bookkeeper in a browser) creates the order, an API call checks “pending approval”, session B (the approver in the mobile app) approves, and session A sees “active”. TC-03 and TC-04 run faster as short tests at form or API level.
What does DORA mean by scenario-based tests?
DORA requires financial entities to run a digital operational resilience testing programme, and Art. 25(1) names scenario-based tests and E2E testing as examples of appropriate tests. The regulation has applied since 17 January 2025 (Regulation (EU) 2022/2554, 2022). Art. 25(1) names, among others:
vulnerability assessments and scans
source code reviews where feasible
scenario-based tests
compatibility testing
performance testing
E2E testing
penetration testing
Art. 9(4)(e) covers the change side: change management policies cover how changes to ICT systems are “recorded, tested, assessed, approved, implemented and verified in a controlled manner”. A small set of stable business regression scenarios gives you traceable results for every change; Autemos records test changes in an audit trail.
“Scenario” has a second meaning in banking supervision. In TIBER-EU, the ECB framework for threat-intelligence-based red teaming, scenarios describe attacks (ECB, TIBER-EU, 2026). Functional scenarios check whether a business process runs correctly; attack scenarios check whether someone can abuse it. The two need different teams and tools.
How many E2E scenarios should you automate?
Automate through the UI only the scenarios whose failure would hurt the business, and check the variants as smaller test cases below the UI. Every long flow has more points where a test can fail without a code defect. As of 2016, Google reported that about 1.5% of test runs returned a flaky result. Almost 16% of its tests showed some flakiness (Google Testing Blog, 2016).
Figure 4: Flaky tests at Google, as of 2016. 84% of pass-to-fail transitions involved a flaky test.
The same source adds: “about 84% of the transitions we observe from pass to fail involve a flaky test”. A red run then says little about the code. The first large empirical study of flaky tests covered 201 fix commits in 51 open-source projects (Luo et al., FSE, 2014).
As a rule of thumb, Google suggested in 2015 a split of 70% unit tests, 20% integration tests and 10% E2E tests (Google Testing Blog, 2015). Google gave it as guidance, without measured data behind it. Our guide to E2E testing explains how to cut and maintain long flows.
Autemos is an AI-assisted test automation platform for web, mobile, API and desktop. One visual test workflow can span several browsers, devices, API calls and user sessions, which matches a banking scenario with a creator and an approver. Business users build the flow by drag and drop; engineers add code blocks or embed existing Playwright tests. See visual test workflows.
When a locator changes, Autemos repairs it through self-healing, and every heal is documented and reversible. Autemos flags one-time-use test data so parallel runs don't reuse it. With an unstable test environment, fewer and tighter UI scenarios mean fewer runs that go red for reasons unrelated to the code.
Frequently asked questions
Is “test scenario” an ISTQB term?
No, the official ISTQB glossary has no entry for “test scenario” (checked on 27 September 2026). The closest terms are test condition and test procedure. Scenario-based testing has been in the CTAL-TA 4.0 syllabus since 2025.
How many test cases belong to one scenario?
There's no fixed number; each identified main, extension and exception scenario needs at least one test case. Variants from equivalence partitions and boundary values come on top. In the example above, five scenarios produce five test cases; boundary values around the single-signature limit would add more.
Is a Gherkin scenario the same as a test scenario?
Usually not: a Gherkin scenario describes one concrete example in Given/When/Then form, which puts it closer to a test case. Several Gherkin scenarios together can cover one business scenario.
What is scenario coverage?
Scenario coverage is executed scenarios divided by all identified scenarios, as defined in CTAL-TA 4.0 (2025). It says nothing about code or requirements coverage.
Can Autemos automate test scenarios?
Yes, Autemos automates test scenarios as visual test workflows across web, mobile, API and desktop, including flows across several user sessions. The AI Recorder drafts a workflow from a Jira ticket or a plain-text test case; your team approves every step before it runs. Load and security testing aren't included.
Conclusion
Test scenario and test case are two levels of the same work. The scenario states which business flow has to work, and the test case checks one variant with fixed data and an expected result. Only the test case is an ISTQB glossary term; scenario-based testing sits in CTAL-TA 4.0. For banks, DORA Art. 25(1) names scenario-based tests as one appropriate test type. Keep UI scenarios few and business-critical, and check variants below the UI, so a red run still points to a real defect. To see a two-session approval scenario as a visual workflow, book a demo with the Autemos team.
