Test Planning & Strategy

Test strategy vs test plan#

• A test strategy is the long-lived, organisation- or product-level approach: which test levels you use, the automation approach, tools, environments and quality standards. It changes rarely.
• A test plan is project- or release-specific: what this release tests, who tests it, when, and how you'll know you're done.

Small agile teams often merge both into one lightweight document — what matters is that the decisions are written down and agreed.

What goes in a test plan#

A practical test plan answers these questions (based on the IEEE 829 structure, trimmed for real teams):

1. Scope — features in scope and explicitly out of scope.
2. Approach — test levels and types, manual vs automated, tools.
3. Environments — where testing happens, test accounts, test data.
4. Entry and exit criteria — when testing starts and when it's done.
5. Schedule and responsibilities — who tests what, and by when.
6. Risks and mitigations — what could go wrong and what you'll do about it.
7. Deliverables — test cases, bug reports, test summary report.

Here's a compact example for one release:

Release 4.2 — Test plan (summary)

Scope:        Checkout redesign, discount codes, Apple Pay.
Out of scope: Admin reporting (unchanged), legacy mobile app v3.
Approach:     Manual exploratory + scripted tests for new features;
              automated regression (Playwright) for checkout and login;
              API tests (Postman/Newman) for the discount service.
Environments: staging.example.com with seeded test cards.
Entry:        Build on staging, smoke suite green, stories code-reviewed.
Exit:         All P1/P2 tests pass, no open Critical/High bugs,
              regression suite green, product owner sign-off.
Risks:        Apple Pay sandbox instability → test with mocks + 1 real device.
Owners:       Sara (checkout), Bilal (discounts, API), Ayesha (regression).

Risk-based testing#

You can never test everything, so test the riskiest things most. For each feature, score:

• Likelihood of failure (new code, complex logic, many changes, a history of bugs).
• Impact if it fails (money, data loss, legal, many users affected).

Feature                 Likelihood  Impact  Risk (L × I)  Priority
Payment processing           3         5        15         Highest
Discount calculation         4         4        16         Highest
Order history page           2         2         4         Low
Profile avatar upload        2         1         2         Lowest

High-risk areas get deep testing (many techniques, automation, exploratory sessions); low-risk areas get a smoke check.

Estimating test effort#

Common approaches:

• Work breakdown: list the testing tasks and estimate each — usually more accurate than a single guess.
• Three-point estimate: (Optimistic + 4 × Most likely + Pessimistic) / 6. For a feature estimated at 2, 4 and 9 days: (2 + 16 + 9) / 6 = 4.5 days.
• Ratio-based: testing effort as a percentage of development effort, calibrated from past releases.

Always include time for retesting fixes and regression — that's what teams forget.

Deciding what to automate#

Automate tests that are:

• Run often (regression, smoke).
• Stable (the feature isn't changing every week).
• Deterministic (same input, same result).
• Tedious or error-prone by hand (many data combinations, calculations).

Keep manual: exploratory testing, usability judgements, one-off checks and features still in flux. The Test Automation Introduction goes deeper.

The Requirements Traceability Matrix (RTM)#

An RTM links each requirement to the tests that cover it, so you can prove coverage and see the impact of a change.

If REQ-13 changes, you know exactly which tests to update. If a requirement has no test case, you've found a coverage gap before your users do.