Manual Testing
Intermediate 14 min read Manual Testing

Test Planning & Strategy

A test plan turns scope, risk and schedule into a concrete testing strategy. Learn how to define scope, prioritize by risk, choose test levels and entry/exit criteria, and communicate the plan to stakeholders.

test plantest strategyentry criteriaexit criteriarisk-based testingtraceability
Prerequisites: Testing Fundamentals Test Case Design Techniques
Introduction

What is this?

Test planning defines the scope, approach, resources, schedule and criteria for a testing effort. A good plan is driven by risk: high-risk areas get deep coverage early, and entry/exit criteria make the release decision objective rather than emotional. The plan is a living document recording what will be tested, how, with which tools and data, and who owns each activity.

Motivation

Why do you need it?

  • It forces stakeholders to agree on scope before testers burn time on unprioritized work.
  • Risk-based prioritization focuses effort where failure hurts the most.
  • Exit criteria give a measurable, objective definition of 'done' for testing.
  • A written plan survives staff changes and keeps testing consistent across releases.
  • Traceability from requirements to tests proves coverage and supports audits.
Think about it

Mental model

Imagine

An architect's blueprint

Think of

A test plan

You would not build a house without a blueprint; the test plan is the blueprint for quality. It shows what gets built (scope), how (strategy), with what materials (environment, data, tools), and how you will know it is done (exit criteria).

Mechanics

How it works

  • Gather requirements, release goals and the risk profile from stakeholders.
  • Define what is in scope and explicitly what is out of scope.
  • Identify test levels (unit, integration, system, UAT), types (functional, performance, security) and entry/exit criteria for each.
  • Estimate effort, assign resources, and schedule test phases against the release timeline.
  • Track execution and re-baseline the plan as risks materialize or scope shifts.

The test-planning loop from scope to release decision.

Requirements & risks
Define strategy
Estimate & schedule
Execute & track
Exit criteria review
Release decision
Reference

Key commands

gh pr list --label release --state open

List pending release changes on the CI pipeline to scope the plan.

curl -s https://staging.example.com/release-candidates | jq '.builds[0].version'

Confirm the build version the plan will target.

"v2.0-RC2"
python3 -c "print(round(124.99 * 1.08, 2))"

Compute expected order totals to seed test data for the tax rule.

134.99
jira issue list -q 'project = QA AND fixVersion = v2.0' --max 20

Pull the open defect backlog into the planning review.

npm test -- --coverage

Pull unit-test coverage numbers into the strategy review.

Hands-on

Examples

A test plan outline (IEEE 829 style)

A test plan outline (IEEE 829 style)
# Test Plan — Checkout v2.0
Scope        : Checkout flow, payment integrations, order history
Out of scope : Mobile apps, performance, accessibility
Risks        : P1 payment provider latency, P0 order total rounding
Strategy     :
  - System: 60% scripted, 40% exploratory
  - Regression: critical-path smoke + full suite
Entry criteria : Build v2.0-RC1 deployed, test data seeded
Exit criteria  : >= 95% pass, no open P0/P1 defects, crash-free on target browsers
Tools       : Jira (defects), TestRail (cases), Postman (API)
Schedule    : T-5 spec review, T-3 case freeze, T-1 full regression, T0 sign-off

The plan answers who/what/where/when for the release. Explicit entry and exit criteria turn sign-off into an objective gate, and the risk table explains why payment integration gets the most test time.

Real world

In production

  • Release readiness reviews use the test plan's exit criteria as the gate for go/no-go.
  • Risk-based plans drive which tests run nightly versus smoke on every deploy.
  • Traceability matrices satisfy compliance audits in regulated industries such as finance and health.
  • Plans that split scripted versus exploratory time keep coverage both broad and deep.
Guidelines

Best practices

  • Write exit criteria as numbers (pass %, open-defect counts) not adjectives.
  • Prioritize tests by business risk: severity x likelihood x frequency.
  • Review the plan with developers and product owners before execution starts.
  • Re-estimate after the first week — estimates always drift from reality.
  • Keep a live traceability matrix from requirement to test to defect.
Watch out

Common mistakes

  • Testing everything equally instead of allocating effort by risk.
  • Setting exit criteria after testing ends so they conveniently match the results.
  • Forgetting to plan test data, environments and access early.
  • Treating the plan as static — it must change as scope and risk do.
Root cause analysis

Common issues

Error
Test environment unavailable during the critical week
Root cause

Environment booked by other teams or undermanaged

Fix

Add a buffer environment and put environment booking in the plan with an SLA.

Error
Regression suite grew from 100 to 1,000 cases in a year
Root cause

No review of redundant or obsolete cases

Fix

Run quarterly suite audits: remove duplicates and convert stable cases to automation.

Error
Stakeholders reject the exit criteria as too strict
Root cause

Criteria not tied to business risk

Fix

Map each criterion to a business risk and negotiate trade-offs explicitly.

When things break

Debugging tips

  • If a test phase slips, cut low-risk coverage before cutting high-risk coverage.
  • Attach every missed deadline to a root cause (environment, data, dependencies) and fix the cause.
  • When pass rate is below target, separate defect-blocked tests from genuine failures.
  • Track time-in-test per requirement to spot the 20% of features eating 80% of effort.
Interviews

Interview checkpoint

Practice

Hands-on lab

Build a Risk-Based Test Plan for a Checkout Release
45 min · intermediate
In progress
Objectives
  • Define scope and out-of-scope for a release
  • Rank features by business risk with a numeric score
  • Write checkable entry and exit criteria
  • Allocate effort and draft a schedule with milestones

Build a Risk-Based Test Plan for a Checkout Release

45 min · intermediate

0/5 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Which of the following is a valid exit criterion for a release?

2

The test plan should be updated when scope or risk changes.

3

You have 40 hours to test a release. Payment caused three production incidents last year; PDF export is rarely used. How do you split effort?

Quick reference

Cheat sheet

Risk-based prioritization
Severity x likelihoodScore each feature's risk
Entry criteriaWhat must be true before testing starts
Exit criteriaWhat must be true to ship
Traceability matrixRequirement -> test -> defect
Go/no-goRelease decision from exit criteria
Go deeper

Official documentation

IEEE 829 — Standard for Software and System Test Documentation
docs
Software Testing Help — Sample Test Plan Document
docs
Guru99 — Test Strategy Document
docs
ISTQB — International Software Testing Qualifications Board
docs