# Test Plan: [Project or release name]

> Complete project test plan. The section structure follows the test plan
> information item of ISO/IEC/IEEE 29119-3: context, communication, risk
> register, test strategy, activities and estimates, staffing and schedule.
> Replace every `[bracketed]` value and every row marked *Example*, and
> explain any removed section in 4.12 (deviations).

<!--
Guidance: How to use this template
- A test plan applies the organisational test strategy (quality/test-strategy)
  to one project or release. Reference the strategy and record only what differs.
- Fill the risk register (section 3) before the strategy section (section 4):
  the plan should show which tests treat which risks.
- Use real dates, names and estimates. A plan without a schedule and staffing
  cannot be monitored.
- Re-issue the plan when scope, schedule or risk changes materially, and record
  the change in the revision history.
-->

## Document control

<!-- Guidance: Identify the plan so every copy traces to one version. Status moves Draft -> In review -> Approved -> Superseded. -->

| Field | Value |
|---|---|
| Document ID | [TP-PROJECT-001] |
| Project / release | [Project name] [release or increment] |
| Test plan type | [Project master test plan / Level test plan: system / Type test plan: performance] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@test-manager] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Governing strategy | [TS-ORG-001 version x.y] |
| Related documents | [SRS], [Architecture description], [Release plan], [Test design specifications] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Test manager | [@name] | [Approved / Rejected / Approved with comments] | YYYY-MM-DD |
| Project manager | [@name] | [Decision] | YYYY-MM-DD |
| Product owner | [@name] | [Decision] | YYYY-MM-DD |
| Engineering lead | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: One row per issued version. State what changed in plan terms. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Initial draft |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Added performance testing after PR-04 exposure rose to high |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved for execution |

## Contents

<!-- Guidance: Keep in sync with headings. -->

1. [Context of the testing](#1-context-of-the-testing)
2. [Testing communication](#2-testing-communication)
3. [Risk register](#3-risk-register)
4. [Test strategy](#4-test-strategy)
5. [Testing activities and estimates](#5-testing-activities-and-estimates)
6. [Staffing](#6-staffing)
7. [Schedule](#7-schedule)
8. [Glossary and references](#8-glossary-and-references)

## 1. Context of the testing

<!-- Guidance: Describe what is being tested and under what conditions. The reader should know the project, the items and the boundaries before reading any risk or strategy. -->

### 1.1 Projects and test sub-processes

This plan covers testing for [project name], delivering [one sentence on
the business outcome] by YYYY-MM-DD. It is the [master / level] plan and
covers these test sub-processes:

| Sub-process | Covered by | Separate plan |
|---|---|---|
| Unit and integration testing | Development teams | No, governed here |
| System testing | Test team | No, governed here |
| Performance testing | SRE and test team | [TP-PROJECT-002] |
| Acceptance testing | Product owner and business users | [UAT plan ID] |

### 1.2 Test items

| Item | Version or build | Source | Notes |
|---|---|---|---|
| *Example:* Mobile app (iOS, Android) | 4.2.0 | Release branch `release/4.2` | Store builds via CI |
| *Example:* Orders API | 2.8.x | Container image `orders-api:2.8` | Includes schema migration 0042 |
| [Item] | [Version] | [Source] | [Notes] |

### 1.3 Test scope

- **Features to be tested**: [feature 1 with requirement IDs], [feature 2], [regression of existing checkout].
- **Features not to be tested**: [feature] because [reason, for example unchanged and covered by automated regression].
- **Quality characteristics in scope**: functional suitability, performance efficiency, security, usability, compatibility, [accessibility].

### 1.4 Assumptions and constraints

| ID | Assumption or constraint | Impact if false or binding |
|---|---|---|
| AC-01 | *Example:* Feature-complete build delivered to system test by YYYY-MM-DD | System test window shrinks, coverage of low-risk features reduced |
| AC-02 | *Example:* Payment sandbox supports 3-D Secure test cards | Strong customer authentication flows tested in staging only |
| [AC-nn] | [Statement] | [Impact] |

### 1.5 Stakeholders

| Stakeholder | Interest in testing | Involvement |
|---|---|---|
| Product owner | Release readiness, acceptance | Approves plan, leads UAT |
| Development teams | Fast feedback, defect reports | Unit tests, fixes |
| Operations / SRE | Operability, performance | Environment, monitoring, performance tests |
| Compliance | Evidence for audit | Reviews completion report |
| [Stakeholder] | [Interest] | [Involvement] |

## 2. Testing communication

<!-- Guidance: Say how test information flows: meetings, reports, channels, escalation. Missing escalation paths cause late surprises. -->

| Communication | Frequency | Participants | Channel | Output |
|---|---|---|---|---|
| Test stand-up | Daily during execution | Test team, dev leads | [Video call] | Blockers list |
| Defect triage | [Daily / twice weekly] | Test lead, dev lead, product owner | [Issue tracker board] | Triaged defects |
| Test status report | Weekly | Project board | [Wiki page / email] | Status report |
| Go/no-go meeting | Before release | Release board | Meeting | Release decision recorded |

Escalation path: tester -> test lead -> test manager -> project manager ->
steering committee. Blockers older than [one working day] are escalated.

## 3. Risk register

<!-- Guidance: List product risks (what could fail in the software) and project risks (what could stop testing). Score L and I on 1-5. The "Treatment" column must point to section 4 or 5. -->

Exposure is $E = L \times I$ on a 1-25 scale; 15 and above is high, 8-14 medium, below 8 low.

### 3.1 Product risks

| ID | Risk | L | I | E | Treatment in this plan | Owner |
|---|---|---|---|---|---|---|
| PR-01 | *Example:* Promotion stacking rules give larger discount than intended | 3 | 5 | 15 | Decision table tests (4.3); API regression; finance review in UAT | [@name] |
| PR-02 | *Example:* Offline mode loses cart changes on reconnect | 3 | 4 | 12 | State transition tests; network-condition E2E tests | [@name] |
| PR-03 | *Example:* App start time over 3 s on low-end Android | 2 | 3 | 6 | Device lab smoke tests | [@name] |
| [PR-nn] | [Risk] | [1-5] | [1-5] | [E] | [Treatment] | [@name] |

### 3.2 Project risks

| ID | Risk | L | I | E | Mitigation | Owner |
|---|---|---|---|---|---|---|
| PJ-01 | *Example:* Late delivery of the payment integration | 4 | 4 | 16 | Contract tests with stubs; reserve buffer in schedule | [@pm] |
| PJ-02 | *Example:* Only one tester knows the device lab | 3 | 3 | 9 | Pairing and runbook by week 2 | [@test-lead] |
| [PJ-nn] | [Risk] | [L] | [I] | [E] | [Mitigation] | [@name] |

## 4. Test strategy

<!-- Guidance: Apply the organisational strategy to this project. For each subsection, state the project-specific decision and point to the strategy for defaults. -->

### 4.1 Test sub-processes

| Sub-process | Objective | Test basis | Entry criteria |
|---|---|---|---|
| Unit and integration | Verify components and interfaces | Code, API contracts | Code compiles, static checks pass |
| System | Verify requirements end to end | SRS, user stories, risk register | Build deployed, smoke test passes |
| Performance | Verify latency and throughput targets | NFRs, workload model | Feature-complete build in performance environment |
| Acceptance | Validate business fit | Business processes, acceptance criteria | System exit criteria met |

### 4.2 Test deliverables

| Deliverable | Owner | Due |
|---|---|---|
| Test plan (this document) | Test manager | YYYY-MM-DD |
| Test design specifications | Testers | YYYY-MM-DD |
| Test cases and procedures | Testers | YYYY-MM-DD |
| Test data and environment readiness report | Environment owner | YYYY-MM-DD |
| Test status reports | Test lead | Weekly |
| Incident (defect) reports | All testers | Continuous |
| Test completion report | Test manager | YYYY-MM-DD |

### 4.3 Test design techniques

| Feature or risk | Technique | Coverage target |
|---|---|---|
| *Example:* Promotion rules (PR-01) | Decision table testing | Every rule column covered |
| *Example:* Quantity field | Equivalence partitioning and boundary value analysis | All partitions, both sides of each boundary |
| *Example:* Cart sync (PR-02) | State transition testing | All valid transitions and selected invalid ones |
| *Example:* New onboarding flow | Exploratory testing with charters | Three 90-minute sessions |
| [Feature] | [Technique] | [Target] |

### 4.4 Test completion criteria

| Criterion | Target |
|---|---|
| High-risk test cases executed | 100% |
| All planned test cases executed | >= 95% |
| Pass rate | >= 98% |
| Open S1 defects | 0 |
| Open S2 defects | 0, or workaround approved by product owner |
| Must-have requirements traced to a passed test | 100% |
| Performance targets | Met at 100% of forecast peak |

### 4.5 Metrics to be collected

Planned versus executed test cases, pass and fail counts, blocked tests,
defects opened and closed per day by severity, requirements coverage,
automated suite duration and flaky test count. Metrics feed the weekly
status report and the completion report.

### 4.6 Test data requirements

| Data set | Purpose | Source | Privacy controls | Owner |
|---|---|---|---|---|
| *Example:* 500 synthetic customers in 12 countries | Tax and shipping rules | Seed script `seed/customers.ts` | Synthetic only | [@name] |
| *Example:* Promotion catalogue | Discount rules | Copy of production config | No personal data | [@name] |
| [Data set] | [Purpose] | [Source] | [Controls] | [@name] |

### 4.7 Test environment requirements

| Environment | Components | Configuration | Ready by | Owner |
|---|---|---|---|---|
| System test | Web, mobile builds, Orders API, stubbed payment | Production config with sandbox keys | YYYY-MM-DD | [@platform] |
| Performance | Orders API at production sizing | Load generators in same region | YYYY-MM-DD | [@sre] |
| Device lab | [List of devices and OS versions] | Latest test build installed | YYYY-MM-DD | [@test-lead] |

### 4.8 Retesting and regression testing

Every resolved defect is retested in the build that contains the fix. The
automated regression suite runs on every merge to the release branch;
the full manual regression checklist runs once on the release candidate.

### 4.9 Suspension and resumption criteria

| Suspend when | Resume when |
|---|---|
| Smoke test fails on a new build | Fixed build passes smoke test |
| More than 20% of planned tests blocked | Blocking defects resolved |
| Environment down for more than four working hours | Environment restored and verified |

### 4.10 Independence and test levels not performed

[State the level of independence for each sub-process and justify any
test level or type that the strategy would require but this plan omits.]

### 4.11 Entry criteria for the plan itself

The plan is approved, the test environment is booked, test data is ready
and the test team is staffed as in section 6.

### 4.12 Deviations from the organisational test strategy

| Strategy rule | Deviation | Reason | Compensating measure | Approved by |
|---|---|---|---|---|
| *Example:* TS 8 E2E gate before deployment | E2E for mobile runs nightly, not per merge | Device lab capacity | Manual smoke on each store build | [@head-of-quality] |
| [Rule] | [Deviation] | [Reason] | [Measure] | [@name] |

## 5. Testing activities and estimates

<!-- Guidance: Break the work down far enough to estimate and track. Estimate in person-days; show the basis (for example, number of test cases times average effort). -->

| Activity | Output | Effort (person-days) | Basis of estimate |
|---|---|---|---|
| Test planning and risk analysis | This plan | 4 | Previous release |
| Test design | Test design specs, 220 test cases | 15 | 220 cases x 0.07 days |
| Environment and data preparation | Ready environments | 6 | Platform estimate |
| Automation of new regression tests | 80 automated cases | 12 | 80 cases x 0.15 days |
| System test execution (two cycles) | Executed runs, defect reports | 18 | 2 cycles x 9 days |
| Performance testing | Performance report | 6 | Four test types, one retest |
| UAT support | UAT sign-off | 5 | Ten business days at 50% |
| Reporting and closure | Completion report | 3 | Previous release |
| **Total** | | **69** | |

A contingency of [15%] is held by the test manager for retesting and
scope changes.

## 6. Staffing

<!-- Guidance: Map named people to roles, state allocation, and list skills gaps with the training planned to close them. -->

### 6.1 Roles, activities and responsibilities

| Role | Name | Allocation | Responsibilities |
|---|---|---|---|
| Test manager | [@name] | 50% | Plan, report, risk, go/no-go input |
| Test lead | [@name] | 100% | Day-to-day coordination, triage |
| Quality engineer | [@name] | 100% | Design, automation, execution |
| Quality engineer | [@name] | 100% | Mobile and device lab |
| Performance engineer | [@name] | 30% | Performance scripts and analysis |
| Business testers | [Names] | 20% during UAT | Acceptance scenarios |

### 6.2 Hiring needs

[None / one contract performance engineer for four weeks from YYYY-MM-DD.]

### 6.3 Training needs

| Person or role | Training | By when |
|---|---|---|
| *Example:* Business testers | Two-hour session on the UAT tool and defect reporting | YYYY-MM-DD |
| [Who] | [Training] | YYYY-MM-DD |

## 7. Schedule

<!-- Guidance: Show milestones and dependencies, not every task. Align with the release plan and show the critical path for the test team. -->

The schedule below shows the main test milestones; dates are illustrative
and must be replaced with the project dates.

```mermaid
gantt
  title Test schedule
  dateFormat YYYY-MM-DD
  section Preparation
  Test planning           :a1, 2026-01-05, 4d
  Test design             :a2, after a1, 10d
  Environment and data    :a3, 2026-01-08, 8d
  section Execution
  System test cycle 1     :b1, after a2, 9d
  Performance testing     :b2, after b1, 5d
  System test cycle 2     :b3, after b1, 9d
  UAT                     :b4, after b3, 10d
  section Closure
  Completion report       :c1, after b4, 3d
  Go or no-go             :milestone, m1, after c1, 0d
```

| Milestone | Date | Dependency |
|---|---|---|
| Test plan approved | YYYY-MM-DD | Requirements baseline |
| Feature-complete build in system test | YYYY-MM-DD | Development |
| System test exit | YYYY-MM-DD | Cycle 2 complete |
| UAT sign-off | YYYY-MM-DD | System test exit |
| Go/no-go decision | YYYY-MM-DD | Completion report |

## 8. Glossary and references

<!-- Guidance: Define project-specific terms and list every document referenced in the plan. -->

| Term | Meaning |
|---|---|
| Test item | A work product that is the object of testing |
| Test sub-process | A test level or test type with its own planning and control |
| Smoke test | A short test set that shows a build is stable enough to test |
| [Term] | [Meaning] |

References: [Test strategy TS-ORG-001], [SRS], [Release plan],
ISO/IEC/IEEE 29119-3, *Software testing, Part 3: Test documentation*.

## Standard and licence note

Structure aligned with ISO/IEC/IEEE 29119-3, *Software and systems
engineering: Software testing, Part 3: Test documentation*, test plan
information item. This template is original text written for this
collection and reproduces no text from the standard; obtain the standard
from ISO, IEC or IEEE for its normative requirements. Template licence: MIT.