test plan is the shopping list and a test case is each item on it. Here's how the two fit together in practice, and why keeping both as simple as possible makes testing easier to manage.

Understanding what is a test plan in testing – and how it differs from a test case – is one of those questions that trips up a lot of teams. A test plan is what you're going to test. A test case is a single instruction within that plan. They're related, but they're not the same, and understanding the difference makes both easier to write and use.

The confusion is understandable. A lot of testing guides use the terms loosely, and some tools blur the line between them entirely. Here's a clear breakdown of what each is, how they fit together, and how Testpad handles both.

What is a test plan in testing?

A test plan is the bigger picture. It captures everything you intend to test in a given release – the scope, the approach, who's testing, which environments, and how you'll know when you're done.

Think of it as the container. It organises your test cases by feature or area and gives your team a shared view of what needs to happen before a release goes out.

In Testpad, a script is your test plan. It's a structured checklist that organises everything you want to cover, broken into folders and sub-folders by feature or area. You run tests against it, track results in real time, and share progress with stakeholders via a live report link – all without a separate reporting tool.

What is a test case?

A test case is a single instruction inside that plan. One thing to check.

Formally, a test case includes a title, steps to execute, expected outcomes, and sometimes metadata like priority or environment. In practice, for most teams, a test case can be much simpler – a short prompt that points a tester at what to investigate.

That's how Testpad approaches it. Rather than formal test cases with multiple required fields, Testpad uses test prompts: short, outcome-focused instructions that tell testers what to check without prescribing every step. They're faster to write, easier to maintain, and leave room for testers to use their judgment rather than just following instructions to the letter.

For more on writing effective test cases, see our guide on how to write a test case.

How do test plans and test cases fit together?

The difference between a test plan and a test case is essentially one of scope. Test cases sit inside a test plan. The plan is the structure; the test cases are the content. A test plan without test cases is just a container. Test cases without a plan are a list with no context. When comparing test plan vs test case, this is the key thing to understand: one sets the scope, the other fills it.

In Testpad, you get both in the same place: the script is your test plan, and each prompt you add is a test case. Open a new script, add your first test prompt, and you've got both.

Where does a test strategy fit in?

A test strategy sits above both test plans and test cases. If test plans and test cases are the operational layer – what you're testing right now – a test strategy covers how your team approaches testing overall: what types of testing you do, how manual and automated work fits together, and where you focus limited testing time.

Most teams don't write a formal test strategy document. But every team that tests regularly has one, even if it's just a shared understanding of how things work. The strategy informs the plans, and the plans are made up of test cases.

It's also worth noting that some teams use "test plan" and "test strategy" interchangeably, which adds to the confusion. If you hear them used that way, just look at the level of detail involved: a test strategy is the bigger "how we test" picture, a test plan is the "what we're testing this sprint" detail. For more on how test plans work in practice, see our test planning guide.

How much detail do test cases need?

Simple answer: as little as possible while still being useful.

A test case needs to be clear enough that the right person can act on it – that's the only real requirement. For most tests, a short description of what you're checking and what a passing result looks like is enough. Longer, more detailed test cases make sense in regulated environments or for complex multi-step processes, but for the majority of teams they create more maintenance work than they're worth.

That's how Testpad is built. Test cases in Testpad are called test prompts – short, outcome-focused instructions that sit inside a structured checklist (the script). Anyone on the team can pick them up and run through them: a developer, a product manager, a client doing UAT. No training, no complex tool to navigate.

What is the most common mistake teams make?

Cramming multiple distinct scenarios into a single test case happens all the time. Someone writes a test case called "test the checkout flow" and packs in 15 different things to check – guest checkout, failed payment, discount codes, empty cart. Those aren't steps in one test; they're separate tests that happen to be lumped together.

The fix is keeping each test case focused on one thing. If a test case is really covering five different scenarios, break them out into separate prompts – grouped together under the same area in your script, but each with its own result. Your plan gets cleaner, results become more meaningful, and maintenance is much easier over time.

Getting started with Testpad

Test plans and test cases are simpler than most guides make them sound. One is the map of what needs testing; the other is the individual checks that make it up. Keep both focused and as lean as the work allows, and testing becomes a lot easier to manage.

In Testpad, a script is your test plan and each line is a test prompt – Testpad's version of a test case. Open a new script, add the features and flows you want to cover, and you have both at once. Organise by area using folders, run tests, and track results all in one place.

Why not give Testpad a go with a trial? It's free for 30 days, and you won't need your card details to sign up.

If you liked this article, consider sharing