Writing a Test Plan From Scratch

A test plan tells the team what testing will happen, what will not, when it will be done, and how the team will know it is finished. Done well, it answers every reasonable question a manager, developer, or stakeholder might have in five minutes of reading. Done poorly, it sits unread in a wiki until something goes wrong.

Who actually reads a test plan

Before writing, picture three readers:

• The engineering manager — will testing fit in the release window, and what risks remain?
• The developer — which areas will you probe deeply, and which lightly, so they know where to compensate?
• The PM or stakeholder — a defensible answer to "are we ready to ship?" without new vocabulary.

If all three can skim and act on the plan, you have written a useful one. A fifteen-page IEEE 829 template that nobody opens has wasted everyone's time.

The sections of a useful test plan

These five sections cover what a useful plan needs. You can add more, but if you skip any of these, the plan is incomplete.

Scope: what's in, and (more importantly) what's out

Defining what is not being tested is just as important as defining what is. Testers fall into the trap of listing the in-scope items and assuming the rest is implied. It never is. If you do not explicitly say "we are not testing the legacy SOAP API in this release," someone will assume you did and act surprised when a regression slips through.

A good scope section reads:

In scope. The new password reset flow on web (Chrome, Safari, Firefox latest) and iOS app v4.2+. End-to-end testing of email delivery via SendGrid sandbox.

Out of scope. Legacy desktop client. Android app (covered separately by the mobile QA team). Production email delivery (mocked in test environment). Performance testing under load (covered next sprint).

Assumptions. Test accounts will be provisioned in the staging environment by Friday. Identity provider (Okta) staging instance will be available for the duration of the sprint.

Compare to a scope section that just says "test the password reset feature." The second version cannot be argued with at release time; the first version cannot.

Approach: which kinds of testing

Different features need different mixes. A typical password reset feature might need:

• Functional testing of happy and error paths.
• Regression testing of adjacent flows (login, account settings, sessions) the change might have affected.
• Smoke testing on every build going to staging.
• Exploratory testing time-boxed for bugs no test case predicted.
• Cross-browser testing — login flows are a high-value target for browser-specific bugs.
• Security checks on the reset link — token expiry, single-use enforcement, rate limiting.

Naming the test types tells the reader where you are spending effort and where you are not.

Entry and exit criteria — when to start and when to stop

This is the section testers most often skip and stakeholders most often ask about.

Entry criteria are the conditions that must be true before testing can begin: the build is deployed to staging, all unit tests pass, the test data is seeded, the relevant developer is available for questions. If those are not met, you do not start — you escalate.

Exit criteria are the conditions that must be true before you call testing complete: 100% of the planned test cases executed, no open critical or blocker bugs, regression suite green, exploratory time-box used. If exit criteria are not met, you do not sign off — you flag what is missing and let the team decide.

Stating both criteria explicitly turns "is testing done yet?" from an opinion into a checklist.

A worked example: the password reset feature

For a small feature, your plan does not need to be long. Half a page works:

• Scope: new password reset flow, web + iOS, 3 browsers; email delivery in sandbox only.
• Approach: functional + regression on login/sessions, smoke on every build, 2h exploratory, token security, cross-browser smoke.
• Schedule: day 1 — data setup; days 2–3 — functional and regression; day 4 — exploratory + cross-browser; day 5 — bug verification and sign-off.
• Risks: SendGrid sandbox flaky in past releases (mitigation: backup data ready); Okta staging may rate-limit (mitigation: pre-provision 50 test accounts).
• Entry: build deployed; sandbox responding; test accounts ready.
• Exit: all happy/error paths tested; no open critical/blocker bugs; login regression green; exploratory log attached.

Half a page, enough information for the team to plan, execute, and sign off. Compare to a fifteen-page IEEE template — same information, ten times the friction, almost certainly unread.

⚠️ Common mistakes

• Writing for the template, not the reader. A plan that mechanically fills in section headers without thinking about what each reader needs is busywork. If a section adds nothing for any of the three readers above, it does not belong.
• Skipping out-of-scope. This is the single most common gap. The day someone is surprised at release time, you will wish you had written one extra paragraph.
• Vague exit criteria. "Testing is complete when QA is satisfied" is meaningless. Real exit criteria are checkable — counts, percentages, named flows, defect thresholds. If two reasonable people can disagree on whether the criterion is met, the criterion is not specific enough.

🎯 Practice task

Pick a small feature you understand well — for example, a "log in with Google" button or a "save shipping address" toggle. Spend 25 minutes writing a test plan from scratch, on a single page:

1. Draft the five sections from this lesson — scope (in / out / assumptions), approach (test types), schedule, risks with mitigations, and entry / exit criteria.
2. Constrain yourself to one page maximum. If the section runs long, cut something.
3. Hand the plan (or read it aloud) to a non-tester friend or colleague. Ask: "Could you tell me, in 60 seconds, what we will test and how we will know it is done?"
4. Note any question they had to ask. Each question is a place your plan was unclear — refine it once and keep the new version as your template for next time.

The plan you draft today will not be perfect. That is fine — a workable test plan written and used beats a perfect one that nobody reads.