Test cases vs scenarios vs charters: the difference

A lot of confusion in QA comes from treating these three as synonyms for "a thing we test." They're not. They sit on a spectrum from fully prescribed to fully open, and choosing the wrong one wastes effort: a scripted test case where you needed exploration produces shallow coverage; an open charter where you needed repeatable proof produces nothing auditable. Knowing the difference is what lets you match the tool to the risk.

The three, defined

Test case — the most prescribed. Specific steps, specific data, one expected result. "Log in as a standard user with valid credentials; expect the dashboard." It's repeatable, unambiguous, and easy to hand to someone else or automate. Its strength is precision; its weakness is that it only ever finds what you thought to script. This is the form you want for test cases developers actually read and for anything that must be re-run identically.

Test scenario — higher level, less prescribed. "Verify a user can complete checkout with a saved card." It describes what to validate without dictating every step, leaving the tester to fill in the how. One scenario can spawn several test cases. It's good for coverage planning and for communicating intent without drowning in steps.

Test charter — the most open. A mission, not a script: "Explore the checkout flow with invalid payment data to discover error-handling gaps." It deliberately doesn't say what you'll do or what you'll find — that's the point. A charter aims an exploratory session at an area and a goal, and trusts the tester to investigate. Its strength is finding the unexpected; its weakness is that it's not a repeatable proof of anything specific.

When to use which

The choice is about what the work needs to prove or discover:

• Need repeatable, auditable proof (regression, compliance, automation candidate)? Test case. You want the same steps, same result, every time.
• Need to plan and communicate coverage before writing detail? Test scenario. Map the scenarios first, then decide which become scripted cases and which become charters.
• Need to find what you don't know to look for (new feature, risky area, "what could go wrong here")? Test charter. Scripts can't discover the unknown; exploration can.

Most real testing uses all three: scenarios to plan coverage, cases to lock down the critical repeatable paths, charters to explore the risky and the new. They're complementary, not competing — exploratory and scripted testing aren't opposites.

Picking the right artifact

• Repeatable, must-run-identically, automation candidate → test case (steps + data + one expected result)
• Coverage planning, communicating what to validate → test scenario (intent, not steps)
• New/risky area, finding the unknown → test charter (mission, not script)
• Don't script what you should explore (shallow coverage) or explore what you must prove repeatably (nothing auditable)
• A scenario can become several cases and/or several charters — start broad, then choose

The common mistake

The mistake I see most is a team that only writes test cases — every piece of testing forced into scripted steps. It feels rigorous, and it systematically misses everything no one thought to script, because a test case can only confirm a known expectation. The opposite mistake — only charters, nothing repeatable — leaves you unable to prove a fix stayed fixed. The skill isn't preferring one; it's reaching for the right one. Match the artifact to whether you're confirming the known (case), organising coverage (scenario), or hunting the unknown (charter).