Free Test Plan Template (Fillable + Example)

What goes into a test plan template?

A usable test plan has eight sections and one number: the scope, the context, the risks, the test approach, entry criteria, exit criteria, the environment, and the schedule and owners. Everything else is an appendix.

The reason to keep it short is that a test plan is a coordination document, not a compliance artefact. If the plan cannot be read in ten minutes by a developer, a product manager, and a support lead, it will not be read at all, and the release decision will be made in a meeting that reconstructs it from memory.

The section list below follows the structure defined for test documentation in ISO/IEC/IEEE 29119-3, which is the standard most templates are quietly descended from. The standard is more thorough than most teams need; the trimming is deliberate and safe as long as scope, risk, and exit criteria survive.

Two of these earn their space more than the rest. Scope, because a plan without exclusions turns every missed edge case into a personal failure. Exit criteria, because a release without them becomes an argument about feelings at 6 p.m. on a Thursday.

What does a filled-in test plan look like?

Here is a shortened but complete example for a checkout release at an online retailer. The numbers are realistic and deliberately unglamorous.

Scope. In scope: cart recalculation, discount codes, payment authorisation for two providers, order confirmation email, refund initiation. Out of scope: the mobile app checkout (separate release next sprint), tax calculation for the two new regions (finance has not signed off rates), and load testing above 400 concurrent users.

Context. Minor release, 3-week window, one hard date driven by a partner promotion. Two testers, one of whom is also on support rotation two days a week.

Risks. Discount stacking produces a negative total (high impact, medium likelihood). Payment provider timeout leaves an order in limbo (high impact, low likelihood). Confirmation email renders incorrectly in Outlook (low impact, high likelihood).

Approach. Risk-based: 60% of available effort on the three high-risk areas, exploratory sessions on discount edge cases, automated regression for the 120 stable cases in the existing suite, manual pass on the 40 new cases.

Entry criteria. Build deployed to staging by Monday 10:00, smoke suite green, three seeded test accounts with saved cards, discount code set refreshed.

Exit criteria. 96% of planned cases executed, 0 open critical defects, no more than 3 open medium defects with agreed workarounds, all five high-risk areas signed off by the named owner, regression suite at 100% pass.

Schedule. Week 1: new feature cases and discount edge cases. Week 2: regression plus payment provider integration. Week 3: fix verification, exploratory pass, and the summary report two days before release.

The executed plan then tracks per area:

Read that table the way a release manager would: 94% executed against a 96% target, two high defects still open, and the discount area is where the risk lives. That is a “hold for one day” decision, not a coin flip, and it took ten seconds to see because the numbers were in the plan.

How do you estimate test effort without guessing?

Estimate in three layers — authoring, execution, and rework — and multiply by a factor for the unknown. The numbers below are typical for web application testing; adjust them against your own last release rather than trusting them blindly.

Layer 1: authoring. 2 to 4 hours per new test case, including data setup and review. A 60-case feature is 120 to 240 hours, which is why teams write fewer, better cases.

Layer 2: execution. 0.5 to 2 hours per case per cycle for manual testing, 12 to 30 minutes for a stable automated case including triage. A suite of 250 cases at 45 minutes average is about 187 hours — nearly five weeks for one tester, which is why suites get pruned.

Layer 3: rework. Expect 20% to 30% of defects to need a second verification pass, and 10% of cases to change when the requirements move. Add that before you promise a date.

Example 1 — the capacity calculation. Two testers at 30 productive hours a week each give 60 hours weekly. The checkout plan above needs 187 hours of execution plus 40 hours of authoring for new cases plus 45 hours of rework allowance: 272 hours. Divided by 60, that is 4.5 weeks. The release window is 3 weeks. The plan either shrinks the regression suite or adds a tester; no amount of optimism changes the arithmetic.

Example 2 — regression cost per cycle. 320 manual regression cases at 12 minutes each is 64 hours. Run twice a month: 128 hours monthly, or roughly one full-time tester’s capacity. Automating the 120 most stable cases brings the manual load to 200 cases at 12 minutes, 40 hours, saving 24 hours per cycle and 48 hours a month — about $4,300 a month at a $90 loaded hourly rate. That number, not a tool preference, is the business case for automation.

Example 3 — the cost of a weak exit criterion. A missing validation ships to production, support handles 140 tickets at 12 minutes each: 28 hours, or $2,520 at a $90 rate, plus the refunds and the trust. Against a two-hour review of the exit criteria, the return is not subtle.

Example 4 — risk-weighted coverage. If the three highest-risk areas hold 20% of your cases but 60% of your historical defects, scheduling them first means that when the window shortens you cut from the 80% that finds less. Teams that order their plan by risk finish testing the important things even when they run out of time.

Which parts of the template do teams skip, and what breaks?

Exit criteria. Skipped because they force a conversation about quality thresholds that nobody wants to have at planning time. The cost arrives later as a release that ships with known defects and no recorded decision. Write the numbers on day one, when everyone is calm.

Out-of-scope list. Skipped because it looks like negativity. In practice it is the most protective line in the document: when a stakeholder asks why mobile checkout was not tested, the answer is one sentence in a plan they already had.

Entry criteria. Skipped because testing “just starts”. Then the first two days are spent waiting for a stable build, and the estimate fails for a reason that was predictable.

Environment and data. Skipped because it is boring. Then a tester spends a morning creating an account with a saved card and a valid discount code, for the third time that month.

The approver’s name. Skipped because “the team decides”. A release with no named approver has no one who can say no, which means the default answer is always yes.

How does a test plan differ from a test strategy, a test case, and a test script?

These four documents get conflated, and the confusion produces either a plan that reads like a policy manual or a strategy that reads like a to-do list.

A practical rule: if a sentence would still be true next year, it belongs in the strategy. If it names a date, a build, or a person, it belongs in the plan.

How do you use the template step by step?

1. Copy the master, never fill it. Keep a clean template with placeholder text; duplicate it per release so the original stays usable.
2. Write the scope and the exclusions first, before the schedule. The exclusions are what make the schedule honest.
3. Score five to ten risks on impact and likelihood, and put the two highest in the first week of the schedule. A risk that is not on the schedule is a risk that is not mitigated.
4. Set exit criteria as numbers and get the approver to agree to them in writing before testing begins.
5. Fill the tracking table as you go, daily if the release is short. A plan updated at the end is a report, not a plan.
6. Hold a 20-minute mid-point review at the halfway mark: re-check the risk order, cut low-value cases, and re-forecast with real execution speed.
7. Close with a summary: executed, passed, open defects by severity, deviations from the plan, and the recommendation. Two paragraphs and a table.
8. Archive it next to the release, because the next plan’s best input is the last plan’s actuals.

How does Doitify fit a test plan workflow?

Doitify is our product, so read this as disclosure. A test plan in a document goes stale the moment execution starts; the same plan as a project structure stays current. In Doitify you can model the template as a project with one task per test area, sub-tasks per case group, checklists for entry and exit criteria, owners per row, and a Gantt or timeline view for the three-week window. Work reports then answer the question the tracking table asks — executed versus planned — without a second spreadsheet.

The honest limit: Doitify is not a test management system. It does not store automated results, integrate with CI pipelines, or track defect history across releases. Teams running thousands of automated cases need a dedicated tool. Teams running a 200-case manual release plan, with a QA owner and a deadline, get most of the value from the project workspace they already use.

Conclusion

A test plan template earns its keep by making three things explicit before anyone opens a browser: what is out of scope, what the biggest risks are, and what number means “done”. Everything else — the environment list, the schedule, the owner column — is scaffolding around those three decisions.

Copy the eight-section structure, fill it for one real release this month, and keep the filled version as your worked example. The second time takes twenty minutes, and the release conversation stops being about who feels confident and starts being about which criteria are green.

If this post on test plan template was helpful, you might also enjoy Resource Planning Software: What to Look For and How to Automate Task Assignment (Step-by-Step).