Scenario
A single plain-language description of how a product behaves in a specific situation. The atomic unit of a Specsight spec.
A scenario describes one specific behaviour of a product: a starting state, something that happens, and how the product responds. Scenarios aren't features, requirements, or test cases. They are statements of behaviour that anyone on the team can read and verify by using the product.
Each scenario has three parts: a Context (the situation), an Action (what triggers it), and an Outcome (how the product responds). Scenarios are grouped into three categories: happy path (the expected flow), edge case (unusual but valid situations that users often find surprising), and error (what happens when things go wrong).
Together, scenarios build up a complete picture of a feature's behaviour. A feature with only happy path scenarios leaves your support team unprepared for everything else. Good specifications cover edge cases and errors too, the places customers actually run into problems.
Example
- CONTEXT
A user's trial has expired
- ACTION
They attempt to access a premium feature
- OUTCOME
They are shown an upgrade prompt and cannot access the feature
Related terms
- SPEC
Context, Action, Outcome
A structured format for describing product behaviour. Precise enough to be unambiguous, plain enough for anyone on the team to read, without the machine-oriented syntax of BDD.
- SPEC
Happy Path
A scenario that describes the expected, successful flow of a feature: what happens when everything goes right and the user stays on the main track.
- SPEC
Edge Case
A scenario that describes unusual but valid behaviour, the conditions at the edges of what the feature supports. Often the source of support tickets.
- SPEC
Error Scenario
A scenario that describes how the product responds when something goes wrong: invalid input, failed validations, blocked actions, or system-level failures.