Test plan generator and template
Nine fields in, a six-section Markdown test plan out, plus a check against the four things that separate a real plan from a filled-in template.
Scope, approach, environments, criteria, risks — one item per line, and the output is a plan you can paste anywhere Markdown renders.
Open the tool — free, no signupWhat this tool does
You enter the feature name and release, then seven list fields: in scope, out of scope, test approach, environments, risks, entry criteria and exit criteria. The output is a plan with six numbered sections, dated at generation. Empty fields are marked to be defined rather than silently dropped, so gaps stay visible. Four quality checks run alongside: out-of-scope stated, risks named, exit criteria defined, and an approach with more than one line.
What goes in each section
In scope is what you will test, at feature level, not test-case level. "Cart to payment flow", "guest checkout", "promo code application" — three lines, not thirty.
Out of scope is the section people skip and the one that matters most. Naming what you are deliberately not testing, and why, sets expectations before the release rather than during the incident review. "Legacy PayPal integration — deprecating in Q4." "Load testing — owned by the platform team." When something breaks in an area you excluded, this section is the difference between a conversation and a blame allocation.
Test approach is how you will test each area, and it should name more than one layer. A plan that says only "UI automation" reads as inexperienced. A credible approach mixes layers: API-level regression on the payment service, UI smoke on the critical path, an exploratory session on promo edge cases. The point is showing you chose the cheapest layer that can catch each class of defect.
Entry criteria are what must be true before testing starts — deployed to staging, unit tests green, test data seeded. Without them, testing starts on a broken build and the schedule slips for reasons nobody recorded.
Exit criteria are what must be true to call it done: no open critical or high defects, 95 percent of planned cases executed. Without these, "done" is a matter of opinion — and the opinion that wins belongs to whoever is most senior in the room on release day.
Risks and mitigations are the specific things that could derail this testing effort, with what you will do about each. "Payment sandbox is unstable — mock the gateway for regression, use the sandbox only for the two end-to-end confirmations." A plan with no risks tells stakeholders you have not thought hard enough.
Common mistakes
Leaving out-of-scope blank. The single strongest marker of a senior plan, and the easiest to fill in.
Exit criteria that cannot be evaluated. "The feature is stable" is not a criterion. "No open critical or high defects, and the payment regression suite passes three consecutive runs" is.
A single-layer approach. Everything through the UI is slow, flaky and expensive. Say what you are pushing down to the API and unit levels.
Confusing a test plan with a test strategy. Strategy is the team's standing approach across projects; a plan is this feature, this release, these criteria.
The generator runs entirely in your browser — nothing you type leaves the page. A real plan for a real feature, in a public repo, is also one of the strongest interview artifacts you can build: showing one beats describing one.
Frequently asked questions
How do you write a test plan?
Define what is in scope and explicitly what is out. State your approach per area, naming more than one test layer. List environments, entry criteria that must hold before testing starts, exit criteria that define done, and the risks with your mitigation for each.
What is the difference between a test plan and a test strategy?
A test strategy is the organisation's standing approach to testing across projects — layers, tooling, standards. A test plan applies that strategy to one feature or release, with specific scope, environments, criteria and risks. Strategy changes rarely; plans are written per release.
What should be in the exit criteria?
Conditions that can be objectively evaluated: no open critical or high defects, an execution percentage of planned cases, critical-path automation passing, performance within an agreed threshold. If a criterion needs someone's opinion to assess, rewrite it.
Do small teams need a test plan?
For routine changes, no. For anything where scope is contested, several people are involved, or a third party is in the loop, a one-page plan prevents the argument about what was supposed to be covered. Length is not the point; the out-of-scope and exit sections are.