Test Planning & Strategy

The 5 Key Questions

Every test plan answers five simple questions. Think of them as the who, what, where, when, and how of testing.

1. 1

   WHAT

   Which features and areas will we test?

2. 2

   WHERE

   Which environments — staging, production, specific devices?

3. 3

   HOW

   Which techniques — manual, automated, exploratory?

4. 4

   WHEN

   What is our schedule and timeline?

5. 5

   WHO

   Which testers own which areas?

Anatomy of a Test Plan

A test plan document has a few standard sections. You don’t need to write a 30-page novel — one page is often enough.

Test Plan Document

6 fields

Scope:"What is IN and OUT of testing"

Risks:"Things that could go wrong"

Schedule:"Start date, end date, milestones"

Resources:"People, tools, environments"

Entry Criteria:"When can testing begin?"

Exit Criteria:"When are we DONE testing?"

Risk-Based Prioritization

You will never have time to test everything. So test the risky stuff first. Risk has two parts: how likely a bug is, and how bad it would be.

Risk = Likelihood x Impact

Impact

High

High Impact, Low Likelihood

Payment outage — rare but catastrophic. Test carefully.

High Impact, High Likelihood

Login flow on a new release. Test FIRST and deeply.

Low Impact, Low Likelihood

Footer link in an obscure page. Skip or smoke test.

Low Impact, High Likelihood

Cosmetic glitch on a popular page. Test if time allows.

Low

LowHigh

Likelihood

A Simple Priority Model

Sort every test into one of three levels. The pyramid shows you where your effort goes.

Level 3 — Nice to Have

Edge cases, rare browsers. Test if time allows.

Level 2 — Important

Common workflows and inputs. Test thoroughly.

Level 1 — Must Pass

Core flows that block release if broken.

• Level 3 — Nice to Have:Edge cases, rare browsers. Test if time allows.
• Level 2 — Important:Common workflows and inputs. Test thoroughly.
• Level 1 — Must Pass:Core flows that block release if broken.

Quick check

Question 1 of 10 correct

You have 2 days to test a release. The payment flow is critical. A rarely-used admin report also needs testing. What do you do?

Test both equally — every feature deserves attentionTest payment first and deeply; smoke test the admin report if time permitsSkip the payment flow since it worked last releaseTest the admin report first because it is simpler

HintSubmit

Estimating Time

Testing always takes longer than you think. A simple rule: estimate the work, then add a buffer.

Entry vs Exit Criteria

Two gates bookend your testing work. One decides when to start. The other decides when to stop.

Entry Criteria

• Conditions to BEGIN testing
• 'Is the build ready for me?'
• Code is deployed to staging
• Test environment is accessible
• Smoke test passes
• Test data is loaded

Exit Criteria

• Conditions to FINISH testing
• 'Are we safe to ship?'
• All Level 1 tests pass
• No Critical or Major bugs open
• 95%+ of planned tests executed
• Sign-off from product owner

VerdictWithout entry criteria, you start testing a broken build. Without exit criteria, testing never ends — or ends too early.

---

Practice: Prioritize These Test Items

Drag these test items into priority order — highest priority (Level 1) at the top, lowest (Level 3) at the bottom.

1. 1Footer year updates to current year
2. 2User can log in with valid credentials
3. 3Password reset email is delivered
4. 4Checkout with credit card completes successfully

Check Order

---

Quiz

Question 1 of 30 correct

Which section of a test plan tells the team when testing is officially complete?

ScopeEntry CriteriaExit CriteriaResources

HintSubmit