Test plans, not test cases

test plan written as an outline of short prompts does everything a suite of formal test cases does for most teams, at a fraction of the writing and maintenance cost. The detail belongs in your product documentation and your testers' training, not spelled out again and again in every test.

At a glance

• Test documentation serves two audiences, testers and managers, and neither needs most of the words in a formal test case
• The format fails twice over: too many words, and too much instruction
• Much of the word count is product documentation hiding in the wrong place
• Step-by-step detail serves a tester's first run; it taxes every run after
• The alternative is a test plan written as one-line prompts, adding detail only where a particular test needs it
• Counting test cases never measured coverage anyway

What do you actually need from your test documentation?

Testing exists to learn the state of your product, so the people deciding what happens next are deciding on facts. The documentation is there to serve that, and it has two audiences.

Testers need to know what to test next, and somewhere to record what they found and what they actually did. Managers need to plan the work, see progress, judge how much is left, and report what was learned. Both would like the work to be reusable next time.

That short list covers most of what test documentation is for, and it's worth writing out because it gives you a way to judge the format itself: a word that isn't serving someone on the list is costing time for nothing. (If you want the textbook definitions of plan, case, and script first, we have those too. This article is about the format.)

Why does writing test cases take longer than the testing?

The standard advice for writing a test case asks for a title, preconditions, numbered steps, and expected results, and often more: a priority, a requirement link, an environment field. Written out properly, a single test of a login form runs to a hundred words. A competent tester needed seven: login with the wrong password is denied.

The other ninety-three words aren't free. They cost something when they're written, then again every time someone reads the case, again when it's reviewed, and again every time the product changes and the case has to change with it. Multiply by a few hundred cases and you arrive at the complaint testers have been making for years: more time is spent writing and maintaining the tests than actually testing. Joep Schuurkes made the longer version of the argument in It's time to retire our test case management tools back in 2020.

When the plan changes mid-sprint and forty cases need editing before anyone can test the new behavior, the documentation has stopped serving the testing. The testing is serving the documentation.

Do step-by-step instructions make testing better?

There's a second cost, separate from the word count. A test case that prescribes every step is in effect a transcript of a testing session, written before the session happens, and the tester's job becomes performing it. Performed faithfully, it covers what it mentions, and very little else. The bug sitting one field to the left goes unnoticed, because noticing wasn't in the steps.

This isn't a fringe view held only by process skeptics. Martin Fowler calls it a red flag if a team isn't doing exploratory testing at all, even when its automated testing is excellent. James Bach and Michael Bolton recently spent an entire book, Taking Testing Seriously, on the case that testing is a thinking activity rather than a clerical one. The expensive bugs are usually the ones nobody thought to write a step for.

A prompt works differently. Give a tester logging in with bad credentials and they'll try the wrong password, the empty password, the expired account, and the trailing space on a pasted password that you didn't think of. The line tells them where to look and leaves the looking to them. That freedom is exactly what the transcript was suppressing, and you get it back while still having a plan and a record. (We've written more on keeping plans light enough to explore within, and there's a full guide to exploratory testing if you want the deeper treatment.)

None of this makes structure the enemy. The plan is still a plan. What changes is how much each line presumes to direct the person reading it.

Should your test cases double as product documentation?

Read a detailed test case closely and most of it isn't testing instruction at all. It's product documentation: how to reach the settings page, what the export button is called, what the field accepts, what the dialog should say. Restated, slightly differently, in every case that touches that part of the product.

That information belongs somewhere, just not scattered across a few hundred test cases, which is the one place it can't be maintained: when the export dialog changes, every case that described it is now wrong, and nobody knows how many there are.

So document the product once, in the product documentation. Train testers on the product once, when they join. Then let each test say only what's specific to that test. The login example above got shorter because its detail was already somewhere better, not because anything was lost.

Do your testers really need all that detail?

Detail in a test case is written for a reader who barely exists: the tester seeing the product for the very first time. They're only that person once. From the second run onward, the spelled-out steps are something to scroll past, and something to keep correct forever.

There's a real exception. If your testers are new every time, because the work rotates through contractors or an outsourced pool, then per-step detail is doing a real job. But follow that logic to its end. A test that can be performed by a stranger following instructions, identically, time after time, is a test a machine could perform. That's an argument for automating those particular tests when the cost makes sense, not for keeping humans on transcript duty indefinitely. (For the teams in that situation meanwhile, checklists for outsourced testers covers the middle ground, and manual vs automated covers the boundary.)

The manual testing that remains is the kind where a person's own attention does the work. Which is exactly the kind that doesn't want step-by-step instructions in the first place.

What can you use instead of test cases?

Write the plan as an outline of prompts. A prompt is a short line that points at something worth testing. Related prompts sit together under a heading, so each one reads in the context of its neighbors, and the heading does the scene-setting once. Results are recorded against each line, so the plan doubles as the record.

To be precise about the term: "test plan" already means things in testing. Sometimes it's the formal document setting out how testing will be conducted, with what resources and constraints; sometimes it's loose shorthand for a team's whole collection of test cases. We're not coining a third artifact. The argument is that the plan is the more useful level to think at, because "plan" carries none of the form-filling that "test case" has come to imply.

Prompts work at whatever altitude suits the test. Some are a single precise test: "apply 3.3V to TP12, measure 2.7V ±5% on TP14" is a real one from a hardware team. One line, no schema. Others deliberately stay higher: "try to break the date picker" is a fine prompt, and a tester can spend a productive half hour inside it, running dozens of tests of their own devising. And where one particular test does need step-level care, indent beneath it and write the steps. Detail becomes a choice you make per test, not a form the format makes you fill in.

Here are three tests, written both ways:

What tooling do you need?

Teams have made this trade before. Project managers mostly stopped maintaining Gantt charts and moved to boards. Product teams swapped requirements documents for user stories. Each time, the heavyweight document about the work gave way to a lighter structure for doing the work, and the feared loss of control mostly never arrived. Testing's version of that move is from test cases to an outline.

Testpad is a tool built on exactly this model: a script is an outline of prompts with a column of results per run, and that's most of the idea. But the model doesn't need a product. A text file or a spreadsheet is a perfectly good place to start for a team of one or two; what eventually moves teams to a tool is who else needs to see the plan and its results. How to write a test plan walks through starting one, and checklists vs test cases weighs the same trade-off test by test.

Don't managers need test cases to prove coverage?

Managers need a record of what was tested, with results, progress against the plan, and some sense of how much is left. That's a reasonable requirement.

Exploratory testing, for all its strengths, struggles to meet it. It does produce a record: the notes a tester takes during their sessions. But the completeness and accuracy of those notes depend entirely on that tester's note-taking, a narrative of what was done can't be scanned at a glance, and reusing the notes next time means rewriting them into a list of items, at which point you've written a plan after the fact.

A plan written as an outline of prompts produces the record as a side effect of the testing. The list is the plan, the results against each line are the evidence, progress is how much of the list has results, and the report is the list, annotated. None of it comes from the paragraphs inside formal cases.

The one thing that does go missing is the test case count. But the count was never the measure it appeared to be: a case can bundle a dozen verifications or just one, so "340 test cases, 280 executed" mostly reports how the author sliced up the writing. A report built on the plan says more: what was covered, what was found, and what that means for shipping. Which is the question testing was supposed to answer in the first place. (More on reports that say something in simple test reports and why hiding test results backfires.)

Should you let AI write your test cases?

AI assistants are good at exactly the part of formal test cases that made them painful: the writing. Describe a feature and you'll get plausible cases, formatted fields and all, faster than any human author. If the writing cost were the whole problem, it would now be solved.

It was never the whole cost. Every generated word still has to be read, reviewed, trusted, and kept true as the product changes, and those costs scale with the volume of words, not with how cheaply they were produced. The 2025 DORA report found 90% of developers using AI while only 24% trust its output "a lot". Stack Overflow's 2025 survey put "almost right, but not quite" at the top of the frustration list. Generating more test case text into that situation produces more reviewing, not more testing.

The format question points the other way, though. Ask an AI assistant how to test a feature and what comes back is a plain-text list: one line per test idea, indented for structure, much as markdown is its natural way to structure prose. That list is already in the same shape as the test plan this article has been describing, so the work left is editorial: cut the suggestions that miss, reorder what's left, and you have a usable outline. Turning the same output into formal test cases is real work by comparison: someone has to interpret each suggestion, reword it as a case, add the product detail for how to get there, and spell out the verifications the one-liner left implied. (If you do use AI to draft tests, how to use AI to write better test scripts has the practical version.)

When are formal test cases the right call?

Sometimes the formality is the requirement. Regulated and compliance-driven work can mandate per-case documentation with traceability back to requirements, and if an auditor needs it, you write it. That's a constraint to respect, not a process failure. And as above, tests that must be performed identically by ever-changing hands are better candidates for automation than for documentation.

For everyone else, the better default is a plan written as an outline of short prompts, grouped under headings, with detail added to the particular tests that need it. Traditional test case management covers what the heavyweight tools are like to live with, and checklists vs test cases goes deeper on the compliance angle.

A final word

Testing exists to learn about the state of your product so you can decide what to do next. Every hour your testers spend maintaining paragraphs of case documentation is an hour of looking at the product that never happens. Write the plan as prompts, keep the product detail in your documentation and your training, and spend the difference on testing.

Testpad is built on this model: plans as outlines of prompts, with results, guest testing, and reports on top. Try it free for 30 days.

If you liked this article, consider sharing