What Is a Test Plan? Structure and Real Example

A test plan is the document that says what will be checked, how, by whom, on what devices, and by when. It also defines what “finished” means, so nobody argues later about whether testing is done. If you’re about to hand your product to a QA team for the first time, this document is what keeps both sides working toward the same result.

A good plan isn’t paperwork for its own sake. Testing without that agreement tends to drift: the QA team picks whatever looks important, developers assume someone else covered the rest, and the gaps only show up after release.

This guide walks through what goes into a real test plan, how QAwerk plans testing with clients, and where test cases fit in. Instead of a generic template walkthrough, we’ll use examples from projects we’ve actually run. Agreeing on a test plan is one of the first things our dedicated QA team does with a new client.

What a Test Plan Actually Includes

Most test plans follow the same structure, and for good reason: each part answers a question someone will eventually ask. The ISTQB Foundation Level syllabus, used to certify software testers worldwide, lists nearly the same sections. The international standard for test documentation, ISO/IEC/IEEE 29119-3, sets out a matching list. Here’s what goes in, in plain terms.

• Objectives: This is what testing should achieve, such as confirming that checkout works before a holiday sale or that nothing broke after a redesign.
• Scope: It lists which features get checked and, just as important, which don’t. Writing down what’s out of scope prevents the most common argument in any testing project.
• Test approach: This covers how testing will happen: by hand, with automated scripts, or a mix. The same section lists what needs checking, such as features, speed, or security.
• Resources: This names who does the work, on what devices and browsers, and with what tools.
• Test environment: It says where testing happens, usually a separate copy of your product set up so testers never touch real customer accounts or data.
• Schedule: This sets when each round of testing starts and ends, and how that timing lines up with your release dates.
• Entry and exit criteria: These are the conditions for beginning, for example the new version is installed and login works. Exit criteria then mark when the job is done, such as no critical bugs left open.
• Risks: It covers what could derail the work, like a late build or a missing test account, and the team’s backup plan for each.
• Reporting: This explains how often you’ll hear about progress and bugs, and in what form.

Exit criteria work best as numbers anyone can check, such as the software test metrics teams usually rely on to make that call.

Think of this list as a test plan template: it’s what you should expect from any prospective QA partner, just tailored to your product. If you need a more detailed example, check our mobile app testing checklist.

Real Examples: How QAwerk Plans Testing

QAwerk creates a test plan for every client, and here’s how the process goes in practice:

1. Product review: Before planning anything, we read your requirements and explore what’s already built to see where problems keep coming back.
2. Agreed scope: Both sides sign off on what gets tested, down to exact devices and browsers. For example, on the Unpakt marketplace project, the list named Windows 10 with Chrome and an iPhone X with Safari.
3. Priorities: Testing runs in phases, with the features that matter most to your business checked first.
4. Unexpected scenarios: Part of the effort, about 20% on the Unpakt project, goes to what happens when users do something nobody planned for.
5. Reporting: Bugs go straight into your own bug tracker, and progress updates arrive daily.
6. Full coverage: A shared checklist records every passed and failed test, so nothing slips through.

Of course, the process is adjusted to each client’s needs. Here are a few cases that called for very different plans:

• A tight deadline: With about a month to go, we covered all features, both user roles, and 7 devices for Escuela Coaching. The app launched on schedule.
• No QA process at all: For DrAnsay, we audited the web and mobile apps first and aimed testing at the recurring problems we found. Since then, 60+ bugs have stayed out of production.
• A product still in development: ChitChat brought us in while the features were still being planned, so we designed checks one feature at a time as the app took shape. Testing ran on 24 phones matched to the Zambian market.

How to Write a Test Plan With Your QA Team

When you hire a QA team, writing the test plan is the testers’ job. Your part is supplying what only you know:

• Existing documents: Specs, tickets, designs, and past bug reports show how the product should behave. Gaps are fine, since the plan turns missing details into open questions.
• Priorities: Tell the team which features bring in money or would hurt most if broken, so testing starts there.
• Usage data: Analytics on the phones and browsers your customers actually use decide the device list.
• Access: Test accounts and a separate copy of the product let the team work without going near the live version.
• Release dates and sign-off: Your schedule sets when each round runs, and your approval makes the plan final.

Beyond these inputs, much depends on what you’re building. For a website, the focus falls on browser compatibility, phone screens, and loading speed, as our website testing checklist shows. By contrast, a game adds heavy-traffic checks, store compliance reviews, and beta rounds, all laid out in our mobile game testing checklist.

AI tools can now draft a plan outline quickly. According to PractiTest’s 2026 State of Testing report, half of small QA teams already use AI for test planning, yet only 19.9% of testers rely on it to identify risks. In other words, a tool speeds up the writing, while judging what could actually hurt your business still takes experienced QA engineers.

If your product has little written down yet, our technical documentation services can write the test cases and other QA documents alongside the plan.

Test Plan vs Test Cases: What's the Difference?

People often confuse test plans and test cases, but the two documents work at very different levels.

When you work with a QA team, the testers write and run the test cases, and what reaches you is results and bug reports. If you’re curious about the mechanics, we explain how to write test cases in a separate article.

You may also hear about a test strategy, which sets the general approach for a whole company or product line. A test plan then puts those principles to work on one project. Larger organizations tend to keep the strategy as a separate document, while smaller teams usually manage with a single plan. For a closer look at how the two documents divide the work, read about software testing strategies.

Where a Test Plan Fits and Why It Pays Off

In the software testing life cycle, test planning comes right after requirements analysis and before anyone writes test cases. That order matters because unclear specs produce a vague plan. Our dedicated post on software testing requirements explains what documents help most. From there, planning shapes each of the remaining stages of software testing.

A test plan proves most valuable when a project changes direction, for example when a feature gets cut, a deadline moves, or a new platform is added. Instead of renegotiating the whole scope, both sides update only the affected parts and carry on.

Every QAwerk engagement starts with a test plan, so the team and the client agree on priorities from day one. The document also helps our testers get up to speed on a new product quickly. On your side, the plan doubles as a clear record of what’s been covered. Get a test plan built for your product.

FAQ

See the real test plan behind our work on 100+ Keystone education websites

Please enter your business email isn′t a business email

Grab Your Free Copy