<!-- Test plan template by BugsQA (bugsqa.com/test-plan-template/), based on ISTQB CTFL v4.0.1 and ISO/IEC/IEEE 29119-3. Free to use and share. -->
# Test plan: [product or project]

## 1. Document control
<!-- Who owns the plan, which version this is, and who must approve it. Example: Test plan for Acme Shop 2.0 launch. ID TP-ACME-2.0, version 1.0, 14 October 2026. Author: QA lead. Approvers: product owner, engineering lead. -->
- **Plan title:** 
- **Plan ID and version:** 
- **Date:** 
- **Author:** 
- **Approvers:** 
- **Revision history:** 

## 2. Introduction and context
<!-- What is being tested and why, and what the testing is based on. Example: This plan covers testing of the Acme Shop web store and iOS app before the 2.0 launch on 1 December 2026. Test basis: product requirements v3, Figma designs, Jira epics ACME-100 to ACME-180. -->
- **Product and release:** 
- **Purpose of this test plan:** 
- **Test basis (requirements, designs, user stories, contracts):** 

## 3. Scope
<!-- What will be tested and, just as important, what will not, with a reason. Example: In scope: signup, login, password reset, search, cart, checkout, payments, order emails. Out of scope: warehouse integration (tested by the vendor), legacy admin reports (unchanged). -->
- **Features in scope:** 
- **Features out of scope and why:** 
- **Platforms in scope:** 

## 4. Test objectives
<!-- What the testing must prove or find. Example: Confirm core purchase flows work on the agreed devices; find critical and major defects before launch; confirm payments, taxes and emails are correct; confirm WCAG 2.2 AA on key flows. -->
- **Objectives:** 

## 5. Assumptions and constraints
<!-- What you are counting on and what limits the testing. Example: Assumes a stable staging environment with production-like data from 3 November. Constraint: two testers for four weeks; no access to production payments before launch day. -->
- **Assumptions:** 
- **Constraints (time, budget, people, environments):** 

## 6. Test approach
<!-- How you will test. Test levels, types, techniques, manual vs automated, and who tests. Example: System and acceptance testing by an independent QA team. Functional testing with the BugsQA test cases for login, signup, reset, search, cart, checkout and payments; exploratory sessions on new features; automated regression smoke suite on every build; accessibility checks against WCAG 2.2 AA. -->
- **Test levels (component, integration, system, acceptance):** 
- **Test types (functional, regression, compatibility, accessibility, performance, security basics):** 
- **Techniques:** 
- **Manual vs automated split:** 
- **Independence of testing:** 

## 7. Test environments, devices and accounts
<!-- Where testing happens and on what. Example: Staging at staging.acme.example. Devices: iPhone (iOS 27, Safari), Samsung Galaxy (Android 16, Chrome and Samsung Internet), Windows 11 Chrome and Edge, macOS Safari, iPad. Accounts: customer, new customer, admin. Tools: Jira, TestRail, BrowserStack. -->
- **Environments and URLs:** 
- **Devices and browsers:** 
- **Test accounts and roles:** 
- **Tools:** 

## 8. Test data
<!-- The data you need and where it comes from. Never use real customer personal data without permission. Example: Stripe test cards; 50 products incl. out-of-stock and multi-variant; addresses in 5 US states and 4 Canadian provinces; no real customer data on staging. -->
- **Test data needed:** 
- **Source of data:** 
- **Privacy rules:** 

## 9. Entry criteria
<!-- What must be true before testing starts (Definition of Ready in agile teams). Example: Build deployed to staging; smoke tests pass; test accounts and data ready; requirements for the release signed off; known open issues listed. -->
- **Entry criteria:** 

## 10. Exit criteria
<!-- What must be true to call testing done (Definition of Done). Can include accepting risk if time runs out, as long as stakeholders agree. Example: All high priority test cases executed and passed; no open critical (S1) or major (S2) defects; minor defects reviewed and accepted by the product owner; regression suite green on the release candidate. -->
- **Exit criteria:** 

## 11. Suspension and resumption criteria
<!-- When to pause testing, and what is needed to resume. Example: Suspend if the build fails smoke tests or a blocker stops more than 30% of planned tests. Resume when a fixed build passes smoke tests. -->
- **Suspend when:** 
- **Resume when:** 

## 12. Risk register
<!-- Product risks (what could go wrong for users) and project risks (what could stop testing), each with likelihood, impact and response. Example: Payment webhook fails and orders are not created (product; likelihood 2, impact 3, score 6; mitigate with dedicated payment tests and monitoring). Staging unavailable for a week (project; likelihood 1, impact 3; contingency: test on a preview environment). -->
- **Risk:** 
- **Type (product or project):** 
- **Likelihood (1 to 3):** 
- **Impact (1 to 3):** 
- **Score:** 
- **Response:** 

## 13. Roles and responsibilities
<!-- Who does what. A simple RACI works well. Example: QA lead: plan, triage, report. Testers: execute, report bugs. Developers: fix, unit test. Product owner: priorities, acceptance, sign-off. -->
- **Role:** 
- **Name:** 
- **Responsibilities:** 

## 14. Defect management
<!-- How bugs are reported, rated and tracked. Example: Jira. Severity S1 to S4 and priority P1 to P4 (see scales). Workflow: New, Open, In progress, Ready to retest, Closed or Reopened. Daily 15 minute triage during the test window. -->
- **Tool:** 
- **Severity scale:** 
- **Priority scale:** 
- **Workflow:** 
- **Triage meeting:** 

## 15. Communication and reporting
<!-- How and how often the team hears about testing progress. Example: Daily summary in Slack; weekly report with tests run, pass rate, open defects by severity; final test summary report before go or no-go. -->
- **Status report cadence:** 
- **Channels:** 
- **Metrics:** 

## 16. Test deliverables
<!-- What testing will produce. Example: This test plan, test cases, bug reports, daily status, test summary report, go or no-go recommendation. -->
- **Deliverables:** 

## 17. Schedule and milestones
<!-- Key dates for testing. Example: Test cases ready 31 Oct; testing 3 to 21 Nov; regression 24 to 26 Nov; go or no-go 27 Nov; launch 1 Dec. -->
- **Milestone:** 
- **Date:** 

## 18. Budget and effort (optional)
<!-- Estimated effort or cost. Example: Two testers for four weeks (about 320 hours) plus a device cloud subscription. -->
- **Effort estimate:** 
- **Budget:** 

## 19. Approval and sign-off
<!-- Who agrees to the plan and, at the end, to release. Example: Product owner, engineering lead, QA lead. -->
- **Name:** 
- **Role:** 
- **Signature or approval date:** 

## 20. Glossary and references
<!-- Terms and documents the reader may need. Example: Severity, priority, regression, smoke test, UAT. References: requirements v3, design files, release notes. -->
- **Terms:** 
- **Referenced documents:**