Topic 21

Test Plan & Test Strategy

Documentation

Before a big trip you decide where you're going, what you'll skip, and what you'll do if it rains — without necessarily writing a novel about it. Teams do the same for testing. A test plan answers the questions that must not be answered by accident: what will be tested, by whom, how deep, by when, and what happens when reality interferes. Some of it gets written down; all of it must be decided — because every question the plan doesn't answer gets answered by chance instead.

The Questions a Plan Answers

Strip the ceremony away and every real test plan answers five questions. Scope — what's being tested this time, and, just as important, what's explicitly out (the "what we're skipping" line is the plan's most valuable sentence — it's where surprises go to be prevented). Approach — which levels and types of testing, which techniques, how deep for which areas (Chapter 7 will teach the risk math behind "how deep"). People — who tests what, especially when "who" is one person with two hands. Schedule — when testing can start, when it must end, and what it depends on. And risks — what could derail the effort itself: an environment that keeps falling over, a third-party sandbox with moods, a story that might land late.

Strategy vs Plan

Two words that get blurred daily, worth keeping straight. The test strategy is the organization's durable "how we test around here": which levels developers own, what gets automated, which environments exist, what the Definition of Done demands. It changes rarely — think of it as the constitution. The test plan applies that strategy to one concrete effort — this release, this feature — and lives only as long as the effort does. Strategy: "regression is automated and runs on every change." Plan: "for the promo-code release, we also run manual exploration on checkout, because the money flows changed." Teams blur the words constantly; knowing both meanings lets you translate on arrival.

Right-Sized Planning

Here's where honesty beats textbooks. A regulated medical device needs a formal test plan document — signatures, versions, the works — because auditors will read it. Fernway needs one page per release. Agile teams plan per sprint, mostly in conversation, with the plan's decisions living in the sprint board and the Definition of Done. The right size is exactly this: big enough that the five questions have deliberate answers, small enough that people actually read it. A 40-page plan nobody opens answers nothing; it just hides the unanswered questions more expensively. The itinerary analogy holds: one page of destinations, skips, and rain plans is useful; a binder is luggage.

Your first Fernway release plan — one page, five answers

Scope — in and explicitly out

promo + checkout + regression · gift cards and mobile OUT, in writing

Approach — levels, techniques, depth

field workups · decision table columns · pairwise browsers · one charter

People — who does what

you: system · Omar: unit/integration · Petra: acceptance pass

Schedule — entry and exit criteria

start when smoked · stop when exit criteria met

Risks — what could derail testing itself

sandbox moods · late stories · each with a plan B

Entry and Exit Criteria

Two pieces of plan vocabulary earn special attention because they'll follow you to Chapter 7. Entry criteria say when testing can meaningfully begin: the build passed smoke, the environment is up, the stories are actually finished. They protect you from the classic waste — testing half-built features and filing bugs about missing parts. Exit criteria say when testing can honestly stop: no open critical bugs, the risk-tier-1 areas fully covered, the regression suite green. Their real power is when they're agreed: in calm, at planning time — so that release-day Friday becomes a check against written criteria instead of a negotiation under pressure. Chapter 7 shows that Friday in full; this page is where you set it up to go well.

The Plan as a Conversation Artifact

Your one-page plan goes to Nadia and Petra before testing starts — and this is the real reason it exists. Nadia reads the scope line and stops: "Wait — mobile is out?" Yes: nothing mobile changed this release, and one tester covering everything means choosing. Short discussion; the choice stands, but now it's the team's choice, made on Monday — not your private gamble, discovered by everyone on Friday. That's the plan doing its job: not predicting the future, but making the decisions visible while they're still cheap to change. Nadia signs off in five minutes. For a one-page plan, five minutes is a compliment.

Common Confusions

"A test plan is a list of test cases." Cases are the next topic; the plan is the level above — scope, approach, people, schedule, risks. A plan can be excellent without containing a single test case.
"Agile teams don't plan testing." They plan smaller and more often — per sprint, per story, in refinement and the Definition of Done. The five questions never go away; only the paper does.
"The plan is written once and then followed." The plan is the decisions, not the paper. When reality disagrees — a story lands late, the sandbox dies — the plan gets revised out loud, which beats being silently abandoned.
"More detailed plans are more professional." The 40-page plan nobody reads hides unanswered questions behind formatting. Professional is when every reader can find what's out of scope in thirty seconds.

Why It Matters

"What would your test plan cover?" is a junior interview staple — and the five questions (scope, approach, people, schedule, risks) are a complete, memorable answer.
The explicit out-of-scope line is the cheapest insurance in testing: it converts Friday surprises into Monday decisions.
Exit criteria agreed in calm are what make release-day conversations sane — this page plants the seed that Chapter 7 harvests.

Knowledge Check

What distinguishes a test strategy from a test plan?

The strategy is the durable organizational approach; the plan applies it to one specific effort
The strategy is the longer, more detailed document of the two
Managers write strategies while testers write plans
Strategies are for waterfall and plans are for agile

Why is the explicit "out of scope" line the plan's most valuable sentence?

It reduces the amount of testing that has to be done
It turns a silent gap into a visible team decision made while it's cheap to change
It protects the tester from blame when bugs appear
It satisfies the auditors who review test documents

The build hasn't passed smoke and half the stories are still in development. What plan concept says testing shouldn't start yet?

Exit criteria
Entry criteria
The risks section
The out-of-scope declaration

Why are exit criteria agreed at planning time rather than at release time?

Because criteria legally cannot be changed once written
Because the planning software requires them as mandatory fields
Criteria set in calm make release day a check instead of a pressured negotiation
So the tester alone gets to decide whether to release

You got correct