Test planning services
We write the test plan for your release: scope, entry and exit criteria, environments and risks, agreed with your team and yours to keep.
It suits teams heading into a regulated audit, and teams whose testing currently ends when the sprint ends.
What the plan pins down
- ScopeWhat is in, and what is out
- Entry and exit criteriaWritten as numbers
- EnvironmentsWhere testing runs
- RisksEach with an owner

Reviewed by Tudor Brad, Founder & CEOISTQB Certified Tester (Foundation Level) · Engineering degree, Technical University of Cluj-Napoca · Completed the DNSC-authorised Cybersecurity Auditor programme (2026) · Certified trainer
What we write
A test plan says what will be tested, how, in which environment, and what has to be true before testing can be called finished.
If you would rather write it yourself, our guide to writing a test plan walks through each section with a worked example and a template.
What the plan covers
Eight sections, each one short enough that people actually read it.
| Section | What it says |
|---|---|
| Scope | What is in, and what is deliberately out, so a gap is a decision rather than a surprise. |
| Test items | The builds, services and API versions under test, so every result traces to a commit. |
| Features to test | Features ranked by risk and traced to requirements. |
| Test approach | What is automated, what gets exploratory time, and what we are deliberately not doing. |
| Entry and exit criteria | Written as numbers anyone can check, so "testing is done" is a claim with a test. |
| Test deliverables | Test cases, results per build, defect reports and a one-page closure report. |
| Test environment | Where testing runs, how it differs from production, and what those differences cannot catch. |
| Schedule | Milestones tied to your sprints and release date, with named owners for each risk. |
How we work
Requirements analysis
We read your requirements, architecture notes and user stories, and mark what is testable, what is not, and what needs a question answered.
Risk assessment
We name the technical and business risks with your team and put the most testing where a failure would cost the most.
Alignment with your strategy
We fit the plan to the way your organisation already tests, and choose the test levels and types this release needs.
Resource planning
We set out who tests what, in which environment, with which tools, and who owns each risk.
Documentation and review
We draft the plan, review it with your dev lead and product owner, and keep it current when scope changes.

What you get
One agreed document
A written plan your developers, testers and product owner have agreed, covering scope, approach and timing.
A risk register
Every risk named with its impact, mitigation and owner, so the ones your team already suspects get written down.
Checkable exit criteria
Exit criteria written as numbers, so whether testing is finished is something anyone can check.
A record for audits
A document you can show an auditor to explain what was tested, why, and against which criteria.
Already have a plan nobody follows?
We can review it and cut it back to what your team will use. Talk to us
Standards we work to
The plan follows the structure of the international test documentation standard, trimmed to what your release needs.
- ISO/IEC/IEEE 29119-3:2021 Software Testing - Test Documentation
- ISTQB Certified Tester Foundation Level Syllabus
ISO/IEC/IEEE 29119-3 replaced IEEE 829, the older test documentation standard. If your organisation still uses IEEE 829 headings, we map them to the plan.
How BetterQA does test planning
We write the plan with your team, starting from the risks you already suspect, and keep it current while testing runs. If you want us to run the testing too, the plan is already written for it.
Engineers who test for a living
50+ QA engineers, working since 2018. People plan and run the test planning and report what the results mean for your release.
Bugs you can act on
Every defect we find is written up in BugBoard, our own test management tool, or in your tracker, with steps to reproduce, the expected and actual result, and the environment.
A certified process
ISO 9001 for quality management and ISO 27001:2022 for information security. See our certifications.
How an engagement works
- €20-45 per hour
- First month is a trial
- First two weeks complimentary if you are not happy
- 30 days notice after that
Test planning: common questions
What is a test plan?
A document that says what will be tested, how, in which environment, by whom, and what has to be true before testing can be called finished.
What does a test plan include?
Scope, test items, features to test, the test approach, entry and exit criteria, deliverables, the test environment and the schedule.
What is the difference between a test plan and a test strategy?
A test strategy sets the general approach to testing across projects. A test plan applies it to one release or project, with dates, people and exit criteria. See our test strategy page.
Is IEEE 829 still used for test plans?
IEEE 829 has been replaced by ISO/IEC/IEEE 29119-3. Many teams still know its section names, and they map almost one to one onto a 29119-3 plan.
Who owns the test plan you write?
You do. The plan is agreed with your team and is yours to keep and reuse for later releases.
What does test planning cost?
Our rate is €20-45 per hour. The first month is a trial, and the first two weeks are complimentary if you are not happy.
What goes in a test plan for a website?
The scope (pages, browsers, devices, integrations), the test levels and types, entry criteria, exit criteria, an effort estimate, the environments, the risks and who does what. ISTQB CTFL 5.1.3 defines entry criteria as the preconditions for starting an activity (for example the build is deployed and test data is ready) and exit criteria as what must be achieved to call it complete (for example the planned tests have run and all defects found are reported). CTFL 5.1.4 covers estimation techniques for the effort.
Talk to us about your test plan
Tell us what you are releasing and when. We will write the plan with your team, starting from the risks you already suspect and have not written down.