Skip to content

Test Planning

Test planning is where the team outlines the scope, objectives, and testing types that will be used. Documents can be saved in ClickUp under Trove > Test Plan Requirements.

Why test planning matters

  • Eliminates vagueness — defines the "what", "when", and "how" of testing, giving the team a clear roadmap
  • Guarantees thorough coverage — prevents accidentally skipping critical areas
  • Early risk awareness — identifies potential bottlenecks before they become actual problems
  • Clear success criteria — sets when testing starts and when it can confidently be called done
  • Improved communication — aligns testers, developers, product managers, and clients around the same expectations

When to start and end test planning

Start when the team has a clear understanding of what needs to be tested:

  • Prerequisites — user stories, business requirements, and functional specifications are ready
  • Initial analysis — risks are identified and clarified with stakeholders (Product Owners, Project Managers, or Dev Leads)

End when the test plan has been finalised and approved:

  • Deliverables — completed documents outlining scope, objectives, and schedules
  • Approval — stakeholders have formally agreed with the plan

Step-by-step process

1. Define scope and objectives

State which features are in-scope and which are out-of-scope.

Example
In-scope Order Tracking — "Order status updates correctly from 'Pending' to 'Shipped'"
Out-of-scope Performance under heavy traffic is excluded

2. Identify testing types

Type Covers
UI Checking Fonts, spelling, layouts, colours
Functional Testing Features meet requirements
Security Testing Identifies vulnerabilities like unauthorised access
Back-end Testing Databases, servers, and behind-the-scenes behaviour
Automated E2E (API) Jest tests covering HTTP endpoints, auth, and permissions — see Writing API E2E Tests
Automated E2E (Frontend) Playwright tests covering customer-facing flows — see Writing Playwright Tests

3. Identify pass/fail criteria

  • Pass — e.g. 100% of features are working
  • Fail — e.g. at least one feature is not working based on requirements

4. Schedule and estimation

Concept Question to ask Covers
Schedule When? Test case execution, bug fixing, retesting before sign-off
Estimation How much? Hours of work needed per feature

5. Define entry and exit criteria

Entry criteria — conditions that must be met before QA can start (prevents the test team being blocked by incomplete code):

  • Code is deployed to the staging environment
  • Test cases are reviewed and approved

Exit criteria — conditions that define completion:

  • Test execution percentage (e.g. 100% done)
  • Pass rate percentage (e.g. at least 95% passed)
  • Defect resolution (all Blocker, Critical, and High severity defects are closed)

Test plan template

Section Description
Test Plan ID & Version Unique identifier and version number to track changes
Introduction Brief summary of the software being tested and the purpose of this testing phase
Scope In-scope features (what will be tested) and out-of-scope features (what won't be tested)
Test Strategy Testing approach (e.g. manual, regression, cross-browser)
Environment Requirements Hardware, software (OS versions, browsers), and test data needed
Schedule & Milestones Key dates for starting and finishing different testing activities
Roles & Responsibilities Who writes test cases, executes them, and manages bugs
Entry & Exit Criteria "Green light" conditions to start and "finished" conditions to stop
Deliverables Documents to be produced (e.g. final test summary report, defect logs)

Automated testing coverage

When scoping a feature for testing, check whether it has automated coverage in the codebase. Automated tests handle regression at the API and browser level so manual effort can focus on exploratory, visual, and edge-case testing.

Do's and don'ts

Do:

  • Involve testers early
  • Identify risks early

Don't:

  • Underestimate bug impact
  • Leave exit criteria unclear