Free test plan template and generator
Answer five quick questions and get a complete software test plan, with every section a QA lead would include, ready to paste into Google Docs, Word or Confluence. Full, one-page, UAT, regression and agile plans. Free, no signup.
- 1Answer 5 questions
- 2Get the full plan
- 3Fill the gaps, share it
What you get, ready for Google Docs or Word:
Test plan: Acme Shop
- 1. Document control
- 2. Introduction and context
- 3. Scope
- 4. Test objectives
- 5. Assumptions and constraints
- 6. Test approach
- 7. Test environments, devices and accounts
- 8. Test data
- 9. Entry criteria
- 10. Exit criteria
- 11. Suspension and resumption criteria
- 12. Risk register
- 13. Roles and responsibilities
- 14. Defect management
- 15. Communication and reporting
- 16. Test deliverables
…and 4 more, with gaps to fill marked Confirm.
Test plan generator
Answer five quick questions and get a complete test plan, with every section a QA lead would include. Anything we cannot know is marked "Confirm" so you can fill it in. Nothing you type leaves your browser.
How the test plan generator works
It drafts the plan the way an experienced QA lead would: the structure from the international standard, the scope and risks from your features, and the devices from current US and Canadian market data. You add what only you know.
- 1
Answer five questions
What you are testing, what kind of plan you need, which features are in the release, where it runs, and (if you know them) the dates and the QA lead.
- 2
Get every section filled in
The plan builds itself with all 20 sections, from scope and environments to risks and sign-off. The features you pick fill the scope and the risk register; the platforms fill the devices to test on.
- 3
Fill the gaps and share it
Anything only you can know is highlighted as "Confirm". Copy the plan into Google Docs, Word or Confluence, fill those in, and send it for approval.
Follows the standardSections from the ISTQB Foundation syllabus and ISO/IEC/IEEE 29119-3.
Honest about gapsIt never invents your dates, names or rules; it marks them "Confirm".
PrivateRuns in your browser. Nothing about your project is sent to us.
Remembers your answersCome back later and your plan is still there.
What a test plan includes
The 20 sections of a complete test plan, based on the typical content in the ISTQB Foundation Level syllabus (v4.0.1, section 5.1) and the ISO/IEC/IEEE 29119-3 standard for test documentation. Smaller plans use fewer; see the one-page version below.
- 1
Document control
Who owns the plan, which version this is, and who must approve it.
- 2
Introduction and context
What is being tested and why, and what the testing is based on.
- 3
Scope
What will be tested and, just as important, what will not, with a reason.
- 4
Test objectives
What the testing must prove or find.
- 5
Assumptions and constraints
What you are counting on and what limits the testing.
- 6
Test approach
How you will test. Test levels, types, techniques, manual vs automated, and who tests.
- 7
Test environments, devices and accounts
Where testing happens and on what.
- 8
Test data
The data you need and where it comes from. Never use real customer personal data without permission.
- 9
Entry criteria
What must be true before testing starts (Definition of Ready in agile teams).
- 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.
- 11
Suspension and resumption criteria
When to pause testing, and what is needed to resume.
- 12
Risk register
Product risks (what could go wrong for users) and project risks (what could stop testing), each with likelihood, impact and response.
- 13
Roles and responsibilities
Who does what. A simple RACI works well.
- 14
Defect management
How bugs are reported, rated and tracked.
- 15
Communication and reporting
How and how often the team hears about testing progress.
- 16
Test deliverables
What testing will produce.
- 17
Schedule and milestones
Key dates for testing.
- 18
Budget and effort (optional)
Estimated effort or cost.
- 19
Approval and sign-off
Who agrees to the plan and, at the end, to release.
- 20
Glossary and references
Terms and documents the reader may need.
How to write a test plan, step by step
A good test plan is the testing part of the release decision, written down before anyone is under pressure. Here is the order QA leads work in.
- 1
Agree what is being tested and why
Name the product and release, and what the testing must prove: that customers can check out, that the new app works on the agreed phones, that nothing old broke.
- 2
Draw the scope, in and out
List the features in scope and, just as important, what is out of scope and why. Out-of-scope items written down stop arguments later.
- 3
Choose the approach
Which kinds of testing (functional, regression, compatibility, accessibility, security basics), manual or automated, and who tests. The approach follows the risks.
- 4
List environments, devices and test data
Where testing happens, which browsers, phones and OS versions, which accounts and roles, and what test data is needed. Never real customer data.
- 5
Set entry and exit criteria
When testing can start (a stable build that passes a smoke test) and when it is done (no open critical bugs, high priority test cases passed). Exit criteria are the release decision written down in advance.
- 6
Write the risk register
What could go wrong for users and for the project, how likely and how bad, and what you will do about each. Risky features get the most testing.
- 7
Name the people and the schedule
Who does what, how bugs are reported and triaged, how often status is shared, and the dates for testing, regression and the go or no-go decision.
- 8
Get it approved, then keep it alive
The product owner and engineering lead sign off. When scope or dates change, update the plan so it stays the source of truth.
Download a blank test plan template
Every section with a short explanation and an example, ready to fill in. Free to download, no email needed.
WordTest plan template for Word and Google DocsAll 20 sections with a short note and an example in each. Opens in Google Docs too.DownloadExcelTest plan template for ExcelThe plan on one sheet, plus a risk register that scores each risk and a schedule tracker.DownloadMarkdownTest plan template in MarkdownFor Notion, GitHub or any wiki that reads Markdown.Download
QA testing by BugsQA
Want a QA team to run the plan?
A test plan is only as good as the testing behind it. BugsQA writes the plan with you, runs it on real phones and browsers, and gives you a clear go or no-go before release.
- Test plan and test cases written for you
- Real iPhones, Android phones and browsers
- Daily status and a go or no-go report
- US and Canadian time zones
Talk to a QA lead, free
A 30-minute call. We look at your app and tell you what to test first, even if you test it yourself.
Get a free QA consultationSee pricingTest plan example
A filled-in example for the launch of an online store, section by section. Use it to see the level of detail each part needs.
Test plan for Acme Shop 2.0
- 1.Document control
- 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.
- 2.Introduction and context
- 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.
- 3.Scope
- 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).
- 4.Test objectives
- 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.
- 5.Assumptions and constraints
- 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.
- 6.Test approach
- 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.
- 7.Test environments, devices and accounts
- 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.
- 8.Test data
- 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.
- 9.Entry criteria
- Build deployed to staging; smoke tests pass; test accounts and data ready; requirements for the release signed off; known open issues listed.
- 10.Exit criteria
- 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.
- 11.Suspension and resumption criteria
- 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.
- 12.Risk register
- 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).
- 13.Roles and responsibilities
- QA lead: plan, triage, report. Testers: execute, report bugs. Developers: fix, unit test. Product owner: priorities, acceptance, sign-off.
- 14.Defect management
- 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.
- 15.Communication and reporting
- Daily summary in Slack; weekly report with tests run, pass rate, open defects by severity; final test summary report before go or no-go.
- 16.Test deliverables
- This test plan, test cases, bug reports, daily status, test summary report, go or no-go recommendation.
- 17.Schedule and milestones
- Test cases ready 31 Oct; testing 3 to 21 Nov; regression 24 to 26 Nov; go or no-go 27 Nov; launch 1 Dec.
- 18.Budget and effort (optional)
- Two testers for four weeks (about 320 hours) plus a device cloud subscription.
- 19.Approval and sign-off
- Product owner, engineering lead, QA lead.
- 20.Glossary and references
- Severity, priority, regression, smoke test, UAT. References: requirements v3, design files, release notes.
Test plan templates for every kind of project
The same structure, tuned for the job. Each one opens in the generator with the right settings.
Website test plan template
A website test plan focuses on what visitors see and do: content, links, forms, browsers and devices, speed, SEO basics and accessibility, plus the launch itself (redirects, analytics, monitoring). Scope and environments matter most, because most website bugs depend on the browser and screen size.
Sections that matter most
- Scope
- Test environments, devices and accounts
- Exit criteria
UAT test plan template
A user acceptance testing (UAT) plan is for business users, not testers. It lists the real tasks they will try, written as user stories with acceptance criteria, who takes part, how they report problems, and who signs off. Keep the language plain: the people running UAT are experts in the business, not in QA.
Sections that matter most
- Scope
- Roles and responsibilities
- Exit criteria
- Approval and sign-off
Agile test plan template
In agile teams the test plan is short and living: one per sprint or release, tied to the Definition of Ready (what a story needs before work starts) and the Definition of Done (what must pass before it ships). Testing happens inside the sprint, story by story, with a regression check before the review.
Sections that matter most
- Scope
- Test approach
- Entry criteria
- Exit criteria
One-page test plan template
For small releases and small teams, a one-page test plan covers what matters: scope, approach, environments, entry and exit criteria, risks, schedule and owners. It is quick to write and, more importantly, people actually read it.
Sections that matter most
- Scope
- Test approach
- Entry criteria
- Exit criteria
- Risk register
Regression test plan template
A regression test plan answers one question: after this change, does everything that used to work still work? It selects existing test cases by risk (core flows, recently changed areas, areas with past bugs), runs a smoke test on every build, and automates the stable, repeated checks.
Sections that matter most
- Test approach
- Risk register
- Exit criteria
Mobile app test plan template
A mobile app test plan adds what websites never need: iOS and Android versions and devices, permissions, interruptions like calls and notifications, offline use, app updates, and the App Store and Google Play rules (for example, from 31 August 2026 Google Play requires new apps and updates to target Android 16).
Sections that matter most
- Test environments, devices and accounts
- Risk register
- Exit criteria
API test plan template
An API test plan covers the endpoints and their contract (usually an OpenAPI file), status codes, validation, authentication and authorization, rate limits, performance and versioning. Security deserves its own line: broken object level authorization is the top risk in the OWASP API Security Top 10.
Sections that matter most
- Scope
- Test approach
- Test data
Test plan vs test strategy
The two are often confused. The strategy is the general approach and changes rarely; the plan applies it to one project or release.
Test strategy
How a company or product tests in general: the kinds of testing, tools, automation approach, environments and quality standards.
Long-lived. Written once, reviewed yearly or when the way of working changes.
Test plan
How one project or release will be tested: scope, schedule, people, devices, risks and the criteria for "done".
Short-lived. One per release or project, updated as the project changes.
Once the plan is approved, the next step is writing the test cases for each feature in scope. The free test case template and generator has ready-made test cases for login, checkout, payments, mobile apps, APIs and more. When a test fails, use the bug report template.
Rather have a QA team plan and run it?
BugsQA writes the test plan with you, runs it on real phones and browsers, and gives you a clear go or no-go before release.
Frequently asked questions
What should a test plan include?
A test plan includes the scope (what is and is not tested), the test objectives, assumptions and constraints, the test approach, environments and devices, test data, entry and exit criteria, a risk register, roles and responsibilities, defect management, communication, deliverables, the schedule and an approval section. This follows the typical content in the ISTQB Foundation syllabus and the ISO/IEC/IEEE 29119-3 standard.
How do you write a test plan?
Agree what is being tested and why, draw the scope in and out, choose the approach based on the risks, list the environments, devices and test data, set entry and exit criteria, write the risk register, name the people and the schedule, and get it approved. The generator on this page does the first draft from five questions.
What is the difference between a test plan and a test strategy?
A test strategy is the general approach to testing for a product or a whole company, and it rarely changes. A test plan applies that strategy to one project or release, with its own scope, dates, people and risks. Small teams often skip the separate strategy and put the approach straight into the test plan.
Who writes the test plan?
Usually the QA lead or test manager writes it, with input from the product owner (scope and priorities) and the developers (environments and risks). The product owner and engineering lead approve it.
How long should a test plan be?
As long as it needs to be read. A one-page plan works for small releases and sprints; a full plan of several pages suits bigger launches, regulated products or work with outside teams. If nobody reads it, it is too long.
Is this test plan template free?
Yes, free with no signup. The generator runs in your browser, so nothing about your project is sent to BugsQA, and the Word, Excel and Markdown templates are free to download and share.
Build your QA plan