What a test scenario is, how it differs from a test case and test script, how to write scenarios from requirements and user stories, examples by feature, and a free test scenario template in Excel, Word, and PDF.
A test scenario is a one-line description of a feature or user journey to verify, written from the user's point of view: it says what to test, not how. Before a release, a team lists them for login, search, cart, checkout, and saved cards, and for what should happen when things go wrong.
This guide covers what a test scenario is, how it differs from a test case and a test script, how to write scenarios from requirements and user stories, and examples by feature. You can also download a free test scenario template in Excel, Word, or PDF, with 15 filled example scenarios.
What is a test scenario?
For example, a login scenario for an online store reads "Check that a registered shopper can log in with a valid email and password." Each scenario is then broken into test cases with steps, data, and expected results.
More examples:
- Login: check that a registered user can log in with valid credentials.
- Payment: check that a payment goes through when a user enters valid card details.
- File upload: check that a user can upload a file under the maximum size limit without errors.
Good test scenarios share 3 traits:
- High-level: they name the goal and leave steps, data, and clicks to the test cases.
- User-focused: they describe what a user or stakeholder needs to do, in their language.
- Action-oriented: each one names a specific user action and the result the system should give.
Scenarios sit in the middle of the testing documents. A test plan sets the scope and approach for a release, test scenarios list what to verify, test cases say how to verify each condition, and test scripts automate the stable cases.
Test scenario vs test case vs test script
Aspect | Test scenario | Test case | Test script |
|---|---|---|---|
Core question | What to test | How to test one condition | How a tool runs the test case |
Level of detail | One line, no steps or data | Preconditions, steps, test data, expected result | Code with actions and assertions |
Source | Requirements, user stories, business rules, risks | Derived from a scenario | Derived from a stable test case |
Primary use | Coverage planning and agreement with stakeholders | Repeatable execution and evidence | Unattended runs, often in CI |
Usually written by | Test leads and testers, reviewed with product and dev | Testers | Automation engineers or testers who automate |
Relationship | 1 scenario covers several cases | 1 case checks 1 condition | Some cases become scripts |
Maintenance | Low: changes when the requirement changes | Medium: changes when the UI or flow changes | Higher: changes with code, locators, and data |
Example | Check user login | TC-LOGIN-002: Log in with a valid email and a wrong password; the error message appears and the user isn't logged in | A script that enters the email and wrong password, selects Log in, and asserts the error text |
Put simply, a test scenario is broader than a test case. One scenario usually becomes several test cases, and the stable, frequently run ones can become scripts. For the anatomy of a full case, see how to write test cases, and for the automation layer, see how to write a test script.
One scenario, four test cases: login
Test scenario: check that a registered shopper can log in to the online store.
- TC-LOGIN-001: log in with a valid email and password; the account page opens.
- TC-LOGIN-002: log in with a valid email and a wrong password; an error message appears and the user isn't logged in.
- TC-LOGIN-003: log in with an email that isn't registered; the same "Email or password is incorrect" message appears.
- TC-LOGIN-004: fail to log in 5 times in a row; the account locks for 15 minutes (illustrative values from the store's security rules).
TC-LOGIN-002 written as a short test case: open the login page, enter a registered email and a wrong password, select Log in. Expected result: the message "Email or password is incorrect" appears and the shopper stays on the login page. Ready-made layouts for full cases are in our test case template.
Two rules of thumb help keep the levels apart:
- If a "scenario" contains test data (specific emails, passwords, card numbers) or click steps, it's really a test case. Business rules such as a lockout limit can stay in the scenario.
- If a "scenario" can't be checked in one test session, it's really an epic. Split it into smaller scenarios.
In theory the two terms are distinct. In practice, many teams use "test scenario" and "test case" interchangeably, so agree on the definitions with your team before you build a template around them.
When a scenario is enough on its own
Not every scenario needs detailed test cases. A list of scenarios can be enough for exploratory testing sessions, early sprint planning, and user acceptance testing checklists, where the tester or business user decides the steps. Write full cases when a check must be repeatable, auditable, or automated.
Why test scenarios matter
- Coverage you can see: a scenario list shows at a glance which requirements have tests and which don't.
- Earlier agreement: product owners, developers, and testers can review one-line scenarios before anyone writes steps.
- Faster planning: scenarios let a team size the testing effort for a release before detailed cases exist.
- Less duplication: grouping cases under scenarios makes overlapping cases easier to spot.
- A clear path to automation: high-priority scenarios with stable cases are the natural first candidates for test scripts.
Types of test scenarios
- Positive: the happy path works. Check that a shopper can complete checkout with a valid card.
- Negative: the system handles invalid input or state. Check that a declined card shows a clear error and no order is placed.
- Edge: behavior at limits and unusual conditions. Check that an expired saved card is flagged and can't be used to pay. Edge scenarios often come from boundary value analysis.
- End-to-end: a journey across modules. Check that a shopper can search, add an item to the cart, pay, and get an order confirmation. See end-to-end testing and integration testing for how these runs are planned.
How to write test scenarios step by step
The steps below use one running example: the checkout feature of an online store.
1. Understand the requirement
Read the business requirements, acceptance criteria, and known risks for the feature. For checkout, that includes card payment, guest checkout, promo codes, and what happens when a payment fails.
2. Write from the user's perspective
Describe what the user is trying to do, not what the system does internally. Instead of "Authenticate payment", write "Check that a logged-in shopper can complete checkout with a card and gets an order confirmation."
3. Cover positive, negative, and edge paths
For each user goal, add at least one scenario for what should fail. For checkout: a declined card, an expired promo code, and a payment that times out.
4. Group scenarios by module
Keep related scenarios together so they're easy to review and assign. For example, group login, registration, and password reset under "User authentication", and card payment, guest checkout, and promo codes under "Checkout".
5. Link each scenario to its requirement
Give each scenario an ID and the ID of the requirement or user story it covers, such as SC-CHK-01 for US-130. That link is what lets you spot requirements with no scenario. A traceability matrix does the same at a larger scale.
6. Prioritize by risk, then review
Rate each scenario by business impact and how often the feature changes. High-impact, frequently changed scenarios get detailed test cases, and later automation, first. Then review the list with the product owner and a developer (the "three amigos") and keep the wording short and plain.
Checklist for writing test scenarios
- Is it high-level? Does the scenario say what to test rather than how?
- Is it user-focused? Does it describe a user action or goal?
- Does it cover positive and negative paths? Have you included what should fail?
- Is it simple? Can a non-technical stakeholder understand it?
- Is it complete? Does every requirement in scope have at least one scenario?
- Is it grouped logically? Are related scenarios in the same module?
How to write test scenarios from user stories
User stories and their acceptance criteria are the most direct source of scenarios. Take this story from the online store:
User story US-130: As a shopper, I want to pay for my order by card so that I can complete my purchase.
Acceptance criteria:
- A logged-in shopper can pay with a valid card and gets an order confirmation.
- A guest shopper can check out without creating an account.
- A declined card shows a clear error and no order is placed.
Each criterion becomes at least one scenario, and you add the scenarios the criteria don't mention, such as selecting Pay twice:
ID | Test scenario | Type |
|---|---|---|
SC-CHK-01 | Check that a logged-in shopper can complete checkout with a card and gets an order confirmation | Positive |
SC-CHK-02 | Check that a guest shopper can check out without creating an account | Positive |
SC-CHK-03 | Check that a declined card shows a clear error and no order is placed | Negative |
SC-CHK-05 | Check that selecting Pay twice doesn't create two orders or two charges | Edge |
SC-CHK-04 (expired promo code) comes from a different story, US-131, and appears in the full example below. SC-CHK-05 is the scenario the criteria didn't mention.
In BDD testing, the same criterion is written as a Gherkin scenario with Given, When, And, and Then statements. Here is SC-CHK-01 for placing an online order:
- Given a logged-in shopper has 2 items in the cart
- When the shopper goes to checkout and enters a valid card
- And the shopper selects Pay
- Then an order confirmation page shows the order number
- And the cart is empty
BDD scenario vs test scenario
A Gherkin scenario is step-level and often executable, so it sits closer to a test case. A test scenario is a planning-level line. One test scenario can be expanded into several Gherkin scenarios, one for each path.
Test scenario examples: an online store
These 15 scenarios cover login, search, cart, checkout, and saved cards for one release. They are the same 15 scenarios as the Example sheet in the free template, and the values are illustrative.
ID | Feature | Test scenario | Type | Priority |
|---|---|---|---|---|
SC-LOGIN-01 | Login | Check that a registered shopper can log in with a valid email and password | Positive | High |
SC-LOGIN-02 | Login | Check that login fails with a wrong password or an unregistered email | Negative | High |
SC-LOGIN-03 | Login | Check that the account locks after 5 failed attempts and unlocks after 15 minutes | Edge | Medium |
SC-SEARCH-01 | Search | Check that a keyword search returns matching products sorted by relevance | Positive | High |
SC-SEARCH-02 | Search | Check that a search with no matches shows an empty state with suggestions | Negative | Medium |
SC-SEARCH-03 | Search | Check that price, brand, and rating filters narrow the results and can be cleared | Positive | Medium |
SC-CART-01 | Cart | Check that a shopper can add items, change quantities, and remove items, and the cart total updates | Positive | High |
SC-CART-02 | Cart | Check that a shopper can't add more units than are in stock | Negative | Medium |
SC-CART-03 | Cart | Check that the cart keeps its items after the shopper logs out and logs in on another device | Edge | Medium |
SC-CHK-01 | Checkout | Check that a logged-in shopper can complete checkout with a card and gets an order confirmation | Positive | High |
SC-CHK-02 | Checkout | Check that a guest shopper can check out without creating an account | Positive | High |
SC-CHK-03 | Checkout | Check that a declined card shows a clear error and no order is placed | Negative | High |
SC-CHK-04 | Checkout | Check that an expired promo code is rejected and the order total doesn't change | Negative | Low |
SC-CARD-01 | Saved cards | Check that a shopper can save a card at checkout and reuse it on the next order | Positive | High |
SC-CARD-02 | Saved cards | Check that an expired saved card is flagged and can't be used to pay | Edge | Medium |
In the template, two of these are marked "Not covered": the cross-device cart (SC-CART-03) and the expired saved card (SC-CARD-02). That's the coverage check at work: both scenarios exist, but no test cases cover them yet. For more login rows, see our test cases for a login page.
Test scenario examples by feature
More scenarios for features most web and mobile apps share. Each feature has a positive, a negative, and an edge row.
Feature | Positive | Negative | Edge |
|---|---|---|---|
Registration | Check that a new user can register with a valid email and password and gets a confirmation email | Check that registering with an email already in use shows an error and links to login | Check that a password at the minimum and maximum allowed length is accepted |
Password reset | Check that a user can reset the password from the emailed link | Check that a reset link can't be used a second time | Check that a reset link stops working after it expires |
Passkey login | Check that a user can sign in with a registered passkey | Check that sign-in falls back to password or another method when no passkey is available on the device | Check that a passkey removed from the account can no longer be used to sign in |
Two-factor login | Check that a user can log in with a valid one-time code | Check that a wrong or reused code is rejected | Check that a code entered after it expires is rejected and a new one can be requested |
File upload | Check that a user can upload a supported file under the size limit | Check that an unsupported file type is rejected with a clear message | Check that a file just over the size limit is rejected with a clear message |
API (orders) | Check that a valid request with a valid token creates an order | Check that a request with a missing or expired token returns an authorization error | Check that a request over the rate limit is refused with a retry message |
Mobile app | Check that a shopper can complete checkout on a phone | Check that losing the network during payment shows an error and doesn't create an order | Check that rotating the screen mid-checkout keeps the form data |
For a wider look at manual checks like these, see our manual testing guide.
Download the test scenario template
The template is free and ungated. Pick the format that fits how your team works:
Format | Best for | Download |
|---|---|---|
Excel (.xlsx) | Filtering, sorting, and tracking coverage across many scenarios. | |
Word (.docx) | A scenario document for review or sign-off | |
Printing or sharing a read-only copy |
What's in the files:
- Excel: 2 sheets. "Template" is blank, with header fields (project name, release or version, features in scope, prepared by, date) and 50 empty rows. "Example" holds the 15 online store scenarios above, linked to user stories US-101 to US-140 and to test case IDs such as TC-LOGIN-001 and TC-CHK-004.
- Excel extras: drop-downs for Type (Positive, Negative, Edge), Priority (High, Medium, Low), and Status (Draft, Ready, Covered, Not covered), a frozen header row and Scenario ID column, filters, and print settings for A4 landscape.
- Word and PDF: the blank template on page 1 (header fields and a 10-column table with 10 empty rows), then the same online store example. Instead of drop-downs, they include a legend of the same values.
Test scenario template fields
All three files use the same 10 columns:
Field | What to write | Example |
|---|---|---|
Scenario ID | A unique ID with a module prefix | SC-CHK-03 |
Module / feature | The area of the product | Checkout |
Requirement or user story | The ID and short text of what the scenario covers | US-130: As a shopper, I can pay for my order by card |
Test scenario | One line, starting with "Check that" | Check that a declined card shows a clear error and no order is placed |
Type | Positive, Negative, or Edge | Negative |
Priority | High, Medium, or Low, by business impact and risk | High |
Linked test cases | The IDs of the cases that cover the scenario | TC-CHK-004 |
Status | Draft, Ready, Covered, or Not covered | Ready |
Owner | Who writes and maintains the scenario | Tester A |
Notes | Dependencies, test data, or open questions | Use the payment provider's test decline card |
How to write test scenarios in Excel
- Fill the header fields: project name, release or version, features in scope, prepared by, and date.
- Add one row per scenario, with an ID and the requirement or user story it covers.
- Set Type, Priority, and Status from the drop-downs, and add the linked test case IDs as you write the cases.
- Filter on Status "Not covered" or an empty Linked test cases column before each release to find gaps.
Need full test cases with steps and expected results? Use the test case template linked above.
Best practices for writing test scenarios
- Start every scenario with a verb. "Check that..." keeps scenarios testable and consistent.
- One goal per scenario. If a scenario needs "and" to join two separate user goals, split it. Two expected results of the same action are fine.
- Keep test data out of scenarios. Specific values such as card numbers and emails belong in the test cases. Business rules such as a lockout limit can stay.
- Link scenarios to requirements and cases. Without those links, you can't tell what's covered.
- Prioritize by risk. Spend the most detail on high-impact, frequently changed features.
- Include negative and edge paths for every feature, not only the happy path.
- Review scenarios when requirements change. Update or retire scenarios in the same sprint as the story change.
- Treat AI-drafted scenarios as drafts. If you ask an AI assistant to draft scenarios from a user story, check the output for duplicates, scenarios that are really cases, missing negative paths, and requirements the story doesn't contain.
Managing test scenarios in a test management tool
A spreadsheet works for one release and a few testers. Once you have hundreds of scenarios, several testers, and requirements that change every sprint, keeping IDs, links, and statuses current by hand gets hard. That's the point where teams move to test case management in a dedicated tool; our list of test management tools compares the options.
In Katalon TestOps, one way to map a scenario is as a manual test suite that groups its test cases. Each manual test case has steps with a description, expected results, and test data, and can call other test cases. A manual test run picks suites or cases, an executor, and a target configuration, then runs in TestPak (Run Manually) or with Run with AI, which pauses when it needs human input.
TestOps also connects to Jira: it syncs projects, releases, requirements, and defects from Jira, and you can report a defect to Jira from a failed result. Once a Jira or Azure DevOps requirement is synced, Katalon AI can generate draft manual test cases from it. The team reviews, edits, and saves them, and each saved case stays linked to the requirement.
Frequently asked questions
A test plan sets the scope, approach, schedule, and resources for a release. Test scenarios list what to verify within that scope, one line per user goal. A plan usually points to the scenario list rather than containing it.
No. A test case is a written check that a person can run. A test script is code that runs that check automatically. Teams usually script only the stable, frequently run cases.
It depends on risk and complexity. A simple scenario may need 2 or 3 cases (one positive and one or two negative), while a high-risk scenario such as payment often needs more to cover boundaries and failure states.
Usually test leads or testers. Product owners and developers often review them against the acceptance criteria, the "three amigos" approach, so everyone agrees on what will be tested.
A test condition is a single item or event that can be verified, such as "the password field rejects fewer than 8 characters". A test scenario groups the conditions for one user goal, such as "Check that a user can register".
A test scenario describes what to verify. A test suite is a set of test cases grouped to run together, often one suite per scenario or module.
AI assistants can draft scenarios from a user story or its acceptance criteria. Treat the output as a draft: remove duplicates, turn step-level items into test cases, add the negative and edge paths it missed, and drop anything the story doesn't contain.
Not quite. Scenario testing is a technique that tests realistic, end-to-end stories of how people use the product. Test scenarios are the planning items that any testing technique can use, scripted or exploratory.
-768x512.png)
Test everything. Ship with confidence.
From generating test cases to spotting failures, Katalon's AI works across your entire pipeline, automatically.
