A test plan sounds like paperwork – until an audit asks for it or a release fails without clear criteria. That is exactly when the document proves its worth. A good test plan does not describe every click. It makes the scope, approach, resources and schedule of one test level traceable. For QA leads and test managers in regulated industries, that is more than a formality: the test plan is the backbone of audit readiness. This article shows what a test plan must contain under the current standard, how it differs from a test strategy, and how it stays lean in both agile and regulated teams.

TL;DR: A test plan, per ISTQB, describes the scope, approach, resources and schedule of intended test activities (ISTQB Glossary, 2024). The current standard is ISO/IEC/IEEE 29119-3 – IEEE 829 is formally superseded (IEEE SA, 2008). The standard defines roughly 13 content sections, from a risk register to entry and exit criteria. In regulated industries, this documented, repeatable plan is the basis of every audit.

Figure 1: The four core elements a test plan defines, per the ISTQB definition.

What Is a Test Plan?

A test plan, per ISTQB, is a document describing the scope, approach, resources and schedule of intended test activities (ISTQB Glossary, 2024). It identifies the test items, the features to be tested, the testing tasks and who does each one.

In concrete terms, a test plan also records which testers work independently, what test environment is required, and which test design techniques apply. Add to that entry and exit criteria, plus the risks that call for contingency planning. The plan is therefore less an instruction manual than an agreement about what gets tested and when testing counts as complete.

Scope is the key point. A test plan usually relates to one project or a specific test level. It does not answer how an entire organisation tests – that is the job of the test strategy. This distinction causes recurring confusion, so we clarify it in the next section.

Test Plan vs. Test Strategy vs. Testkonzept – What Is the Difference?

Figure 2: Scope and time horizon of test strategy, Testkonzept and test plan compared.

These terms get used interchangeably, but they mean different things. Per ISTQB, a test strategy is a high-level description of the test levels for an organisation or programme made up of one or more projects (ISTQB Glossary, 2024). The strategy works organisation-wide, while the test plan is tied to a project or test level.

The German term "Testkonzept" deserves a closer look. In the German ISTQB glossary, "Testkonzept" is simply the translation of "test plan" – both carry the same definition (ISTQB Glossary DE, 2024). The hierarchy common in many German teams – "Testkonzept = master, Testplan = per test level" – is therefore practitioner convention, not the ISTQB definition. Naming that openly prevents misunderstandings during an audit.

Source: ISTQB Glossary and Test strategy (2024).

Field note: In client projects, we regularly see "Testkonzept" and "test plan" used as one. As long as the team documents its own definition of the terms, that is fine – an audit asks for consistency, not textbook purity.

For more on the different test levels, see our overview of software test types.

Which Standard Applies Today?

The governing standard today is the ISO/IEC/IEEE 29119 series. The older IEEE 829-2008 is formally superseded by ISO/IEC/IEEE 29119-1, -2, -3 and -4 (IEEE SA, 2008). Aligning a new test plan to IEEE 829 means building around an outdated document – an avoidable audit finding.

The concrete structure of test documentation is set by ISO/IEC/IEEE 29119-3 (current edition 2021). The standard defines templates for test documents as outputs of the processes in 29119-2 (IEEE SA, 2021; ISO, 2021). It does not prescribe a rigid form. Instead, it supplies a framework that teams adapt to their context.

The practical benefit is comparability. A test plan structured to 29119-3 is recognisable to auditors because it follows internationally accepted sections. That speeds up every audit and reduces follow-up questions. The next section shows exactly what those sections are.

Structure and Content of a Test Plan

Figure 3: The 13 canonical sections of a test plan under ISO/IEC/IEEE 29119-3.

A test plan under ISO/IEC/IEEE 29119-3 covers roughly 13 content building blocks – from the context of testing through the risk register to completion criteria and the schedule (microTOOL, 2021). This structure is the scaffold every template should follow. It forces completeness without dictating content.

The canonical sections of a test plan under 29119-3:

• Context of testing: project, test item(s), scope, assumptions and constraints, stakeholders

• Testing communication: who is informed about test status and results, and how

• Risk register: product risks and project risks, with assessment

• Test strategy / sub-processes: chosen approach per test level

• Test deliverables: which artefacts testing produces

• Test design techniques: the design techniques applied

• Completion criteria: entry and exit criteria per activity

• Metrics: how progress and quality are measured

• Test data and test environment: required data, infrastructure, tools

• Retesting and regression: approach after defect fixes

• Suspension and resumption: when tests pause and restart

• Staffing: roles, responsibilities, skills

• Schedule: milestones and dates of test activities

Not every section needs the same depth in every project. The skill lies in addressing each point deliberately – even when the answer is "not relevant, because …". That documented decision is what separates a load-bearing plan from a box-ticking exercise. To make the completeness of your testing measurable, see our article on test coverage.

Why Is the Test Plan Critical in Regulated Industries?

Figure 4: DORA requires at least annual, documented testing of critical ICT systems.

In regulated industries, the test plan is not an administrative act but an audit backbone. Under DORA – Regulation (EU) 2022/2554 – financial entities must regularly, at least annually, test their critical ICT systems and document the results and remediation status in a traceable way (Regulation (EU) 2022/2554, Art. 24–26). Supervisors want demonstrated resilience, not paper compliance.

This is exactly where a structured test plan pays off. It records what was tested when, against which criteria, and who was responsible. That traceability is the basis of any tamper-proof audit trail. Without the plan, it is hard to prove in an audit that testing happened systematically and repeatably.

Reproducibility is the core of it. A test plan that leads to the same defined steps and criteria on every run delivers exactly the consistent evidence an audit requires. Automated, documented test runs strengthen this effect because they reduce human variability. To see how such runs are set up consistently, look at our test workflows.

What Does a Lean Test Plan Look Like in Agile Teams?

Agile teams need a test plan too – just in a different form. The 29119-3 sections still apply, but the plan often lives as a compact, living document rather than a 40-page PDF. What matters is that every canonical point has a deliberate answer, not that every point runs to pages.

A slimmed-down format works well in practice. The risk register, entry and exit criteria, and the test environment belong in firmly, because they decide release readiness. Detail on staffing or communication, by contrast, can often be cut to a few lines when the team is small and well-established.

A common mistake is the opposite of bureaucracy: no plan at all. Without documented exit criteria, gut feeling decides the release – a real risk in a regulated environment. A lean but complete plan resolves that tension. To see what a concrete release quality gate looks like, read our guide to the smoke test. For the wider context, see our overview of the test pyramid.

Frequently Asked Questions

What is the difference between a test plan and a Testkonzept?

In the German ISTQB glossary, there is none: "Testkonzept" is the translation of "test plan" and carries the same definition (ISTQB Glossary DE, 2024). The common split "Testkonzept = master, Testplan = per test level" is practitioner convention. It is acceptable but should be defined within the document itself to avoid audit follow-ups.

Which standard applies to test plans – IEEE 829 or ISO 29119?

ISO/IEC/IEEE 29119 governs; IEEE 829-2008 is formally superseded (IEEE SA, 2008). The structure of test documentation is set specifically by ISO/IEC/IEEE 29119-3 in its 2021 edition (IEEE SA, 2021). New test plans should align to the current standard, not to the superseded IEEE 829.

Which sections must a test plan contain?

Under ISO/IEC/IEEE 29119-3, roughly 13 building blocks: context of testing, communication, risk register, test strategy, test deliverables, design techniques, completion criteria, metrics, test data and environment, retesting and regression, suspension and resumption, staffing, and schedule (microTOOL, 2021). The team adapts depth and scope to its context.

Does an agile team even need a test plan?

Yes, just in a leaner form. The canonical sections still apply, but the plan often lives as a compact, living document. The most important parts are the risk register, entry and exit criteria, and the test environment, because they decide release readiness. Missing documented criteria are a genuine risk, especially in a regulated environment.

How does a test plan support audit readiness under DORA?

DORA requires regular, documented testing of critical ICT systems including remediation status (Regulation (EU) 2022/2554, Art. 24–26). A structured, repeatable test plan delivers exactly the traceable evidence supervisors expect. It proves what was tested when and against which criteria – the basis of a tamper-proof audit trail.

Conclusion

A test plan is not an end in itself but the agreement about what gets tested and when testing counts as complete. The governing standard today is ISO/IEC/IEEE 29119-3, not the superseded IEEE 829 (IEEE SA, 2008). Address the roughly 13 sections deliberately – from the risk register to the exit criteria – and you get a document that holds up in agile and regulated teams alike. In regulated finance under DORA, this documented, repeatable plan becomes the backbone of audit readiness. What matters is not length but completeness and the reproducibility of your test runs. Want to set up your test runs so every run is documented and audit-ready? Talk to our team.