Test scenario
A test scenario is a one-line statement of something a user does with the system that has to work, written from the user's side and independent of how it is checked. It names the situation to be tested, not the steps: 'a returning customer checks out with a saved card' is a scenario, and the concrete inputs, steps and expected results that verify it are test cases.
The longer version
A scenario is the unit a tester derives from a requirement, a user story or an acceptance criterion before any steps exist. It answers what a user could be trying to do here and lists those situations: sign in with a wrong password, sign in with an expired session, sign in from a second device. Each line is short enough to review with a product owner who has never opened a test case, and that is the point. The scenario list is the artefact the whole team can agree is complete, and the place where a missing situation is cheapest to notice.
The confusion is with the test case. A case is the executable version of a scenario: a precondition, ordered steps, specific data and an expected result somebody can mark passed or failed. One scenario usually expands into several cases, because checkout with a saved card has to be checked with a card that is valid, one that has expired and one the issuer declines. The scenario stays stable while the cases under it change with the interface. Writing steps into the scenario itself produces a case with a vague name.
A scenario written as a feature, 'test the checkout', is too wide to run: nobody can say which situations ran or what a pass proved. A scenario written from the implementation, 'test that the submit handler validates the card field', follows the code rather than the user, and a redesign invalidates the whole list. A scenario is well formed when a product owner can read it and say whether it describes something that matters.
Scenario lists are written once a requirement is understood well enough to test and before the build is finished, then reviewed against the acceptance criteria to find the situations the criteria forgot. During a run the scenario is the row in the results, and a failed scenario is what gets filed as a bug, with the failing case attached as its steps to reproduce.
Common questions
What is the difference between a test scenario and a test case?
A scenario names a situation worth testing, in one line, from the user's side: a returning customer checks out with a saved card. A test case is the executable check for it: precondition, ordered steps, exact data and the expected result. One scenario usually expands into several cases, and the scenario stays stable while the cases change with the interface.
Who writes test scenarios?
Usually a tester or QA lead, working from the requirement, the user story or the acceptance criteria, and reviewing the list with the product owner before any cases are written. The review is the reason the format is so short: a scenario is brief enough for somebody who has never opened a test case to say whether a situation is missing.
How many test scenarios does a feature need?
As many as there are distinct situations a user can be in when they reach the feature, which is a property of the feature rather than a target. A sign-in form with a password, a magic link and a locked-account state has at least those three plus their failures. A list that fits on one screen gets reviewed; a list that does not gets skimmed.
Can test scenarios be automated?
A scenario is a statement of intent, and intent cannot be executed. What gets automated is the test cases derived from it, each with concrete steps and data. The scenario stays in the scenario list as the row the automated cases report against, so a run can say which situations passed rather than which scripts did.
What does a good test scenario look like?
A good test scenario is one line, written from the user's side, naming a situation rather than a step: a returning customer checks out with a saved card, a guest uploads a file over the size limit. A product owner who has never opened a test case can read it and say whether it matters, and a tester can derive several cases from it without asking what it meant.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.