Checklists vs Test Cases vs Exploratory Charters

Not every check deserves a numbered, step-by-step script. Last topic's TC-118 is the heavyweight format — precise, repeatable, and expensive to write and maintain. Professional testers carry two lighter formats beside it: the checklist and the exploratory charter — and choosing the right weight for each job is itself a skill interviewers probe, usually as "would you write formal test cases for everything?" (The answer, you're about to see, is a confident no.)

Cooking runs on the same three formats. A printed recipe for the dish you must reproduce exactly. A shopping list — one line per item, because you know how to buy milk. And "make something good from what's in the fridge" — a mission that trusts the cook's skill entirely. Different formats, same cook, chosen by the job.

The Full Test Case

You know this one: title, preconditions, numbered steps, verdict-grade expected result. Its powers — precision, repeatability, reviewability — come at a price: it's the slowest to write and the most expensive to maintain, because every product change that touches its steps demands an edit. So it earns its cost where those powers matter: regression (run every release, often by different people — repeatability is the whole point), anything compliance-adjacent (auditors read test cases, not vibes), and checks whose exact values matter (the $255.00 verdict machine). The rule of thumb: script what must be run identically, repeatedly, by anyone.

The Checklist

A checklist is one line per check, no steps, no preconditions: "promo + member discount don't combine" · "cancellation blocked inside 48h" · "confirmation email arrives." It looks like a lazy test case; it's actually a different tool with a different assumption: the reader is skilled. A trained tester reads "promo + member don't combine" and knows exactly what to do — log in as a member, apply SUMMER15, verify one discount. Writing out those steps for that reader is pure cost. The checklist's job is to make sure nothing is forgotten, not to explain how; it assumes the how. That's why smoke passes (Chapter 3's ten-minute vital signs) are almost always checklists — speed is the point, and the runner knows the product.

The honest limit: a checklist in unskilled hands produces chaos — five people, five interpretations. The format borrows its precision from the person, so it only works where the person has precision to lend.

The Exploratory Charter

The third format documents the least and trusts the most. A charter is a mission, not a script: "Explore date selection across time zones, looking for off-by-one errors. 60 minutes." Where it aims, what it hunts, how long — and nothing about how, because the how is discovered during the session as each finding steers the next probe. Charters are the structure that makes exploratory testing (Chapter 7 gives it a full topic) a discipline rather than wandering: the timebox forces focus, the mission forces aim, and the session notes — what you tried, what surprised you — are the deliverable. Skill and trust assumed; in return, the format finds what no script predicted.

Choosing by Job: Fernway's Mix

Here's how the three formats settle across one real product. The booking regression suite — the checks that must hold every release, sometimes run by others — becomes full test cases: TC-101 through TC-174, maintained with care. The new-build smoke pass becomes a 12-line checklist on the team wiki: search works, property opens, checkout reachable, email arrives — ten minutes, any skilled runner. And the redesigned date picker — new code, unknown risks, nothing stable enough to script yet — gets a charter: explore across time zones, 90 minutes, notes to the tracker. That charter session, incidentally, is what catches FW-312's cousin on the mobile app — a bug no script contained, because no one had predicted it enough to script it. New and changing areas get charters; stabilized behavior graduates to cases; the vital signs live in checklists. Features flow through the formats as they mature.

Format Is Not Rigor

The trap this topic exists to disarm: believing the heavyweight format is the "professional" one and the others are corner-cutting. Rigor lives in the thinking — the Chapter 4 design that decided what's worth checking — and the format is just packaging matched to the audience and the job. A checklist built on solid partitions and boundaries beats a beautifully formatted script that tests the wrong things. Mature teams deliberately run all three formats side by side; the mix is the professionalism. When an interviewer asks "would you script everything?", the answer is this topic in one sentence: script what needs repeatability, checklist what needs completeness, charter what needs discovery — and put the rigor in the design, not the formatting.