It’s two days until release day. 50% of the test cases do not have an owner. There is no consensus on whether the payment gateway is in scope. There are no set criteria for exiting. That’s what a missing QA test plan would be like.
A QA test plan is a document that defines your test plan, how you’re going to test it, who’s going to do it, and when it’s going to be done. It provides a single source of reference for testers, developers and project managers.
Without it, scope veers off course in the middle of the sprint and bugs become visible at the end of the sprint.
The Consortium for Information and Software Quality estimates the cost to the United States of poor software quality at $2.41 trillion or more in 2022. Having a written QA testing plan allows you to minimize the number of defects that will be added.
This guide describes the contents of a quality assurance test plan and how it differs from a test strategy. It walks you through 14 steps to write one, and demonstrates how to execute the plan in Kualitee.
What Is a QA Test Plan?
A QA test plan is a document that establishes the objectives, scope, approach, resources, and timeline of testing a product. To replace the previous default IEEE 829 format for test documents, the ISO/IEC/IEEE 29119-3 standard has been adopted.
Most teams follow that format, but they customize it to their projects.
The plan has only one goal. Before testing, it helps the team to establish goals, restrictions, and responsibilities. The approach is reviewed by the stakeholders early on. The team then monitors progress against a written baseline.
Test Plan vs. Test Strategy: What Is the Difference?
A test strategy provides the overall direction of a company or product line in terms of testing. A QA test plan is the same concept as the test strategy but specific to one project or release. The strategy remains unchanged. The plan changes with each project.
| Aspect | QA Test Plan | Test Strategy |
| Purpose | Describes how testing runs for one project or release | Sets testing principles for the whole company or product line |
| Scope | Features, environments, schedule, and resources for one release | Test levels, test types, tools, and standards for all projects |
| Owner | QA lead or test manager | QA head, test architect, or senior management |
| Project-specific | Yes | No, it applies to every project |
| Updates | Revised when scope, schedule, or risks change | Changes rarely, usually after a process or tooling change |
When Do You Write a Test Plan in Software Testing?
Write the plan after the requirements are baselined and prior to beginning test case design. It is written by waterfall teams after the requirements phase. The agile team creates a brief plan during release planning and revises that plan at the end of each sprint.
Who Writes a QA Test Plan?
The plan is written by the QA lead or test manager. The developers provide the build and environment information. Product Owners confirm scope and priorities. Project managers validate the agenda. The final document is approved by the stakeholders.
Planning a test is one phase in a longer process. In our guide to the software testing life cycle, it shows how test planning fits in with requirements analysis and test closure.
Why Is a QA Test Plan Important?
A QA test plan reduces rework, shrinks the surprises of a schedule and reduces audit risk. Business impacts are shown for each benefit below.
Improves Software Quality
Prior to testing, the plan identifies what is included, what types to run, and what criteria will need to be met to pass the test. Testers make sure that each requirement is met by a defined criterion. Defects in production are reduced.
The business saves on its hot fixes, support tickets, and customer credits.
Reduces Project Risks
Threats are identified early in the risk section. This can include unstable environments, late builds, and the lack of testers. Owners and fallbacks are assigned to each risk. Managers see schedule problems weeks before release, while a fix is still cheap.
Improves Communication
The plan is one document shared by QA, Developers, Product Owners and Project Managers. If there is any disagreement about scope or readiness, the dispute is resolved by agreeing to text. Meetings get shorter. Sign-off comes faster.
Increases Testing Efficiency
Clear scope and priorities focus effort on high-risk areas. The team doesn’t re-check the same items and the team has items outside the release. The same hours discover more beneficial defects.
Ensures Complete Test Coverage
Mapping requirements to test types shows gaps early. A requirement with no planned test is visible on paper before it fails in production. Coverage targets give managers a number to track.
Supports Agile and Waterfall Projects
A Waterfall plan documents all of the test effort in one place.
An Agile plan is concise and is subject to change on a sprint-by-sprint basis. Both provide a common notion of done for the team.
Improves Resource Planning
The schedule and roles sections indicate the required number of testers, environments, and tools for a release.
Leadership of delivery can approve headcount or tool spend before the bottleneck has formed.
Meets Compliance Requirements
Evidence of planned testing must be demonstrated by banking, healthcare and government teams. Documented testing is required in secure development as required by frameworks such as PCI DSS and ISO/IEC 27001.
An approved plan with attached requirements provides auditors with evidence. It also avoids delays in releases due to missing records. As tests change over time, those links are maintained in your test management tool via requirement traceability.
What Should a Software Test Plan Include?
There are 13 sections in a software test plan. For smaller projects, you may only have a single short project.
Project Overview
Summarize what the application is and the primary processes and users of the application. New team members and reviewers get context fast.
Scope
List the features and platforms to test on. State what isn’t included, such as a third-party payment gateway.
A written exclusion will save you from the hassle of future arguments.
Objectives
Outline the aims of testing. For example, 95% of the test items that are most important belong to the passed component prior to release. Limit objectives to one per meeting and make them specific and measurable.
Test Strategy
Identify test levels, test types and methods. Explain manual testing and automated testing.
Test Environment
List the hardware, operating systems, browsers, devices, and integrations. State how similar the environment is to production.
Test Data
Cover valid/invalid accounts, edge cases, and masked production records. Indicate the source of the data and how it is updated.
Resources and Roles
List the names of each tester, lead, and approver, and include their responsibilities.
Document remaining training and/or tool access requirements.
Schedule
Establish a timeframe for planning, design of the test, conducting the test, and reporting. Describe dependencies (e.g., environment requirements prior to execution).
Risk Assessment
Give each risk a probability, an impact, an owner, and a mitigation step. Common risks are late builds, unstable environments, and staff absence.
Defect Management
Define how defects are logged and triaged. Set severity and priority levels, and name the tracking tool. A defect management tool that links each bug to the test that found it speeds up triage.
Entry and Exit Criteria
Entry criteria say when testing may begin, such as a stable build and approved test cases. Exit criteria say when testing may end, such as no open critical defects. Suspension and resumption criteria say when testing pauses and restarts.
Deliverables
Deliverables are the documents QA produces. They include test cases, test data, defect reports, a requirements traceability matrix, and the final test summary.
Reporting
Set the metrics, format, frequency, and audience for status updates. Common metrics are execution progress, pass rate, and defect trends. Customizable reporting cuts the manual spreadsheet work.
Test Plan Sections at a Glance
| Section | Purpose | Why It Matters |
| Project Overview | Gives context on the product and users | Aligns reviewers before they read details |
| Scope | Sets what is and is not tested | Prevents scope creep and coverage gaps |
| Objectives | States measurable testing goals | Defines what success looks like |
| Test Strategy | Names levels, types, and methods | Keeps testing consistent across the team |
| Test Environment | Lists hardware, software, and integrations | Makes results reproducible and realistic |
| Test Data | Defines the data used in each scenario | Avoids blocked tests and privacy exposure |
| Resources and Roles | Assigns people and responsibilities | Removes ownership gaps |
| Schedule | Sets dates and dependencies | Exposes timeline risk early |
| Risk Assessment | Records threats and mitigations | Lets management act before delays occur |
| Defect Management | Defines the defect workflow | Speeds triage and fixes |
| Entry and Exit Criteria | Sets start, pause, resume, and stop conditions | Gives a clear release decision rule |
| Deliverables | Lists documents produced by QA | Creates an audit record |
| Reporting | Defines metrics and update cadence | Keeps stakeholders informed |
How to Write a QA Test Plan (Step-by-Step)
In this 14-step process, a team moves from initial requirements to an approved plan.
Each step has an example you can adapt.
Step 1: Understand the Project Requirements
Read through business requirements, software requirements specification, user stories and design files. Discuss with product owners and developers if unclear.
Example: A $10,000 per day transfer limit is set as a boundary test condition.
In Kualitee, requirement management lets you create or input user stories and link test suites to them.
Step 2: Define the Testing Scope
Identify features, platforms, and types of tests covered. Give a list of the exclusions and why each is excluded. State that the card tokenization is done by a third party.
Then, Tokenization is not in scope, and the integration call to that provider remains in scope.
Step 3: Set Testing Objectives
For each objective, specify it in the SMART format: specific, measurable, achievable, relevant and time-bound.
A sample objective: execute all critical and high-priority test cases and close all critical defects before the release date.
Step 4: Choose the Testing Strategy
Select Test Levels: Unit, Integration, System, and Acceptance.
Select the types of tests to apply: functional, regression, performance, security and accessibility.
Automate stability testing, e.g., regression suites.
Exploratory testing with new features.
Kualitee’s automation testing integrations report results from Selenium, Playwright, Cypress, and Appium in the same workspace as your manual runs.
Step 5: Prepare Environments and Test Data
Simulate the test environment in browsers, operating systems, and integration versions. Use masked or synthetic data. There should be no real customer records in a test system.
Schedule refresh of the data.
Step 6: Identify Risks
Note each risk and its probability, impact, owner, and mitigation. Take a third-party sandbox that goes down. Medium chance of happening. Integration tests are temporarily disabled. The mitigation is a set of service virtualisation stubs.
Step 7: Assign Roles
Identify the QA lead, test engineers, automation engineers, and QA approvers. Describe the responsibilities of each person and their availability. Enhance defect support for developers.
In Kualitee, it is possible to assign test cycles to testers and have test managers review and approve test cases by working on the collaborative test design.
Step 8: Define the Defect Workflow
Explain the defect life cycle and reopened path: New, Assigned, Fixed, Retested and Closed.
Define severity levels. If there is any data loss or payment failure, it is considered critical.
Establish a response time for each level and label the tracking tool.
Kualitee has native two-way sync with Jira, so defects stay in sync across both tools.
Step 9: Create the Testing Schedule
Split the work into planning, test design, environment setup, execution cycles, regression, and sign-off. Include buffer time to retest.
Look at each person’s availability and compare it with the dates.
Step 10: Define Entry and Exit Criteria
An entry rule: the build is deployed, the smoke test passed, and test cases are approved. An exit rule: all high-priority cases ran, no critical or high defects are open, and the regression suite passed. A blocking exception: a login exception that blocks entry to the login. A fix that has been verified and is a resumption rule.
Step 11: Document the Deliverables
Indicate each artifact and its owner and due date. Typical artifacts are test cases, automation scripts, a requirements traceability matrix, defect reports, and a test summary report. The requirements or UI screenshots are turned into test cases by Hootie AI. Your team critiques and edits the draft.
Step 12: Set the Reporting Process
Determine who is receiving the reports, when and what their format is. For example, create an execution dashboard for the project team on a daily basis and a weekly summary to executives. Monitor pass rate, open defects by level and progress of execution.
Step 13: Plan the Post-Test Review
Schedule a retrospective after release. Record what worked and what failed. Note the changes the team will make to the plan for the next release.
Step 14: Review the Plan With Stakeholders
Walk developers, product owners, project managers, and compliance staff through the plan. Record their comments and approvals with dates. Version the document so later changes are traceable.
Software Test Plan Example for a Fintech Payments Release
This example applies the steps to a fictional release called Funds Transfer 2.0 in a mobile banking app. All figures are illustrative.
Finance teams can also observe how Kualitee for FinTech helps them in such a release.
Scope and Objectives
- In scope: domestic and international transfers, daily limit checks, two-factor confirmation, push notifications, and the two latest versions of iOS and Android.
- Out of scope: card issuing and core ledger internals. The vendor tests those.
- Objective 1: Execute all critical and high-priority test cases and resolve all critical and high defects prior to release.
- Objective 2: The transfer API is able to respond within 2 seconds for 500 concurrent users.
- Objective 3: All the requirements are mapped to at least one test case in the traceability matrix.
Risk Register
| Risk | Probability | Impact | Mitigation |
| Payment gateway sandbox is down | Medium | Integration tests are blocked | Use service virtualization stubs and agree on an uptime window with the vendor |
| Build arrives late | High | Execution time shrinks | Set a code freeze date and run a smoke test on every build |
| Real customer data appears in test systems | Low | Privacy and compliance breach | Use masked data and restrict environment access |
| Android device fragmentation | Medium | Device-specific defects escape | Pick test devices from usage analytics |
Entry, Exit, and Suspension Criteria
- Entry: Build is deployed to the QA environment, the smoke test is passed and test cases are approved.
- Exit: All high-priority cases are run and there are no critical or high defects open. The regression suite passes.
- Suspension: An execution problem when logging on or transferring confirmation is blocked.
A bank or fintech team would also add evidence of PCI DSS-related checks along with an audit trail of approvals.
Agile vs. Scrum vs. Waterfall QA Test Planning
The development model decides how long the plan is and how often it changes. The waterfall teams write a single detailed plan.
In Agile and Scrum teams, a short plan is written and changes are made in each iteration.
| Aspect | Waterfall | Agile | Scrum |
| Test planning | One detailed plan written after requirements are baselined | Lightweight release-level plan updated each iteration | Release-level plan plus a sprint test plan drawn up in sprint planning |
| Documentation | Formal and detailed, often following ISO/IEC/IEEE 29119-3 | Concise, often one or two pages or a wiki page | Test approach recorded in the Definition of Done and the sprint backlog |
| Changes | Handled through formal change requests | Expected, and the plan is revised as priorities shift | Handled at sprint boundaries, with the product owner approving scope shifts |
| Release cycle | One release after a long test phase | Frequent small releases | A potentially releasable increment each sprint |
| Testing timing | After development finishes | Alongside development | Inside every sprint |
Waterfall Test Planning
Requirements are specified prior to development. The plan may be developed from day one. Testing is performed after the build is complete. Changes are subject to a formal approval process.
Agile Test Planning
The plan includes the plan to test the approach, risks and environments to use for the release. It gets more detailed over time. Testers participate in the planning meetings and create test cases as stories are evolved. An agile test plan template should be kept short to ensure the test team is able to maintain it.
Scrum Test Planning
According to the Scrum Guide, the Sprint is an event that always has a fixed duration of 1 month or less. During Sprint Planning, the Sprint team determines the test scope for the Sprint.
Test completion criteria go into the Definition of Done. Every backlog item then meets them.
QA Test Plan Template for Software Projects
Common QA Test Plan Mistakes
Eight gaps weaken a QA test plan. Each has a direct fix.
Unclear Objectives
Non-specific objectives like “improve quality” do not provide any means to measure success.
Fix: Number each objective and set a deadline for each, and make sure it is aligned with exit criteria.
Undefined Scope
When testing goes out of the box, some features get tested, and some do not.
Fix: Add inclusions and exclusions, and get the product owner’s sign-off on inclusions and exclusions.
Missing Risk Assessment
A plan that contains no risk section will not show a threat until it causes a delay.
Fix: Conduct a brief risk session with developers and QA, and document the likelihood, severity, who is responsible for the risk, and who will be responsible for the risk mitigation.
Poor Resource Planning
Plans that fail to consider the capacity of the environment and whether the tools are available for testing stall during execution.
Fix: make sure to check the schedule against physical calendars and verify environments prior to the start date.
No Traceability
If there is no connection between the test cases and the requirements, then no one can claim coverage.
Fix: maintain a requirements traceability matrix and review it at each milestone. It’s always up to date because it has traceability built in.
Unrealistic Timelines
If there is no retesting and regression, there’s no place for defects that are found during testing.
Fix: include buffer in fix-and-verify cycles, and rely on the team’s previous velocity to make estimates.
Ignoring Stakeholder Reviews
If only QA has read the plan, it gets challenged at release time.
Fix: Discuss with the developers, product owners, and compliance staff and document the approval.
Treating the Plan as a One-Time Document
A plan that is written once and filed away is out of date by the second sprint.
Fix: Version the document, set an owner, and review at all Milestone or Sprint boundaries. A short plan is easier to maintain.
How to Run Your QA Test Plan in Kualitee
A plan in a document is a starting point. The work occurs in your test cases, cycles, and defects. Kualitee links those pieces together to keep the plan visible during tests.
| Plan Section | What You Do in Kualitee |
| Scope and requirements | Create or import user stories and link test suites to them with requirement management |
| Test cases | Draft test cases from requirements or UI screenshots with Hootie AI |
| Roles and cycles | Assign test cycles to testers and route test cases to managers for approval with collaborative test design |
| Automation | Report Selenium, Playwright, Cypress, and Appium results through automation testing integrations |
| Defects | Link bugs to the tests that found them, with two-way Jira sync |
| Reporting | Build status and closure reports with customizable reporting |
Kualitee monitors execution of your plan. Your team determines the scope, risks, and criteria.
Start Kualitee free, or check the pricing for the team that can be suitable for you.
Conclusion
The starting point of software testing is a QA test plan. It defines goals, scope, resources, timeframe and strategy for all testers and stakeholders to operate. Risk is reduced by a good plan. Helps to foster collaboration between QA and development. Significant improvement of software quality at release.
The 14 steps, template and checklist provided in this guide provide your team with a full starting point. Consider the plan to be a “living document. Update it when scope shifts, whenever new risks are identified and after each retrospective.
When you are ready to run it, start Kualitee free and connect your requirements, test cases, and defects in one workspace.
