Blog
What is Test Planning and 9 Steps to Create a Test Plan
Published on
May 19, 2026
Pricing
A test plan aligns QA, development, and stakeholders on what success looks like before work begins, so everyone knows when testing is on track or done.
A test plan is the document that turns a release, a feature set, or a defined piece of work into a coordinated testing effort. It names what will be tested, by whom, with what approach, against what risks, and to what definition of done. A good test plan is short enough to be read in one sitting and useful enough to be referenced through the work it describes.
The discipline has shifted since the days of hundred-page IEEE 829 plans that nobody read. The modern test plan is a living document: short, current, owned, updated, and read by the people whose work depends on it.
A test plan is a written agreement that allows a team to know whether testing is on track, off track, or done. It aligns QA, development, product, and stakeholders on what success looks like before the work begins.
A test plan is not a deliverable to be approved and filed. A plan that gets filed dies on the day it is filed. The plan that earns its place is the one that gets read, referenced when scope or schedule shifts, and updated when reality changes. The question is not whether the plan is written. The question is whether the plan is working.
Without a test plan, every person on the team has a slightly different idea of what is being tested, who is responsible for it, and what done looks like. That gap produces missed coverage, last-minute scope debates, and release decisions made on gut feel rather than evidence.
A well-written test plan does several practical things at once.
The plan does not have to be long to do all of this. Three pages covering the right components beats thirty pages covering everything twice.
A test plan touches every role involved in a release, not just the QA team.
A short test plan with the right components is better than a long plan that covers everything twice. Eight components account for nearly everything a modern test plan needs to carry.
The scope section names what is in and what is out. Both matter equally. The in-scope list tells the team what to test. The out-of-scope list forces a decision about what is being skipped, deferred, or covered by someone else.
Be specific. "All checkout flows" does not tell anyone which flows, which browsers, or which languages. "Single-item, multi-item, and saved-card checkout flows on Chrome, Firefox, Safari, and Edge in English and French" does.
Everything downstream, from effort estimates to done criteria, depends on how clearly the scope is written.
The approach section records how the testing will be done for this specific release: which test design techniques apply, which test types will run, and what level of automation is being used for each area.
Write it as a record of decisions made, not a general description of how testing works.
For example: "We are using boundary value analysis for all date and monetary fields because those are the most common source of defects in the previous two releases." When the work runs into trouble, the team can go back to these decisions and ask whether they are still the right ones.
List the people doing the work by name and what each person is responsible for. For example: "James owns the checkout module. Priya owns the payment integration. Both are available full time for the three-week cycle." This makes it clear who to go to for any question about a specific area.
Do the same for environments. Name each environment, what it is used for, and when it will be available. If there are constraints, write them down.
For example: "The staging environment is shared with team B and is only available to us from Monday to Wednesday each week."
Name the three dates that matter most:
For example: "System testing starts 5 June. UAT starts 19 June. Release decision is 30 June."
Add contingency days around the steps most likely to slip. If the staging environment has been unreliable before, add buffer time around that milestone specifically rather than spreading extra days evenly across the whole schedule.
For each risk, write what could go wrong and exactly what will be done about it.
For example: "The fraud screening vendor has not been tested at the volume this release requires. We will run contract testing in week one and limit the initial rollout to one market to reduce the impact if problems appear."
Three or four specific risks with specific actions is more useful than a long list of general concerns with nothing attached to them.
Entry criteria are the conditions that must all be true before testing starts.
For example: the build is deployed and stable in the test environment, the test environment has been checked and is accessible to all testers, test data is ready, test cases have been reviewed, and any defects that would block progress from the previous cycle have been fixed.
Agree this list with the development and environment teams at the start of the cycle. If any condition is not met by the planned start date, the team knows immediately rather than discovering it on day one of testing.
Pass and fail criteria define what must be true for the release to go ahead and what would cause it to be held.
For example: "No critical or high defects are open at the release decision date. All in-scope scenarios are passing on the full browser and device list. The regression suite has been green for three consecutive nightly runs before the release date."
Write criteria that anyone on the team or in the business can check for themselves. If a criterion requires someone to make a judgement call about whether it has been met, rewrite it until it does not.
Write down who owns each area of the plan.
For example: "Ana owns the test plan overall. James owns the checkout module test cases and execution. Priya owns the payment integration test cases and execution. David owns the regression suite. Fatima owns test data."
Every area has one named person. If the list reveals an area that nobody has been assigned to, assign someone before testing starts. An unowned area will not receive attention until something goes wrong in it.
Write down how bugs will be handled before testing starts.
For example: "All defects are logged in Jira with a severity label. Critical means a core user journey is completely broken with no way around it. High means significant impact but the user can work around it. Medium and Low cover everything else. Developers are assigned defects by the QA lead within 24 hours of logging. Once fixed, the original reporter retests and closes the defect."
Getting this agreed in advance means the first defect found during testing goes straight into the right process rather than triggering a conversation about how to handle it.
List what the testing effort will produce and who receives each item. For example: "Test cases for all in-scope areas delivered by day five. Daily status update sent to the engineering manager each afternoon. Weekly summary sent to the product owner every Friday. Release readiness report delivered on the release decision date."
Also write down what triggers an escalation.
For example: "If any milestone slips by more than two days, the QA lead notifies the project manager the same day." This means everyone knows in advance when and how problems will be raised rather than finding out differently each time.
Read the requirements, user stories, and acceptance criteria before writing anything. Talk to developers to understand what is changing. Talk to the product manager to understand what matters most.
A plan written without this context will miss the things that matter most. The purpose statement keeps the team focused when scope or priorities shift mid-cycle.
Purpose statement for a claims module release: "This release adds a guided claims intake journey and automated triage. Testing must confirm both work correctly, that the fraud screening integration behaves as expected, and that the regulatory reports match the new requirements."
Document what will be tested, what will not be tested, and who must confirm each exclusion. Both lists need to be explicit and agreed before testing begins.
Unconfirmed exclusions surface as surprises mid-cycle. A stakeholder who disagrees with an out-of-scope decision is better to find out on day one than on day ten.
In scope:
Out of scope:
During review, the engineering manager asked for lightweight API response time checks on the fraud screening integration because it had never been tested at volume. The scope was updated to include this. The full load test remained with the platform team.
For every area that could cause problems, write what could go wrong and what will specifically be done about it.
A risks list without actions is just a list of worries. The mitigation is what turns it into a plan.
Write down every condition that must be true before testing starts. Share the list with the development and environment teams and get confirmation by a specific date.
Testing that starts before these conditions are met wastes the first week on setup problems rather than actual testing.
By end of day 4 June:
During review, the development lead flagged the fraud screening integration would not be ready until 6 June. The system testing start date was moved to 6 June and the product manager was notified the same day.
For each scope area, decide which test techniques will be used and how much will be automated versus manual. Write the reasoning behind each decision.
Decisions made without recorded reasoning are impossible to revisit when the work runs into trouble. Writing the reasoning takes two minutes and saves hours of debate later.
Write down exactly what must be true for the release to go ahead and what would cause it to be held. Get sign-off on these before system testing begins.
Criteria agreed before testing produces a clear release decision. Criteria agreed at the release decision meeting produces a debate.
Release proceeds if all of the following are true on 30 June:
Release is held if any of the following are true:
At the kickoff meeting, the product manager asked whether a medium defect in the regulatory reporting would hold the release. The QA lead confirmed it would not under these criteria. The product manager agreed and this was recorded in the plan.
Name the three dates that matter most and the dependencies between them. Add contingency at the most uncertain points.
A schedule with too many dates is a schedule nobody tracks. Three load-bearing dates with clear dependencies is a schedule people can manage.
The two buffer days before UAT were added because the staging environment was unreliable in the previous release. If the environment is ready early, those days go to additional regression coverage.
Assign one named person to every area of the plan. No area should have more than one owner or no owner at all.
An area with no owner will not receive attention until something goes wrong in it.
Send the plan to the full delivery team before work begins and hold a short meeting to walk through it.
A plan that has been read and discussed by the people doing the work is a plan that does its job. A plan that gets filed without discussion does nothing.
The QA lead sends the plan on day one and books a 20-minute kickoff for the next morning. The agenda:
At the meeting, the development lead raises a concern that the fraud screening integration may not be stable enough to meet the entry criteria date. The QA lead adds a contingency to the plan: if the integration is not ready by 6 June, that area moves to week two and triage testing fills week one instead. The updated plan goes to the full team by end of day.
Use this as a starting point. Remove sections that do not apply. Add any section your release needs.
Consider a European property and casualty insurer is releasing a new claims-handling module. The module replaces a legacy intake form with a guided journey, adds automated triage, and connects to a new fraud screening service. It is the largest release of the year.
Three pages. Read at a team meeting in the first week. Referenced twice when scope questions came up during the cycle. Updated once when the staging environment issue materialised.
Test plans change. Requirements shift. A vendor misses a delivery date. A new regulatory requirement arrives mid-cycle. Five practices keep changes from breaking the plan.
For example: "The QA lead updates the plan at the end of each week to reflect any scope or schedule changes from that week." Daily edits during an active cycle are normal.
For example: "Adding the accessibility audit to scope adds three days to the schedule and requires one additional tester. The release decision date needs to move from 30 June to 3 July."
For example: "Send a single update to the full delivery team within 24 hours of any scope change, naming what changed, why, and what the impact is."
For example: "If the triage rules change in sprint three, James updates the affected test cases within two days and flags the change in the daily status update."
For example: "If the schedule shrinks by three days, the exploratory sessions on the legacy intake are reduced first. The fraud screening integration and the regulatory reporting get full coverage regardless."
A plan written because the project management office requires one, with no expectation that anyone will read it. The moment the plan becomes a filing exercise, it stops being useful.
A plan with fifty numbered subsections covering every possible edge case. A plan that long gets skimmed on day one and ignored for the rest of the cycle. Keep it as short as it can be while still covering what matters.
A plan with three sentences that leaves the scope, approach, and done criteria open to interpretation. Everyone reads it differently and the gaps surface at the worst possible time.
A plan that lists scope and schedule with no mention of what could prevent the testing from succeeding. The risks section is what separates a plan from a list of intentions.
A plan that says "testing will be thorough and complete" without defining what thorough and complete actually means. When the release decision meeting arrives, stakeholders argue about whether testing is done rather than checking whether measurable criteria have been met.
A plan approved by the project manager on day one and never opened again. A plan that gets read, referenced, and updated through the cycle is a plan that does its job. A plan that gets filed does nothing.
Writing a good test plan is one challenge. Keeping the testing it describes running continuously as the code changes is another.
The plan defines what must work. Virtuoso QA makes sure it does, continuously, as the code changes around it.
Try Virtuoso QA in Action
See how Virtuoso QA transforms plain English into fully executable tests within seconds.
