Test Planning

Basketly's "save cart for later" feature ships in a week. The developer thinks you will test on Android. The product owner assumes iOS is covered too. You planned to test on the web. Nobody is lying; nobody wrote anything down. A test plan is the page that stops three people carrying three different pictures.

The rule

A plan says what, how, where and when done, including what is not tested.

A test plan can be ten pages or half a page; for most Agile features, short is better. What matters is that it answers the key questions:

• Scope: what is in, and what is explicitly out.
• Approach: which kinds of testing: functional, regression, exploratory, performance and so on.
• Environment and data: where tests run (a staging site, devices, browsers) and what test data is needed.
• Entry criteria: what must be true before testing starts, such as "deployed to staging and smoke test passes".
• Exit criteria: what "finished" means, such as "no open critical bugs and all high-priority cases pass".
• Risks: what could go wrong with the testing itself, such as late delivery or missing devices.
• Roles and schedule: who does what, by when.

The plan is a living tool, not a contract carved in stone. When scope changes, update it and tell people.

The shortcut

Write the plan as answers to six questions: What? Not what? How? Where? When can we start? When are we done? If any answer is blank, that blank is a risk to raise now.

The trap is leaving exit criteria vague, like "when testing is complete". Testing is never complete; exit criteria make "enough" a decision the team agreed in advance, not a feeling on release day.

Drills

Answer fast — trust the rule.

Remember

• A plan says what, how, where and when done, including what is not tested.
• Six questions: What? Not what? How? Where? When start? When done?
• Vague exit criteria turn release day into guesswork.