What belongs in a test plan, and what turns it into a decision document

There is one type of document that almost every project has and almost nobody reads: the test plan. It usually runs to twenty or forty pages, appears shortly before the test phase, describes test types and tools in general terms, and is never opened again. It satisfies a formality, not a function.

That is rarely the author's fault. The question was framed wrongly. A test plan is not a descriptive document but a decision document. It settles what will be tested, at what depth, on what grounds, and how the end will be recognised. Everything else is padding.

Terminology first: “Testkonzept” or “test plan”?

In German usage, “Testkonzept” has become the established term. The international standard does not use it; it speaks of the test plan. This is not a question of translation but a shift in meaning: “plan” stresses that the document makes statements about the future which can later be held against reality. “Konzept”, or concept, sounds like a one-off collection of ideas.

With German clients we go on saying “Testkonzept”, because that is what people ask for, but what we mean is the test plan as the standard defines it. Anyone preparing documents for an audit or for an international parent company should know the English term, otherwise the other side will look for a document that appears to be missing.

Where the structure comes from

The authoritative series of standards is ISO/IEC/IEEE 29119, “Software and systems engineering — Software testing”. It consists of several parts that are maintained separately:

• Part 1 (2022), General concepts: terminology and the underlying concepts of testing.
• Part 2 (2021), Test processes: the process model. The centrepiece of the series.
• Part 3 (2021), Test documentation: the document templates, including the one for the test plan.
• Part 4 (2021), Test techniques: the test design techniques, from equivalence partitioning to state transition testing.
• Part 11 (2020), Guidelines on the testing of AI-based systems: a Technical Report on testing AI-based systems.

Part 2 defines three process levels, and this three-way split explains why so many test plans come across as vague. There is the organisational test process, which sets out how testing is done in the company as a matter of principle. There are the test management processes: test planning, test monitoring and control, and test completion. And there are the dynamic test processes, in which testing is actually designed, set up, executed and reported.

A test plan belongs at the middle level. It translates the company's general requirements into decisions for a specific undertaking and gives the level below it the ground rules it works to. Mix the levels up and you write either house rules too general to be concrete for any project, or a collection of test cases too detailed to steer by.

The areas a test plan has to cover

Part 3 of the standard provides a template. It can be boiled down to seven areas, and those seven turn up in every project, whether or not anyone knows the standard:

• Context: what is being tested, in what environment, on what assumptions, under what constraints. This is also where anything expressly out of scope is recorded. The exclusion is often worth more than the list of inclusions.
• Communication: who receives which information, when, and in what form. It sounds trivial, but it determines whether bad news arrives in time.
• Risk register: the assessed product and project risks. Not as an annex, but as the foundation.
• Test strategy: test types, test levels, test design techniques, test coverage targets, test data, test environments, entry and exit criteria, and how deviations are handled.
• Activities and estimates: what has to be done and what it costs, in person-days or in elapsed time.
• Staffing and roles: who is responsible for what, and what qualifications are assumed.
• Schedule: milestones and dependencies, in particular on deliveries from development.

The part that drives the whole plan

Of these seven, one is the real core: the risk register together with the test strategy derived from it. It answers the one question a test plan has to answer and that no tool can answer: why do we test this part deeply and that one only lightly?

Without that derivation, every choice of test depth is arbitrary. With it, the choice becomes negotiable, and that is the point. A management team that knows a particular process step is deliberately being tested only at surface level, because its risk was assessed as low, can support that decision or overturn it. A management team that does not know finds out when the incident occurs.

The second core element is the exit criteria. They sit in the test strategy, and they are the reason a test plan has to be written before the testing rather than after it. A criterion set only once the test run is over is not a criterion but a description of the result. As soon as the numbers are on the table, the threshold quietly moves to wherever you happened to land.

What does not belong in it

Three things inflate test plans without making them any better:

• Test cases. They belong in the test case inventory, not in the steering document. A test plan sets the authoring standard they are written to and supplies the worked examples people take their bearings from.
• Tool descriptions. How a given tool is operated belongs in a user guide. All the test plan needs to state is what function the tool serves in the process and what happens if it fails.
• Textbook material. An explanation of what a system test is addresses nobody. Anyone reading the document already knows; anyone who does not needs training, not a chapter.

When to write it and how long it should be

A test plan is written as soon as the requirements are firm enough for risks to be assessed, and long before the first test case is drafted. It is a living document: if the scope changes, the risk assessment changes, and with it the test strategy.

On length there is no standard and no rule of thumb that holds. What does hold is a different yardstick: every sentence must either contain a decision or justify one. Anything that fails that test can go. In practice, most projects end up with something that can be talked through in a single meeting, and that is precisely the purpose.

Who does what

Qelivia produces the risk picture and the test plan, defines the authoring standard for the test cases and supplies fully worked examples. We take on review and sign-off of the test case inventory as well as steering throughout the test phase. Your team runs the tests themselves, in your tool or in an environment we provide. The reason is practical: the detailed system and process knowledge sits with you, and without it you get test cases that are formally correct and practically worthless. The plan is aligned with the ISTQB test process and uses established testing terminology. Its structure also reflects relevant principles from the ISO/IEC/IEEE 29119 series where they apply to the project context.

Conclusion

A test plan of this kind is not bureaucratic overhead; it is the shortcut. It forces three decisions to be taken early that would otherwise be taken late and under pressure: which risks we take seriously, how deeply we therefore test, and when we are finished. With those three points in writing, the closing discussion is about results. Without them, it is about opinions.