| name | scenario |
| description | Design real-world test scenarios — user journeys, role-based flows, recovery paths — independent of execution tool (pytest, Playwright, Postman, etc.). |
| category | Testing & Debug |
| status | active |
Scenario
Purpose
Scenario-based testing is a design discipline: enumerate the real-world workflows a system must support and the failure paths it must survive, then express them as runnable test cases. Tool-agnostic.
Distinct from [[test-automation]] — how to run tests: runners, Playwright/browser patterns, CI integration. That skill is the single testing toolkit; this one decides which cases exist.
When to Use
- Greenfield feature: derive test set from requirements before implementation
- Regression triage: turn a bug report into a permanent scenario
- Acceptance testing for a release
- Role-based features (admin vs user vs guest)
- Recovery testing (network failures, retries, partial state)
Activation phrases: "design test scenarios for...", "create user-flow tests", "recovery scenarios for...", "acceptance criteria as scenarios"
Scenario Types
| Type | Question it answers |
|---|
| System / golden-path | Does the main user journey work end-to-end? |
| Role-based | Does each persona see the right capabilities and data? |
| Negative | What happens when input is invalid, missing, malicious? |
| Recovery / failover | What happens when a dependency fails mid-flow? |
| Data-driven | Does the system behave correctly across input variations? |
| Boundary | Off-by-one, empty set, max size, expiry edges |
A balanced suite covers every type. A suite that's 100% golden-path is theatre.
Design Process
- Extract actors — who triggers this flow? (user, admin, system job, external webhook)
- Map the happy path — every step from trigger to completion, including state changes.
- Branch the unhappy paths — at each step, ask: "what could go wrong?" → distinct scenario.
- Enumerate roles — repeat the happy path per role; note diverging behavior.
- Add boundaries — for any input with a numeric range, add min, max, min-1, max+1.
- Add recovery — for any external call, add a scenario where it times out or returns 5xx.
Scenario Template
### Scenario: <name>
**Type**: golden | role | negative | recovery | data | boundary
**Actor**: <persona>
**Preconditions**: <state before>
**Steps**:
1. ...
2. ...
**Expected**: <observable outcome>
**Cleanup**: <state after>
Tool Mapping (pick by layer)
| Layer | Tool examples | Notes |
|---|
| Unit / integration | pytest, JUnit, Vitest | See [[test-automation]] |
| API | Postman, curl, supertest, httpx | Express scenarios as request sequences |
| Browser / UI | Playwright, Cypress | See [[test-automation]] |
| End-to-end | Playwright + Postman + DB seeders | Compose layers per scenario |
The scenario itself is the same markdown spec — only the execution tool changes.
Anti-Patterns
- Scenario inflation: 200 near-duplicate scenarios. Fix: parameterize via data-driven scenarios.
- No cleanup: tests pollute each other. Fix: every scenario declares state pre/post.
- Golden-path-only suite: gives false confidence. Fix: require at least 1 negative + 1 recovery per feature.
- Implementation-coupled scenarios: "click button X" instead of "submit form". Fix: write at user-intent level; let the executor map to UI.
References
See references/:
browserstack-test-scenarios-2025.md — modern methodologygeeksforgeeks-scenario-testing.md — definition + canonical examplestestsigma-test-scenario-guide.md — best practices, positive/negative
Cross-links
[[test-automation]], [[tdd]], [[debugging]]
