Test Plan vs. Test Case: Differences and Examples

A test plan describes how a body of testing will be organized: its scope, approach, resources, responsibilities, and schedule. A test case specifies one particular check, including the conditions and inputs needed to run it and the result that should occur.

In short, the plan coordinates the work; cases make individual checks executable and assessable. A plan can organize many test cases, and neither artifact replaces the other.

1. Test plan vs. test case at a glance

Dimension	Test plan	Test case
Main question	What testing will be done, how, by whom, with what resources, and on what schedule?	Given these preconditions and inputs, what action is taken and what result should occur?
Scope	A project, release, test level, or test type	One test objective or condition
Typical contents	Objectives and scope, approach, tasks, owners, resources, schedule, environment, criteria, and risks	Preconditions, inputs, actions where applicable, expected results, and postconditions
Purpose	Coordinate and communicate intended testing	Guide a particular check and make its outcome assessable
Relationship	Can organize many cases; a project may use a master plan and more detailed plans	Implements a check within the planned testing

ISTQB defines a test plan as “a document describing the scope, approach, resources and schedule of intended test activities.” Its glossary defines a test case as “a set of preconditions, inputs, actions (where applicable), expected results and postconditions, developed based on test conditions.” See the ISTQB test plan entry and the ISTQB test case entry.

2. What belongs in a test plan?

A plan gives the people involved a shared account of the testing that is intended and how it will be managed. Its detail should fit the project’s size, risk, and context; there is no single universal template that every team must use. Common sections include:

Objectives and scope: what the testing aims to learn or verify, which items and features are included, and what is out of scope.
Approach: test levels and types, techniques, automation strategy, and how risks influence priority.
Tasks and responsibilities: work to be done, owners, and any required tester independence.
Resources and environment: people, tools, test data, systems, integrations, and environment dependencies.
Schedule: planned activities, milestones, dependencies, and available time.
Entry and exit criteria: conditions for starting or completing a test activity, such as environment readiness or agreed completion criteria.
Risks and rationale: known constraints, likely risks, and decisions that shape the approach.

These are useful planning prompts, not mandatory fields for every project. ASTQB’s presentation of ISTQB Foundation Level syllabus section 5.1 describes a test plan in terms of objectives, resources, and processes. The ASTQB test-planning syllabus page offers further guidance.

3. What belongs in a test case?

A case needs enough information for someone to carry out the check and judge its result. A practical case usually records:

Identifier and objective: a stable reference and the behavior or condition being checked.
Preconditions: the required starting state, account state, permissions, or environment.
Inputs and test data: values, files, or other data supplied to the system.
Actions: steps to perform, when actions are needed to define the check.
Expected result: observable behavior that determines whether the check passed.
Postconditions: the state expected after execution, where it matters.

The expected result is essential: without one, a tester may perform an action but have no defined basis for evaluating the outcome. ISO/IEC/IEEE 29119-1:2022 describes a test case as a set of preconditions, inputs, and expected results developed to drive execution toward test objectives. It identifies test cases as the lowest level of test implementation documentation for their intended level or type. That is a standard definition, not a claim that the standard is legally mandatory or that teams must use one specific template. See the ISO/IEC/IEEE 29119-1:2022 entry.

4. Example: a test plan for checkout

This illustrative plan covers an e-commerce checkout release. It is an example, not a required format.

Plan item	Example
Objective	Assess whether customers can complete checkout and receive an order confirmation.
Scope	Cart, payment integration, and order confirmation.
Approach	Use risk-based testing, prioritizing payment integration and the order flow.
Resources and environment	Two testers and a sandbox payment gateway.
Schedule	Three weeks for the planned testing work.
Exit criteria	Use agreed project criteria to decide when the planned testing is complete.

The ISTQB glossary uses a checkout plan example and notes that plan depth should suit the project’s size and risk. A real team should define measurable entry and exit criteria appropriate to its release rather than copy an example without adapting it.

These illustrative cases follow the ISTQB glossary example. The 16-character limit is specific to that example; it is not a universal password rule.

Case A: password at the allowed limit

Preconditions: the account exists and the user is on the login page.
Input: a valid password at the system’s allowed 16-character limit.
Action: submit the login form.
Expected result: login succeeds and the user is redirected to the dashboard.
Postcondition: an authenticated session exists.

Case B: password beyond the allowed limit

Preconditions: the account exists and the user is on the login page.
Input: a 17-character password, when the example system limits passwords to 16 characters.
Action: submit the login form.
Expected result: the system displays an error message.
Postcondition: no authenticated session is created.

In a real specification, make the expected message or observable behavior precise enough to evaluate, and use the actual product’s rules and test data.

6. How to draft both artifacts

Agree on the testing objective. State what decision or confidence the testing should support.
Set the plan’s scope and approach. Identify what will be tested, what is excluded, the test activities, and how risks affect priority.
Assign work and resources. Record owners, environment, data, tools, and schedule constraints.
Define completion criteria and risks. Make clear how the team will know an activity is ready to begin and what evidence supports completion.
Derive test conditions. Break the scope into behaviors, boundaries, integrations, and risk areas that need checks.
Write cases for the checks that need repeatable execution. Add preconditions, inputs, actions, expected results, and postconditions where useful.
Review the connection. Confirm that important planned risks and objectives have corresponding checks, and that cases have a usable expected result.
Update when the work changes. If scope, risk, schedule, or system behavior shifts, keep the plan and affected cases aligned.

7. How plans and cases fit together

Think of the plan as the coordination level and the test case as the execution level. The plan establishes the intended scope, approach, people, environment, and timing. Test conditions identified from that work are then elaborated into cases when the team needs specific, repeatable checks.

A project may use a master test plan and separate plans for test levels or types. ISO/IEC/IEEE 29119-1:2022 recognizes this kind of plan hierarchy. The degree of decomposition depends on the project. A small change may need a concise plan and a few cases; a larger or riskier release may need more coordination and more detailed plans.

Neither document guarantees quality by itself. A plan can be organized but omit an important risk; a case can be detailed but test the wrong behavior. Review both against the objectives, product risks, and evidence the team needs.

8. Test plan, test case, test scenario, and test script

Teams sometimes use these terms differently, so check how your organization defines them. A useful working distinction is:

Test plan: organizes testing work and its resources, approach, scope, and schedule.
Test condition: an aspect of the system or a risk that should be tested.
Test scenario: often a high-level situation or flow to explore; it may be less detailed than an executable case.
Test case: a defined check with conditions, inputs, and expected results.
Test script: a manual procedure or automated instructions used to execute one or more checks.

The last three labels can vary by workplace and tool. The formal ISTQB definition of a test case is the safer reference when precision matters; do not assume every team uses “scenario” and “case” identically.

9. Common mistakes and fixes

Problem	Why it causes trouble	Practical fix
A plan lists activities but no objective or scope	People cannot tell what the testing is meant to cover or support.	State the objective, included items, exclusions, and relevant risks.
A case has steps but no expected result	The executor has no defined basis for deciding whether the check passed.	Write an observable expected result for each outcome that matters.
The plan is treated as a fixed template	Irrelevant detail can obscure real constraints, while needed planning may be missed.	Scale the document to the project’s size, risk, and context.
Cases are disconnected from plan objectives	The team may execute checks without covering important planned risks.	Review traceability between objectives or conditions and the cases that address them.
One plan is assumed to cover every level in detail	Different levels or test types may have distinct needs and owners.	Use a master plan with more detailed plans where the work benefits from them.
Example data is copied as a product rule	An illustrative boundary, such as a 16-character password, may not match the actual system.	Derive inputs and expected results from the product’s requirements.

10. Screenshots as test evidence

For visual checks, a screenshot can help record what a page looked like at a particular point in a case. Treat it as supporting evidence: the test case still needs to state the expected result and the conditions under which the image was captured. Keep the tested URL, viewport, state, and relevant test data consistent when comparing captures. Avoid including real credentials or sensitive user information in evidence.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server from Yorker Media. Its API returns an image or PDF from a URL; see the ScreenshotNeo documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before the capture. Bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000.

11. Performance, reliability, and cost considerations

Test documentation has a maintenance cost: more detail takes time to write and keep current. Match the level of detail to risk and repeatability. Write explicit cases for high-risk behavior, release checks, and work that different people must execute consistently. For exploratory testing, the plan may define the objective, boundaries, and reporting expectations without pretending every action can be predetermined as a case.

Reliability depends on clear inputs and conditions. Record environment and relevant starting state so a failure can be investigated and a case can be repeated. Keep expected results observable, and distinguish product failures from environment or test-data problems. A case that relies on unstated setup is fragile even when its steps look complete.

Where visual evidence is useful, capture only what supports the test objective. Repeatedly capturing unchanged pages can add noise and consume time; compare like-for-like states and retain evidence according to the team’s needs. ScreenshotNeo’s stated billing rule is that only clean shots are billed: bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing. Its plans are Free for 1,000 shots monthly, Starter $5 for 3,000, Growth $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000; yearly billing gives two months free. Every feature is on every plan. Refer to the product site and docs for the API and plan details.

12. Frequently asked questions

Can a project have more than one test plan?

Yes. A master plan can coordinate the overall effort while more detailed plans address particular test levels or types, as appropriate to the work.

Does every test case need postconditions?

Not necessarily. Include postconditions when the state after execution matters; the ISTQB definition includes them as part of the formal description.

Is a test plan a test strategy?

Terminology varies across organizations. The test plan records intended testing work and how it will be organized. Use your team’s definitions when distinguishing strategy from plan.

Does ISO require every team to use the same test case template?

No. The cited standard provides definitions and concepts; the dossier does not establish one mandatory universal template or a legal requirement for every team.