Test Scenario vs Test Case: 15 Worked Examples with Test Cases

Last updated 2026-11-04 · 15 min read · By SoftwareTestPilot

Quick answer: a test scenario is one line that says what behaviour to check, such as "a shopper applies an expired coupon at checkout". A test case is one runnable check under that scenario, with the exact setup, data and expected result. One scenario usually becomes several test cases: the normal path, the failure paths and the edge cases.

This page is a catalogue of worked examples. Each of the 15 examples below shows the scenario, why a team would care about it, and the test cases a tester would write from it. If you want the definitions, comparison table and templates first, start with our test scenario vs test case explained guide, then come back here to practise.

Key takeaways

• A scenario names a behaviour; a test case proves one path through it.
• Most scenarios expand into 3 to 6 cases: at least one positive, one negative and one edge case.
• Good test cases state concrete data and a result you can see, not "should work correctly".
• Track coverage against scenarios and execution against test cases.

Every example uses the same layout so you can compare them:

• Scenario — one sentence, written from the user's or system's point of view. No steps, no data.
• Why it matters — the risk if this behaviour breaks. This is what decides the scenario's priority.
• Test cases — each row is one case: the setup and data that make it different from its neighbours, and the result you would check.
• Tester's note — the case people most often forget, or a design technique that helped.

The cases are written in short form to keep the page readable. In a real test management tool each row would also carry an ID, preconditions, numbered steps and a priority. Our test case template guide shows the full layout.

The business rules in these examples (limits, timings, messages) are illustrative. Always take the real values from your product's requirements or acceptance criteria.

Example 1: Adding an out-of-stock item to the cart

Scenario: A shopper tries to add a product that has no stock left.

Why it matters: Selling stock you do not have leads to cancelled orders and refunds.

Tester's note: TC-02 and TC-03 are the cases that catch real bugs, because they involve timing. They are easy to skip when you only test the product page.

Example 2: Shipping to a country the store does not serve

Scenario: A shopper enters a delivery address in a country the store cannot ship to.

Why it matters: Accepting the order creates a payment the business must refund by hand.

Tester's note: TC-03 checks that the rule applies to the right field. Mixing up billing and shipping rules is a common defect.

Example 3: Using a gift card and a coupon together

Scenario: A shopper pays with a gift card and also applies a discount coupon.

Why it matters: Wrong order of calculation gives away money or overcharges customers.

Tester's note: Write down the expected calculation order before testing. Without it, two testers can 'pass' opposite results.

Example 4: Transfer above the daily limit

Scenario: A customer tries to send more money in one day than their daily transfer limit allows.

Why it matters: Limits protect customers from fraud; a gap here is a security and compliance issue.

Tester's note: TC-01 and TC-02 come from boundary value analysis. TC-04 tests what 'daily' actually means.

Example 5: Login after repeated wrong passwords

Scenario: A user enters the wrong password several times in a row.

Why it matters: Lockout stops password guessing, but a broken rule can lock out real customers.

Tester's note: TC-03 is a security case: the error message must not reveal whether the password was correct.

Example 6: Downloading a statement for a closed account

Scenario: A customer requests an old statement for an account they have closed.

Why it matters: Regulations often require old statements to stay available after closure.

Tester's note: Ask what the retention rule is before writing TC-01. The answer usually comes from compliance, not the product team.

Example 7: Downgrading a plan in the middle of a billing cycle

Scenario: A customer moves from a higher plan to a lower one partway through the month.

Why it matters: Billing errors are visible to customers and hurt trust quickly.

Tester's note: Get a written example invoice from the product owner. It turns a vague rule into numbers you can check.

Example 8: Inviting a user beyond the seat limit

Scenario: An admin invites a new team member when all paid seats are used.

Why it matters: Seat limits drive revenue; letting extra users in for free is a real loss.

Tester's note: TC-04 is where requirements are often silent. Raise the question before release, not after.

Example 9: Single sign-on with a mixed-case email address

Scenario: A user signs in through their company's single sign-on with an email that has capital letters.

Why it matters: Duplicate accounts and failed logins are common support tickets.

Tester's note: Emails are a classic source of duplicate data. Always include a case that changes only the letter case.

Example 10: Hitting the API rate limit

Scenario: A client application sends more API requests per minute than its plan allows.

Why it matters: Rate limits protect the service for everyone; clients need a clear signal to slow down.

Tester's note: You can practise exactly these checks against a live practice API in our API Playground.

Example 11: Trial expiring at midnight in another time zone

Scenario: A user in Sydney reaches the end of a 14-day free trial.

Why it matters: Ending a trial early or late annoys customers and affects revenue.

Tester's note: Time zones and daylight saving are among the most common causes of date bugs. Pick test dates that cross a clock change.

Example 12: Leaving the app while entering a one-time code

Scenario: A user switches to their messages app to read a one-time password, then returns.

Why it matters: If the screen resets, users cannot finish signing in.

Tester's note: Run these on a real device as well as an emulator. Background behaviour differs.

Example 13: Opening a link from an email while signed out

Scenario: A signed-out user taps a link in an email that points to a page inside the app.

Why it matters: Broken links waste the email and lose the user.

Tester's note: TC-01 checks that the original destination survives the sign-in step, which is easy to lose.

Example 14: Denying notification permission, then allowing it later

Scenario: A user refuses notification permission at first launch, then enables it from settings.

Why it matters: Notifications drive return visits; a stuck permission state loses them silently.

Tester's note: Write these for both Android and iOS separately; the permission flows are different.

Example 15: Exporting personal data on request

Scenario: A user asks to download all the personal data the service holds about them.

Why it matters: Data protection laws such as the GDPR give people a right to a copy of their data.

Tester's note: TC-02 is a security case. Every export or download feature needs one check that a different user cannot open the file.

A simple table linking scenarios to cases makes gaps easy to spot. Each scenario row lists its case IDs, so a scenario with only one case stands out straight away.

Scenario ID | Scenario                              | Cases               | Priority | Automated
SC-004      | Transfer above the daily limit        | TC-041 to TC-044    | High     | TC-041, TC-042
SC-008      | Invite beyond the seat limit          | TC-081 to TC-084    | High     | No
SC-013      | Open email link while signed out      | TC-131 to TC-133    | Medium   | TC-131

Add a column for the requirement or user story ID and the table becomes a basic traceability matrix: you can show which requirement each test covers.

Use these five steps on any feature. They are how the 15 examples above were written.

1. Write the scenario as one sentence about behaviour. Start from a user story or acceptance criterion. Leave out steps and data.
2. Ask "what would make this go wrong?" List wrong inputs, missing permissions, limits, timing and interruptions.
3. Use a design technique for the data. Boundary values for limits, equivalence partitions for input groups, and a decision table when several rules combine (as in Example 3).
4. Write one case per distinct condition. If two cases have the same setup and the same expected result, merge them.
5. Make each expected result observable. "Order total is 900" can be checked. "Discount works" cannot.

Teams that use behaviour-driven development write the same thing in Given/When/Then form. A scenario becomes a Gherkin Scenario or Scenario Outline, and each row of the examples table is effectively a test case. See the official Gherkin reference and our BDD with Cucumber tutorial.

• Scenarios that are really test cases. "Enter 50,001 and click Send" is a case. The scenario is "transfer above the daily limit".
• Only the happy path. If a scenario has one case, it almost always lacks negative and edge coverage.
• Vague expected results. "System behaves correctly" gives two testers two answers.
• Hidden data. "Use a valid account" does not say which one. Name the data or the setup.
• Scenarios that are too big. "Checkout works" covers dozens of behaviours. Split it until each scenario has a handful of cases.
• Guessing business rules. When a limit or timing is not written down, ask. Do not invent the expected result.

For more on writing the case itself, see test case writing best practices.

Interviewers usually ask the definition, then hand you a feature. A strong answer has three parts:

1. Define both in one breath. "A test scenario is a one-line statement of what to check. A test case is one runnable check under it, with setup, data and an expected result."
2. Give a real example. Pick one from this page, for instance the daily transfer limit, and name two or three cases including a boundary.
3. Explain how you use them. "I track coverage against scenarios so I can see what behaviour is tested, and execution against cases so I can see what passed today."

If asked to write cases on the spot, say the scenario out loud first, then work through positive, negative and edge cases in that order. That structure shows method, not memory. More practice questions are on our manual testing interview questions page, and you can ask other testers for feedback in the QA Community.

For standard definitions, the ISTQB glossary is the reference most interviewers recognise.

A scenario says what to test; a test case says exactly how, with data and an expected result. Across these 15 examples, the cases that matter most are rarely the normal path. They are the limits, the timing problems, the permission checks and the questions the requirements forgot to answer. Pick one feature you work on this week, write its scenarios in one line each, and expand one of them into four cases using the five steps above.