For teams shipping to a deadline with no agreed definition of done

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.

€20-45Per hour
First 2 weeksComplimentary on ongoing work if not happy
50+QA engineers
2018Founded

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
// what we write

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.

// contents

What the plan covers

Eight sections, each one short enough that people actually read it.

SectionWhat it says
ScopeWhat is in, and what is deliberately out, so a gap is a decision rather than a surprise.
Test itemsThe builds, services and API versions under test, so every result traces to a commit.
Features to testFeatures ranked by risk and traced to requirements.
Test approachWhat is automated, what gets exploratory time, and what we are deliberately not doing.
Entry and exit criteriaWritten as numbers anyone can check, so "testing is done" is a claim with a test.
Test deliverablesTest cases, results per build, defect reports and a one-page closure report.
Test environmentWhere testing runs, how it differs from production, and what those differences cannot catch.
ScheduleMilestones tied to your sprints and release date, with named owners for each risk.
// how we work

How we work

  1. 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.

  2. Risk assessment

    We name the technical and business risks with your team and put the most testing where a failure would cost the most.

  3. 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.

  4. Resource planning

    We set out who tests what, in which environment, with which tools, and who owns each risk.

  5. Documentation and review

    We draft the plan, review it with your dev lead and product owner, and keep it current when scope changes.

Two BetterQA colleagues working side by side at the meeting table, one reviewing results on a laptop
// deliverables

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

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 replaced IEEE 829, the older test documentation standard. If your organisation still uses IEEE 829 headings, we map them to the plan.

// how we work

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
// questions

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.