Test Scenarios vs Test Cases vs Checklists

Test scenarios in depth

A test scenarioTest scenarioA high-level idea of what to test, such as 'User resets a forgotten password'.Open in glossary → is a one-line description of a situation worth testing. It names the user, the action and the twist, and stops there.

Good scenarios share three traits:

• They describe a situation, not a click path. “Reorder when the cart already has items from another restaurant”, not “Tap Orders, tap Reorder”.
• They can be read by anyone. Product owners, designers and developers can review a list of scenarios in five minutes and say “you forgot the closed-restaurant case”.
• They cover the unhappy paths too. For every happy scenario, ask: what if something is missing, wrong, late, or at its limit?

Test cases in depth

A test caseTest caseA written set of steps, data and an expected result used to check one specific behavior.Open in glossary → turns one slice of a scenario into exact instructions: preconditionsPreconditionSomething that must already be true before you can start a test.Open in glossary →, numbered steps, test dataTest dataThe input values, accounts and records you use while testing.Open in glossary → and an expected resultExpected resultWhat should happen when you perform a test step, according to the requirements.Open in glossary → that can only pass or fail. Everything about writing one well is in How to Write Test Cases. Here we focus on one question that lesson leaves open: how detailed should a case be?

How detailed should a test case be?

There’s no single right answer, but there is a good rule: detail should follow risk and the reader.

Situation	Detail level	Example step
Regulated or money flow, new testers	High	“Tap Reorder on order #1042 (Luigi’s, 3 May)”
Normal feature, team knows the app	Medium	“Reorder order #1042”
Low risk, experienced team	Low (maybe a checklist)	“Reorder works for a past order”

Two tests for “enough detail”:

1. The new-tester test. Could someone on their first day run it without asking you a question?
2. The two-tester test. Would two testers running it independently agree on Pass or Fail?

If either answer is no, add detail. If the case describes every pixel and breaks whenever a button moves, you’ve gone too far.

The bad example breaks the moment the designer changes a color or the restaurant changes a price, even though nothing is wrong with Reorder.

Checklists in depth

A checklistChecklistA simple list of things to check, lighter and faster to use than full test cases.Open in glossary → is a list of short checks without steps or detailed expected results. It trusts the tester to know how to get there and what “right” looks like. That’s what makes it fast to write, fast to run and cheap to update.

Checklists come in two main flavors:

• Smoke and regression checklists. The 10 to 30 things you check on every build or before every release (see Regression and Smoke Suites), such as “Reorder button shows on delivered orders” or “Cart badge updates”.
• Heuristics checklists. Reminders of kinds of things that often break, used while exploring: rotate the phone, interrupt with a call, go offline, switch to dark modeDark modeA display setting that uses light text on dark backgrounds.Open in glossary →, turn on large text, try a screen readerScreen readerSoftware that reads the screen aloud for blind and low-vision users, like VoiceOver or TalkBack.Open in glossary →.

How they fit together

User storyAs a returning customer, I want to reorder a previous order so I can get my usual meal in two taps.

• Scenario: Reorder with all items available

  • Test case: TC-RO-001 One item, no extras
  • Test case: TC-RO-002 Several items with extras kept

• Scenario: Reorder when some items are sold out

  • Test case: TC-RO-007 2 of 3 items sold out
  • Test case: TC-RO-008 Every item sold out

• Scenario: Reorder when the cart has another restaurant

  • Test case: TC-RO-011 Tap Cancel keeps old cart
  • Test case: TC-RO-012 Tap Start new replaces cart
• …and three more scenarios

Checklists alongside

• Reorder smoke check (every build)
• Mobile heuristics: rotate, interrupt, offline, dark mode
• Accessibility quick check

• A user story gives you a handful of scenarios.
• Each scenario produces two or more test cases: the happy one, the negative ones, the limits.
• Checklists run alongside: a smoke checklist for every build, a heuristics checklist for exploratory sessions.

Linking each test case back to its scenario and story is what makes a traceability matrixTraceability matrixA table linking each requirement to the test cases that cover it.Open in glossary → possible: you can show which requirement is covered by which tests.

When to use which

Context	Lean towards	Why
Banking, health, regulated	Detailed test cases	Auditors want evidence; mistakes are costly
Fast startup, frequent releases	Scenarios + checklists	Cheap to write and update as the app changes
New testers on the team	Detailed test cases	They teach the product and keep results consistent
Experienced testers	Checklists	They know the “how”; save time for exploring
Regression pack run often	Cases for risky flows, checklist for the rest	Balance repeatability and upkeep
Exploratory session	A short goal + heuristics checklist	Freedom to follow your curiosity

Worked example: from user story to scenarios to cases

Here’s the full journey for FoodDash’s Reorder feature.

Four of the test cases

The Reorder checklist

• Reorder button visible on delivered orders only
• Button readable in light and dark mode
• Button is at least 44 × 44 pt (iOS) / 48 × 48 dp (Android)
• Screen reader announces “Reorder, order from Luigi’s, 3 May”
• Cart badge shows the new item count
• Price-change note appears when the total differs
• Double-tapping Reorder doesn’t add the items twice
• Works after rotating and after returning from the background
• Offline: a clear “No connection” message, nothing half-added

Keeping them maintainable

Tests that nobody updates turn into noise: they fail for the wrong reasons, so people stop trusting them. A few habits keep your tests useful:

• Name things by label, not by position or color. “Tap Reorder”, not “tap the green button on the right”.
• Don’t hard-code values that change. Prefer “today’s price for Margherita” over “11.90 €”, unless the exact number is what you’re testing.
• Keep data in preconditions or test data, not buried in steps. It’s easier to update one line than to hunt through ten steps.
• Link every case to its scenario and story. When the story changes, you instantly know which cases to review.
• Prune. When a feature is removed or redesigned, archive the old cases. A pack of 300 cases where 80 are outdated is worse than a pack of 220 that are all correct.
• Promote and demote. A checklist item that keeps finding bugs deserves a full case. A case that has passed unchanged for a year in a low-risk area can shrink to a checklist line.

Common mistakes