Test case vs test scenario vs checklist
A test scenario says what to test: one user's path through a business process, such as "a customer buys two kettles with a coupon and pays by card". A checklist lists short checks for one area of the product, one line each, with a status per run and no steps. A test case says exactly how to run one check: preconditions, numbered steps with real data, and an expected result for each step. One scenario usually gives several checks, and most teams keep checklists and test cases side by side.
- 3 documents
- what each one is for
- 1 feature
- written all three ways
- 7 situations
- and which document fits each
From a scenario to checklists and cases, step by step
- Step 1
Write the scenario in one sentence
Name the user, the goal and the path: who does what, with which data. Take it from the story; if the business process is unclear, ask the analyst.
- Step 2
Split the path into areas
Cart, coupon, checkout, payment. Each area gets its own group of checks, so that a failure points at one place.
- Step 3
List the checks for each area
One line per check, named by the action and the data: "Apply expired coupon WINTER10". Positive checks first, then every invalid value on a line of its own.
- Step 4
Choose which checks become test cases
Business rules, regression checks and anything a new person will run alone become cases. Quick visual checks stay on the list.
- Step 5
Write the cases
Preconditions as a state, steps with the exact labels and values, an expected result after each step.
Open - Step 6
Link everything to the story
Put the story ID on the checklist and on each case. When the story changes, you see at once what to update.
What a test scenario is
A test scenario is a user's path through a business process that covers several checks. "A signed-in customer puts two Steel kettle 1.7 l in the cart, applies coupon SAVE25 and pays by card" is a scenario. It says what to test and in which order, and leaves out the details of each check.
The word comes from job ads and team practice rather than from the standard testing glossary, which has no entry for it. Teams use it differently: for some it is one line, for others a short story with a few steps. Ask what your team means by it before you write the first one.
One more meaning causes confusion. In Gherkin, the Given, When, Then format, the keyword Scenario names one concrete example with its own data and expected outcome. That is much closer to a test case than to the one-line scenario of a test plan.
What a checklist is
A checklist is a list of short checks for one area of the product, without steps. It works like a shopping list: each item is a check, and the tick is its status in this run, such as Passed, Failed or Skipped. A spreadsheet is enough to keep one.
A usable checklist has a header (application, build, environment, tester, date), checks grouped by module, and a status column for each run. One status column per browser keeps one list for all of them instead of a copy per browser. An expected result column is optional.
Each item names an action and its data. "Coupon field" says what you touch, not what you check. Every invalid value gets its own line: an item "Apply a wrong, expired or empty code" that fails does not say which input broke.
What a test case is
A test case is one check written out so that anyone can run it and reach the same verdict. It has a title that names what is checked and with which data, preconditions that describe a state, numbered steps with exact values and on-screen labels, an expected result for each step, and postconditions. It has no actual result: each run records Passed or Failed.
A case costs more to write than a checklist line and pays it back when the same check is run many times by different people, or when someone has to prove later what exactly was tested.
Side by side
The three documents differ in how much they say and in what they are for. Read the table by rows: each row is one question you can ask of any test document.
Scenario Checklist Test case
Answers what to test what to check exactly how
Covers a user's path one area one check
Steps none or a few none numbered, with data
Expected result the path's goal optional one per step
Status none of its own per item and run per run
Best for planning and early stages, business rules,
coverage talks quick passes, regression, new
changing specs people, auditsOne feature, written three ways
Shelf is the practice shop the courses use. Its cart has a "Coupon code" field with an "Apply" button. Two coupons exist: SAVE25 takes USD 25.00 off a cart of 1 to 10 items, and WINTER10 expired on 28 February 2026. The Steel kettle 1.7 l costs USD 24.00 and ships free, so two of them make a subtotal of USD 48.00.
Below is the same coupon feature as a scenario, as one module of a checklist and as one test case. The scenario fits in two lines and will give checks in several areas. The checklist covers the coupon in six lines that take a few minutes to run. The test case spends seven lines on one of those checks, and anyone can repeat it with the same result.
Scenario A signed-in customer buys 2 × Steel kettle 1.7 l with coupon SAVE25 and pays with a test card. Checklist: Shelf web 1.4.2, cart, module Coupon (status per browser) Apply SAVE25 to 2 × Steel kettle 1.7 l (USD 48.00): total USD 23.00 Apply save25 in lower case Apply expired coupon WINTER10 Apply unknown code SAVE30 Apply with an empty Coupon code Remove an applied coupon with "Remove" Test case Title: Apply expired coupon WINTER10 in the cart Preconditions: Signed in. The cart holds 1 × Steel kettle 1.7 l. 1. Open /cart -> the cart with 1 × Steel kettle 1.7 l 2. Enter WINTER10 in Coupon code -> no message 3. Select Apply -> "Coupon WINTER10 expired on 28 Feb 2026." Postconditions: The cart still holds 1 × Steel kettle 1.7 l; no coupon is applied.
When to use which
The choice depends on how stable the product is, who runs the checks and what the results are for. Most projects use checklists and test cases together, often for the same feature at different times: a checklist while the feature changes, cases once it settles.
Requirements still change
A checklist. Cases written now would be rewritten next week.
A quick pass over a screen
A checklist. Labels, layout and simple inputs need no steps.
Complex business rules
Test cases. Discounts, payments and order states need exact data and an expected result per step.
Regression before every release
Test cases. The same check must give the same verdict every time, whoever runs it.
A new tester runs it alone
Test cases. A checklist assumes you already know the product.
An audit or a client asks for proof
Test cases with their run results, linked to the requirements.
Planning what to cover
Scenarios. They show which user paths are covered before anyone writes a step.
Common mistakes
Most of these come from mixing up the three documents: giving one the job of another, or copying one instead of writing it for the product in front of you.
A checklist with steps
Once items grow steps and data tables, they are test cases written badly. Keep checks to one line, or move them into cases.
A scenario used as a test case
"A customer buys with a coupon" cannot pass or fail on its own. Split it into checks with data.
A copied checklist
Ready-made checklists for web forms or mobile apps give ideas, but copied whole they add checks for things the product does not have, such as a photo upload in a shop with none.
Merged negative checks
One item for three invalid values hides which one failed. One value, one line.
Cases for everything
A case for a screen that changes every week costs more than it saves. Start with a checklist.
Where to learn this
13 lessonsQuestions and answers
What is the difference between a test case and a test scenario?
A test scenario is a user's path through a business process and says what to test. A test case is one check on that path with exact preconditions, steps, data and expected results, and says how. One scenario usually gives several test cases.
What is the difference between a checklist and a test case?
A checklist item is one line naming a check, with a status per run and no steps. A test case writes the same check out in full: preconditions, numbered steps with data and an expected result per step. Checklists are faster to write; cases are easier to repeat exactly.
Is a test scenario the same as a use case?
No. A use case is a requirement: it describes how a user and the system interact to reach a goal. A test scenario is a tester's note of which path to test, and it is often taken from a use case.
Does a checklist need expected results?
No, the column is optional. A well-named item, such as "Apply expired coupon WINTER10", tells the tester what to look for. Add the exact message when the team needs it written down.
Can a team work with checklists only?
On a small product that changes often, yes. Once the same checks must be repeated by other people before every release, move them into test cases.
How many test cases come from one scenario?
As many as there are distinct checks on the path: one for each partition and boundary of each input and one for each rule. A short path through a cart with a coupon already gives several.
More guides
- Start hereHow to become a software testerWhat a software tester does, what to learn and in what order, and how to practice without a job: six steps from zero to a small portfolio.
- Bug reportsHow to write a bug reportThe fields of a bug report, a template to copy, a complete example from a practice shop, severity and priority with examples, and the mistakes that send a report back to you.
- Test casesHow to write test casesThe parts of a test case, a template, a complete example and its negative cases, the difference between a test case, a test scenario and a checklist, and how to fix a weak case.
- Test designBoundary value analysis and equivalence partitioning, with examplesHow to split inputs into equivalence partitions, pick boundary values with the 2-value and 3-value methods, and choose the step, worked through four fields of a practice shop.
- Bug reportsSeverity vs priority, with examplesWhat severity and priority mean, who sets each, the scales teams use, and all four combinations worked through on one practice shop, with a short answer for interviews.
- Test designHow to test a login pageTest cases for a login page derived from partitions, a decision table, boundaries and states, plus the security checks every login page needs, worked through on a practice shop.
- API testingAPI testing with Postman: a beginner's guideHow to send your first requests in Postman, read the response, keep addresses and tokens in variables, test 401 and 403, add a status check and run a collection, on a practice shop's API.
- API testingHow to test a REST API manually: a checklistA manual REST API testing checklist without code: reading the OpenAPI documentation, status codes, body, headers, 401 versus 403, negative cases and state, with example requests to a practice shop.
- DatabasesSQL for testers: check what the app savedHow testers use SQL: the queries that check what an online shop saved after an order (order row, items, payments), SELECT, WHERE, GROUP BY and JOIN on a real schema, and the mistakes to avoid.
- Web testingChrome DevTools for testers: how to collect evidence for a bug reportWhich Chrome DevTools panels a tester needs and how to use them to collect the Console error, the request, the server's response and the storage values that make a web bug report reproducible.
- Test processSmoke vs sanity vs regression testingWhat smoke, sanity, regression testing and retesting usually mean, why teams use the names differently, how to ask on a new team, and how to choose the checks for a new build.
- Mobile testingHow to test a mobile appWhat breaks only on a phone, how to choose between an emulator, a simulator and a real device, how to read the app's log and its traffic through a proxy, and a checklist to start from.
See the first course
The full outline of every course is available: you can see each lesson before you start.