Test Case vs Test Scenario vs Test Plan: Differences With Examples

“What’s the difference between a test case and a test scenario?” is one of the most common questions in QA and manual testing interviews, and the terms get mixed up on real teams too. The good news is that they fit together neatly, from the big picture down to the single click. This guide explains each one with an example, shows a simple template for each, and gives you an interview-ready answer.

The short answer: these four documents go from broad to detailed:

1. Test strategy: the overall approach to testing, often for a whole organisation or product. “We automate regression, test APIs on every commit and do exploratory testing before each release.”
2. Test plan: how testing will be done for one project or release: scope, approach, schedule, people, environments, risks and exit criteria.
3. Test scenario: a one-line description of something to test. “Verify a user can reset their password.”
4. Test case: the detailed, step-by-step check under a scenario, with preconditions, test data, steps and an expected result.

Think of it as a trip: the strategy is how your family usually travels, the plan is this holiday’s itinerary, a scenario is “visit the museum”, and a test case is the exact directions to get there.

Test case vs test scenario vs test plan at a glance

	Test plan	Test scenario	Test case
What it answers	How will we test this release?	What should we test?	Exactly how do we test it?
Level of detail	High level, whole project	One line per feature or flow	Step by step
Typical size	A document of several pages	One sentence	A short table of steps
Written by	QA lead or test manager	Testers, often with product input	Testers
Written when	Before testing starts	During requirement analysis	During test design
Example	“Test plan for checkout redesign v2.3”	“Verify user can apply a discount code”	“Apply a valid 10% code to a $50 cart; total shows $45”

What is a test scenario?

A test scenario is a short statement of something that needs to be tested, usually a user goal or a piece of functionality. It describes what, not how.

Examples for an online shop

• Verify a user can search for a product by name.
• Verify a user can add a product to the cart.
• Verify a user can apply a discount code at checkout.
• Verify a user can pay with a saved card.
• Verify a user receives an order confirmation email.

Why scenarios are useful

• Coverage at a glance: a list of scenarios shows quickly whether every important flow is covered.
• Easy to review: product owners and developers can check them without reading detailed steps.
• Fast to write: useful in Agile teams where requirements change quickly.
• A starting point: each scenario later becomes several test cases.

Many teams map scenarios directly to user stories and acceptance criteria.

What is a test case?

A test case is a specific set of conditions, inputs, steps and expected results used to check one aspect of a scenario. It’s detailed enough that someone else could run it and get the same answer.

Components of a test case

Field	Example
Test case ID	TC_DISC_003
Title	Apply an expired discount code
Related requirement or scenario	Verify a user can apply a discount code
Preconditions	User is logged in; cart contains one item costing $50; code SUMMER10 expired yesterday
Test data	Code: SUMMER10
Steps	1. Go to checkout. 2. Enter SUMMER10 in the discount field. 3. Click Apply.
Expected result	Message “This code has expired” appears; cart total stays $50
Actual result	(filled in when run)
Status	Pass / Fail / Blocked
Priority	Medium

Several test cases from one scenario

For the scenario “Verify a user can apply a discount code”, test cases might include:

1. Apply a valid percentage code; total reduces correctly.
2. Apply a valid fixed-amount code; total reduces correctly.
3. Apply an expired code; clear error, no discount.
4. Apply an invalid code; clear error.
5. Apply a code below the minimum order value; error explains the minimum.
6. Apply two codes when only one is allowed; second is rejected.
7. Enter the code in lowercase; it’s accepted if codes aren’t case-sensitive.
8. Remove an applied code; total returns to the original price.

That’s how one line becomes eight precise checks. Techniques like boundary value analysis and equivalence partitioning help you choose which cases matter; we cover them in our top QA interview questions.

Tips for writing good test cases

• One check per test case, so a failure points to one problem.
• Clear, specific titles that say what’s being tested.
• Exact expected results. “Works correctly” isn’t testable; “$45.00 shown as total” is.
• Include test data so anyone can repeat it.
• Write for someone new to the product. If they can’t run it without asking you, add detail.
• Link to the requirement so you can see coverage and update tests when requirements change.

What is a test plan?

A test plan describes how testing will be carried out for a particular project or release. It aligns the team on what will be tested, how, by whom and when, and what “done” looks like.

What goes in a test plan

1. Introduction and objectives: what the release is and what testing aims to achieve.
2. Scope: features in scope and, just as important, out of scope.
3. Test approach: types of testing (functional, regression, API, performance, accessibility), manual vs automated.
4. Test environment: devices, browsers, test data, test accounts.
5. Entry criteria: conditions to start testing, such as “build deployed to staging and smoke tests pass”.
6. Exit criteria: conditions to finish, such as “all high-priority test cases run, no open critical bugs”.
7. Schedule and milestones.
8. Roles and responsibilities.
9. Risks and mitigations: “payment provider sandbox is unstable; we’ll reserve two extra days”.
10. Deliverables: test cases, bug reports, a test summary report.

A common reference for test plan structure is the IEEE 829 standard (since replaced by ISO/IEC/IEEE 29119), though most teams use a lighter version.

A short test plan example

Test plan: checkout redesign, release 2.3

Scope: new checkout page, discount codes, saved cards. Out of scope: account settings and the mobile app.

Approach: manual functional testing of new flows; automated regression of existing checkout tests; API tests for the discount service; accessibility check with a screen reader.

Environments: staging; Chrome, Safari and Firefox on desktop; Chrome on Android and Safari on iPhone.

Entry criteria: all stories marked dev-complete; smoke tests pass on staging.

Exit criteria: 100% of high-priority test cases executed, 95% passing; no open critical or high bugs.

Schedule: testing 4–13 November; release 15 November.

Risks: payment sandbox downtime (mitigation: mock payment responses for functional tests).

In Agile teams, test plans are often shorter and live in a wiki page or the sprint board, but the same questions still need answers.

What is a test strategy?

A test strategy sits above the test plan. It describes how the organisation or product approaches testing in general: which levels and types of testing are used, automation goals, tools, defect management, environments and quality standards. It changes rarely. Each project’s test plan follows the strategy and fills in the specifics.

	Test strategy	Test plan
Scope	Organisation or product	One project or release
Changes	Rarely	Every project
Content	General approach, standards, tools	Specific scope, dates, people, risks
Written by	QA manager or head of quality	QA lead for the project

Other related documents

• Test suite: a group of related test cases, such as “checkout regression suite”.
• Test script: usually an automated test written in code, though some teams use the term for detailed manual steps.
• Test data: the inputs and accounts needed to run tests.
• Requirements traceability matrix: a table mapping each requirement to its test cases.
• Test summary report: written at the end, summarising what was tested, results, open bugs and a recommendation.
• Bug report: documents a failed test case so a developer can reproduce and fix it.

Positive, negative and edge-case test cases

A common follow-up interview question is “what kinds of test cases would you write for this scenario?” Group them into three types.

Type	What it checks	Example for “user can sign up with email”
Positive	The feature works with valid input	Valid email and strong password create an account
Negative	The feature handles invalid input gracefully	Email without “@”; password too short; email already registered
Edge case	Behaviour at the limits	Password exactly at the minimum length; email with a plus sign; very long name; leading spaces

Strong candidates mention all three without being prompted. Most real bugs are found in the negative and edge-case groups, because developers usually test the happy path themselves.

Test cases in Agile teams

In Agile teams with two-week sprints, the classic heavy documents get lighter, but the ideas stay:

• The test plan often becomes a short page per release or epic, or a section in the team’s definition of done.
• Test scenarios usually map to user stories and their acceptance criteria. Many teams write acceptance criteria in a Given-When-Then format that doubles as scenarios:

Given a logged-in user with $50 in their cart, When they apply the valid code SAVE10, Then the total shows $45 and the code appears under “Applied discounts”.

• Test cases are written for risky or complex stories, and the stable ones are automated and added to the regression suite.
• Exploratory testing sessions cover what scripted test cases miss.

Knowing how these documents adapt to Agile shows interviewers you’ve worked on real teams, not just studied definitions.

How to answer this in a QA interview

Question: “What’s the difference between a test case and a test scenario?”

Sample answer: “A test scenario is a high-level statement of what to test, usually one line, like ‘verify a user can reset their password’. A test case is the detailed check under it, with preconditions, test data, steps and an expected result, like ‘request a reset with a registered email and confirm the link arrives within two minutes and expires after one use’. One scenario usually has several test cases covering valid, invalid and edge-case inputs. Above both sits the test plan, which describes scope, approach, schedule and exit criteria for the whole release.”

That answer defines both terms, gives an example, shows how they relate and mentions the test plan, which is often the follow-up question.

For more practice, see our manual testing interview questions and what is software testing.

Common mistakes

• Writing scenarios that are really test cases, with steps and data, which makes them hard to review.
• Writing test cases that are really scenarios, with no steps or expected results, which makes them impossible to repeat.
• Vague expected results like “page works”.
• Skipping negative and edge cases. Most bugs live there.
• A test plan nobody reads. Keep it short enough to be useful.
• Not updating tests when requirements change, so they slowly stop matching the product.

Show this on your QA resume

Hiring managers want evidence you can design tests, not just run them. Bullet points like “Designed 180 test cases across 24 scenarios for a checkout redesign; found 31 defects before release, including 4 critical payment bugs” are far stronger than “Responsible for testing”.

Different QA listings stress different things: one wants test design and Jira, another wants API testing and automation. Tailr is a Chrome extension that tailors your resume to the job listing you’re viewing, writes a matching cover letter and tracks the application, so the right experience leads each time.

Try Tailr

Conclusion

A test strategy sets the general approach, a test plan applies it to one release, a test scenario names something to test, and a test case spells out exactly how to test it. Scenarios give coverage at a glance; test cases make testing repeatable; the plan keeps the whole team aligned. Learn one example of each and you’ll answer this classic QA interview question with confidence.