
A test plan template is a document that describes how testing will be done, what will be tested, for how long, how much it will cost, what results can be expected, and what resources will be needed. The test plan determines how much work needs to be done to ensure the software being tested is good. It serves as a manual for conducting specific types of software testing. The test manager keeps a close eye on everything and makes sure it all goes smoothly.
Key takeaways
- Build your test plan online, free. The Test Plan Builder below starts from a ready example (web app, mobile app, API, ERP rollout or agile sprint) and exports to Word, Excel, CSV or PDF, with no sign-up.
- Cover the 10 sections every plan needs. Project info, scope, approach, environment, criteria, roles, schedule, risks, deliverables and approvals follow the contents of a test plan in the current test documentation standard, ISO/IEC/IEEE 29119-3:2021.
- Agree your criteria, do not copy them. Entry, exit, suspension and resumption criteria need thresholds your team and stakeholders accept, based on your risks. A fixed pass rate from another project rarely fits.
- Plan for agile teams too. A sprint or release test plan can be one page: scope the stories, link testing to the Definition of Done and keep the risks and criteria short.
Try our free Test Plan Builder below.
It works in your browser and follows the contents of a test plan in the current test documentation standard, ISO/IEC/IEEE 29119-3:2021, written in plain words. Start from an example (web app release, mobile app, API or integration, ERP rollout or agile sprint), edit the 10 sections, and watch the completeness meter and the live preview update as you type. When you are done, download the plan as a Word file, your test cases as Excel or CSV, or print the plan as a PDF. It suits test managers, QA leads and project managers on waterfall, agile and hybrid teams. Free, no sign-up, and your work stays in your browser. Prefer a file? Download the Word test plan template and the Excel test case tracker below the tool.
All 10 sections are filled. Download your test plan below.
1Project infoDone
2ScopeDone
Features in scope
Features out of scope
3Test approachDone
4Test environmentDone
5CriteriaDone
Add suggestions with one click, then edit them. Text in [brackets] is a placeholder for your own value.
Entry criteria
What must be true before testing starts.
Exit criteria
What must be true to finish testing and move on.
Suspension criteria
When the team pauses testing.
Resumption criteria
What must happen before testing restarts.
6Roles and responsibilitiesDone
7Schedule and estimatesDone
Effort is in person-days. Totals and the timeline update as you type.
The end date is before the start date.
The end date is before the start date.
The end date is before the start date.
The end date is before the start date.
The end date is before the start date.
The end date is before the start date.
The end date is before the start date.
- Total effort
- 52 days
- Calendar span
- 26 days
- First start
- 26 Oct 2026
- Last end
- 20 Nov 2026
8RisksDone
Score = likelihood × impact. 1 to 2 is low, 3 to 4 medium, 6 to 9 high.
9DeliverablesDone
10ApprovalsDone
The document adds a signature and date line for each approver.
11Test casesOptional
Optional. These rows feed the Excel and CSV download and the appendix of the document.
Test plan
Customer portal
1. Project information
| Project | Customer portal |
|---|---|
| Version or release | Release 3.2 |
| Plan type | Master test plan |
| Plan ID and revision | TP-CP-3.2, revision 1.0 |
| Test manager | Alex Morgan |
| Date | 19 Oct 2026 |
2. Scope
In scope
- User sign-up, sign-in and password reset
- Account dashboard and profile settings
- Online invoice payment by card
- Order history search and filters
- Email notifications for orders and payments
Out of scope
- Back-office admin console (covered by its own plan)
- Internal logic of the third-party payment gateway
- Native mobile apps
Test basis
Release 3.2 user stories and acceptance criteria, UI designs v4, payment API contract v2
Assumptions and constraints
A stable build reaches the test environment every Tuesday. Payment tests use the gateway sandbox, never live cards. The same four testers stay for the whole release.
3. Test approach
| Test levels | Integration, System, Acceptance |
|---|---|
| Test types | Functional, Regression, Performance and load, Security, Accessibility, Compatibility |
| Manual vs automated | Manual 60%, automated 40% |
| Tools | Test management tool, a UI automation framework, a load testing tool, browser developer tools, defect tracker |
| Regression approach | Automated smoke suite on every build, full automated regression every night, manual regression of the payment flows before release |
4. Test environment
| Hardware and servers | Staging servers sized like production (2 application nodes, 1 database) |
|---|---|
| Operating systems and browsers | Windows 11 and macOS with the latest two versions of Chrome, Edge, Firefox and Safari |
| Devices | iPhone and Android phones for responsive checks: real devices plus a cloud device farm |
| Test data | Masked copy of production customers, 50 test accounts in different states, sandbox payment cards |
| Access and accounts | Tester accounts with user and admin roles, VPN access to staging, read access to logs |
5. Entry, exit, suspension and resumption criteria
Entry criteria
- The test environment is ready and a smoke test passes
- The build is deployed with release notes
- Test cases are reviewed and approved
Exit criteria
- All planned high-priority test cases have been run
- No open critical or high defects, or each one has an approved workaround
- The regression suite passes on the release candidate
- The test completion report is approved
Suspension criteria
- A blocking defect stops a main user flow
- The test environment is down for more than [your limit] hours
Resumption criteria
- The blocking defect is fixed and the fix is verified
- The environment is restored and a smoke test passes
6. Roles and responsibilities
| Name | Role | Responsibility |
|---|---|---|
| Alex Morgan | Test manager | Owns the plan, schedule and reporting; approves the exit decision |
| Priya Nair | QA engineer | Designs and runs functional and regression tests |
| Tomas Silva | Automation engineer | Maintains UI and API automation; runs the load tests |
| Mei Chen | Product owner | Clarifies acceptance criteria; leads user acceptance |
| Samuel Okafor | Development lead | Fixes defects; supports builds and the environment |
Status reporting
Daily status in the team channel, weekly test report to the sponsor, defect triage on Monday and Thursday
7. Schedule and estimates
| Activity | Start | End | Effort (days) |
|---|---|---|---|
| Test planning and design | 26 Oct 2026 | 30 Oct 2026 | 6 |
| Environment and test data setup | 28 Oct 2026 | 30 Oct 2026 | 3 |
| System test cycle 1 | 2 Nov 2026 | 6 Nov 2026 | 16 |
| Performance and security tests | 5 Nov 2026 | 6 Nov 2026 | 6 |
| System test cycle 2 (regression) | 9 Nov 2026 | 13 Nov 2026 | 12 |
| User acceptance testing | 16 Nov 2026 | 20 Nov 2026 | 8 |
| Test completion report | 20 Nov 2026 | 20 Nov 2026 | 1 |
Total effort: 52 days | Calendar span: 26 days (26 Oct 2026 to 20 Nov 2026)
8. Risks
| Risk | Likelihood | Impact | Score | Mitigation |
|---|---|---|---|---|
| Late delivery of the payment feature shortens test time | 3 | 3 | 9 High | Test payments first in each cycle; agree a cut-off date with development |
| Peak load cannot be reached in the test environment | 2 | 3 | 6 High | Scale staging for the test window; compare results with production metrics |
| Staging data drifts away from production | 2 | 2 | 4 Medium | Refresh the masked data before each cycle |
| A key tester is unavailable during cycle 2 | 1 | 2 | 2 Low | Pair testers on the payment flows; keep test cases detailed |
9. Test deliverables
Before testing
- Test plan
- Test cases
- Test data requirements
- Test environment readiness check
During testing
- Test execution log
- Defect reports
- Status reports
- Traceability matrix
After testing
- Test completion report
- Final defect list with status
- Release recommendation
- Lessons learned
10. Approvals
| Name | Role | Signature | Date |
|---|---|---|---|
| Alex Morgan | Test manager | ||
| Mei Chen | Product owner | ||
| Lena Fischer | Project sponsor |
Appendix A. Test cases
| ID | Feature | Steps | Expected result | Priority | Status | Tester |
|---|---|---|---|---|---|---|
| TC-001 | User sign-up, sign-in and password reset | 1. Open the sign-up page 2. Enter a valid email and password 3. Open the confirmation link | The account is created and the user lands on the dashboard | High | Pass | Priya Nair |
| TC-002 | User sign-up, sign-in and password reset | 1. Request a password reset 2. Open the reset link after it has expired | The link is rejected with a clear message and a new link can be requested | Medium | Not run | Priya Nair |
| TC-003 | Online invoice payment by card | 1. Open an unpaid invoice 2. Pay with a valid sandbox card | Payment succeeds, the invoice shows Paid and a receipt email is sent | High | Fail | Tomas Silva |
| TC-004 | Online invoice payment by card | 1. Pay with a card that the sandbox declines | A clear error shows, nothing is charged and the invoice stays Unpaid | High | Pass | Tomas Silva |
| TC-005 | Order history search and filters | 1. Filter orders by date range and status | Only matching orders show and the count is correct | Medium | Blocked | Priya Nair |
| TC-006 | Account dashboard and profile settings | 1. Change the language and email preferences 2. Sign out and sign in again | The new settings are saved and applied | Low | Not run | Priya Nair |
Test plan built with the free Test Plan Builder from ProjectManagers.net
The section structure follows the contents of a test plan described in the current test documentation standard (ISO/IEC/IEEE 29119-3:2021), in plain words. Your plan is saved in this browser only.
Download the free test plan templates
Prefer to start from a file? Both templates are free, with no sign-up, and open in Word, Excel, Google Docs and Google Sheets.
Test plan template
The 10 sections with short guidance in each, editable tables, a risk scoring key and a filled example for a web app release.
Download the Word templateTest case and execution tracker
Test cases with priority and status dropdowns, and a summary sheet that counts pass, fail, blocked and not run and works out the pass rate.
Download the Excel trackerOr build your plan online with the Test Plan Builder above and download it as Word, Excel or PDF.
A practical test plan is a document that changes as the project progresses. It is the basis for how a quality assurance team plans and approaches testing. The QA team (and sometimes people from other teams) helps the QA managers or team leads make the plan. The project should be finished in no more than one-third of the allotted time.
However, the test plan is also given to project managers, business analysts, development teams, and other team members involved. The main goal of this is to make QA activities transparent so that everyone involved is aware of how the software will be tested.
Types of Test Plans
The three different kinds of test plans are listed below.

Master Test Plan
It’s a specific kind of test plan that includes incremental tests at different levels. It encompasses the full test strategy, providing a comprehensive overview of all testing activities, methodologies, and resources required to ensure thorough quality assurance throughout the entire software development lifecycle.
Phase Test Plan
It is a specific type of test plan that addresses every phase of the testing strategy, from initial planning to final execution. Examples of these plans include detailed lists of test cases, the tools needed to run tests, expected outcomes, and the resources required to complete each testing phase successfully.
Specific Test Plans
It’s designed for the most common kinds of testing, such as performance testing, security testing, load testing, and so on. In other words, it is a particular test plan used to test non-functional features, ensuring the software meets quality standards related to speed, reliability, and overall system stability.
Test Plan Major Attributes
The test plan comprises various parts that help us understand the whole testing process. Some of the most important testing attributes are given below in detail:
| Section | What to write | Example |
|---|---|---|
| 1Project info | Project name, version or release under test, test manager, date and the type of plan (master, level or phase, specific, sprint) | Customer portal, Release 3.2, master test plan |
| 2Scope | Features in scope and out of scope, with a reason for each exclusion, plus the test basis and your assumptions | In: online invoice payment. Out: native mobile apps (separate release) |
| 3Test approach | Test levels and test types, the planned share of manual and automated testing, tools and how regression runs | System and acceptance levels; 60% manual, 40% automated; nightly regression |
| 4Test environment | Hardware, operating systems and browsers, real devices or emulators, test data and access | Staging sized like production; masked customer data; sandbox payment cards |
| 5Criteria | Entry, exit, suspension and resumption criteria the team can check with a yes or no, with thresholds agreed for your risks | Exit: no open critical or high defects, or each has an approved workaround |
| 6Roles | Who does what, including people outside the test team, and how status is reported | Product owner clarifies acceptance criteria and leads user acceptance |
| 7Schedule and estimates | Test activities with start and end dates and effort in person-days | System test cycle 1: 5 days, 16 person-days |
| 8Risks | Product and project risks, rated by likelihood and impact (1 to 3), with a mitigation for each medium and high risk | Late payment feature (3 x 3 = 9, high): test payments first each cycle |
| 9Deliverables | What the team produces before, during and after testing | Test cases, defect reports, test completion report |
| 10Approvals | Who approves the plan, with signature and date lines | Test manager, product owner, project sponsor |
The sections follow the contents of a test plan described in ISO/IEC/IEEE 29119-3:2021, the current test documentation standard, in plain words. The builder and the Word template on this page use the same 10 sections.
Test Plan Templates in Word Format
- Test Plan Document #1
- Test Plan Sample #2
- Test Plan Template #3
- Software Testing Plan #4
- Test Plan Example #5
- Sample Test Plan Template #6
- Test Plan Template #7
- Test Plan Template #8
- Test Case Example #9
How to Test Plan
The following are the stages involved in developing a test plan:
Product Analysis
It’s the first step toward learning more about the client, the product, and the people who will use it. At this stage, it’s essential to address the following concerns:
- The product’s target audience.
- What is the product’s primary function, exactly?
- Explain the product’s functionality.
- What minimum hardware and software must be used for a successful deployment?
Designing the Test Strategy
When testing software, a test strategy is an essential part of creating an actual test plan. Usually, the test manager creates this high-level document. The following are components of it.
- The goals of the testing effort and how it was carried out.
- It also determines the required cost and effort of testing.
The document must specifically include the following information:
- Scope Definition: It includes both tested and untested hardware, software, and middleware.
- Testing Type Identification: This part talks about the different kinds of testing that will be done during the project. This is essential because each test focuses on finding a unique class of errors.
- Risks and Issues Documentation: This section lists all the problems that could happen during testing, such as missed deadlines, bad project management, and wrong budget estimates, as well as how these problems could affect the finished product or the business.
- Create Test Logistics: It contains a list of the testers’ names or credentials, as well as the kinds of tests they will conduct. Timelines and testing resources are included here as well.
Defining the Test Objectives
During this phase, we will decide how the tests will be conducted and what we expect the results to be. All testing should aim to find as many problems as possible, so the items should:
- List every aspect of the software that needs to be tested (such as the user interface, performance specifications, and functionality).
- Know the standard or desired result for every single software testing requirement. This will act as the standard criterion by which all actual outcomes will be evaluated.
Establish Test Criteria
The guidelines or standards that direct everyone on a testing project on how to carry out their duties are known as test criteria. There are usually two primary evaluation criteria involved in this phase.

- Suspension Criteria: It establishes the standard for terminating all tests. For example, if the QA team found that 50% of all test cases failed, testing would stop until all problems were fixed.
- Exit criteria: The exit criteria show that a project or phase of testing has been finished successfully. These are the intended testing results that must be achieved to proceed to the next stage of development. For instance, an application or software can’t be made available for public use until eighty percent of the test cases pass.
Test Planning Templates in PowerPoint
Resource Planning
This section includes a complete list of everything required to finish the project, such as the workforce, tools, and all the necessary infrastructure for accurate and comprehensive testing. This phase also determines the number of testers and the necessary tools. This helps project managers create a precise project estimate and schedule.
Free resource planning template
Setup Test Environment
The term test environment refers to the combined hardware and software quality assurance professionals use during testing. Real devices should ideally be used as testing environments for testers to see how the software performs in user scenarios. Nothing beats using real devices with natural operating systems and browsers as test environments, even if you perform automation or manual testing. Avoid using emulators or simulators if you value accuracy in your tests. For this mission to be successful, the test and development teams must be able to talk to each other and work well together.
Test Schedule and Estimation
Create a list of subtasks, estimate how much time and effort each will take, and then reassemble the project for test estimation, as given below. The next step is to make a plan to finish all of these jobs by the deadline using the required effort and time. However, the schedule needs input from many different people to be created:
- Factors such as employee availability, working days, project due dates, and daily resource availability need to be considered.
- Possibilities and threats concerning the project have already been assessed.
Test Planning Email Templates
Establish Test Deliverables
Test deliverables for a project are a full list of all the paperwork, equipment, and other things that must be made, given, and kept up-to-date to support testing activities. There are specific test deliverables for each phase of the software development lifecycle. The following deliverables are required before testing:
- Test Design specifications
- Test plans document.
- Test case documents
The following deliverables are required during testing:
- Scenarios for Testing
- Simulators
- Execution logs and error logs.
- Test results
- Traceability Matrix
The necessary deliverables after successful testing are the following:
- Release notes
- Defect Report
- Installation/ Test procedures guidelines
- Test Results/reports
Test Plan Template Excel
- Free Test Plan Excel spreadsheets #1
- Test Case Template #2
- Test Plan Iteration #3
- System Integration Testing Template #4
- Test Plan Excel – Test Case Example #5
- Test Case Planning and Execution Template #6
Test Planning Online Tools
QA Touch
QA Touch is a thorough case management application designed specifically for modern QA teams. Without spending much effort, organizations may streamline their test management procedures. QA Touch provides a complete, integrated testing workspace that works well with third-party apps like GitHub, Slack, and Jira. It also has on-demand test management services.
API DOG
Api Dog is a powerful program that streamlines the design, debugging, and testing of APIs in an efficient and professional manner. It simplifies the development workflow by automatically generating essential documentation, including mock data and test cases, saving developers significant time while ensuring accuracy and consistency throughout the API development process.
Test Lodge
Test Lodge is an intuitive online application designed for efficiently managing test cases. It follows straightforward, user-friendly rules that streamline the testing process, allowing teams to get started right away without any complex setup. Its clean interface ensures a smooth and enjoyable testing experience for all users.
Video About Test Planning
Conclusion
A well-structured test plan is the backbone of any successful software testing process. It ensures that all aspects of the software are thoroughly examined, from functionality to performance. By defining clear objectives, schedules, and resources, test plans help QA teams deliver high-quality products. Whether using Word, Excel, or Google Docs templates, having a solid test plan keeps your entire team aligned and focused.
The variety of test plan templates available — from Master Test Plans to Phase and Specific Test Plans — gives teams the flexibility to choose the right approach for their projects. Each template type serves a unique purpose, helping testers systematically identify and address potential issues. Utilizing these 31 free templates saves valuable time and ensures no critical testing component is overlooked during the software development lifecycle.
Test Plan FAQs
What is meant by a test plan?
A “Test Plan” is a detailed document that outlines the specifics of how a test will be conducted, including its goals, timeline, cost estimates, and other time constraints. It serves as a roadmap for the testing team, ensuring all aspects of the software are systematically evaluated and documented.
What is a test plan in QA?
A quality assurance (QA) test plan is a comprehensive written document that lists all the necessary QA testing steps. It defines the scope, objectives, and approach of testing activities, helping QA teams stay organized, maintain consistency, and ensure that the software meets the required quality standards before release.
What are the five most important components of the test plan?
A test plan’s five most important components are the test strategy, objectives, schedule, estimates, and deadlines. Together, these elements provide a structured framework that guides the testing team, ensures proper resource allocation, defines expected outcomes, and keeps the entire project on track throughout the software development lifecycle.
What is the name of the tool to generate a test plan?
EasyQA is a popular test management tool that makes it easy to create test plans, write test cases, and manage them intuitively. It streamlines the entire testing workflow, allowing teams to collaborate effectively, track progress, and ensure comprehensive test coverage while maintaining clear documentation throughout the project.
Suggested articles:
- Surprising Differences Between Test Plan Vs Test Strategy and Why It Matters
- Project Plan Template For Excel Explained
- Mastering the Testing Pyramid and Software Testing Phases
Shane Drumm, holding certifications in PMP®, PMI-ACP®, CSM, and LPM, is the author behind numerous articles featured here. Hailing from County Cork, Ireland, his expertise lies in implementing Agile methodologies with geographically dispersed teams for software development projects. In his leisure, he dedicates time to web development and Ironman triathlon training. Find out more about Shane on shanedrumm.com and please reach out and connect with Shane on LinkedIn.