Glossary · Testing fundamentals
Test scenario
Also called: test scenarios
Definition
A high-level statement of a user goal or functionality to test, such as "verify checkout with a saved card", which is later broken down into test cases.
A test scenario describes what to test, not how. It is usually one line that names a user goal or a piece of functionality, written from the user’s point of view. Scenarios are quick to write and review, which makes them a good way to agree on coverage with product and development before investing in detailed test cases.
Example
For a password reset feature, the scenarios might be:
- Verify a registered user can reset their password via the emailed link.
- Verify a reset request for an unregistered email does not reveal whether the account exists.
- Verify an expired reset link is rejected.
- Verify a reset link cannot be used twice.
- Verify the new password must meet the password policy.
Scenario 3 then becomes several test cases with concrete data: a link used 1 minute before expiry, exactly at expiry, and 1 minute after; a link with a tampered token.
Scenario vs test case
| Test scenario | Test case | |
|---|---|---|
| Level | High: what to test | Detailed: how to test it |
| Content | One-line goal | Preconditions, data, steps, expected result |
| Count | Few per feature | Several per scenario |
| Best for | Coverage reviews, fast-moving projects | Execution, automation, audit |
Scenario in BDD
In Gherkin, a Scenario: is closer to a test case than to a test scenario in the traditional sense, because it contains concrete steps and examples. When someone says “scenario”, check which meaning they intend.
Common mistakes
- Writing steps instead of goals. “Click the reset button” is a step, not a scenario.
- Only happy paths. Negative, boundary and security scenarios (like number 2 above) are where most defects hide.
- Skipping the review. The main value of scenarios is that non-testers can read them and spot missing cases early.