“We’ll test at the end, once everything is finished” – that sentence marks the beginning of many difficult go-lives. Without a test plan, nobody knows exactly what will be tested, who tests, on which environment, and when the software counts as sufficiently tested. The result is debate shortly before the release, missing test data and a sign-off based on gut feeling. A good test plan answers these questions before they become problems. This article shows what belongs in a test plan, how to write one step by step, and how to keep it lean in agile projects as well.
A test plan describes how testing is done in a specific project or release: objectives, scope, approach, resources, schedule and the criteria used to decide on release. In German-speaking projects it is usually called a Testkonzept. The standard ISO/IEC/IEEE 29119-3, which replaced the earlier IEEE 829, is a common reference for its structure and contents.
It is worth distinguishing it from two related terms:
A test plan pays off whenever several parties work together: development, business departments, operations, external service providers. Once there are interfaces to other systems, regulatory requirements or a formal acceptance, it becomes indispensable. Its scope should follow the risk, not a template. For a manageable application a few pages are often enough; a core-system migration with many interfaces may need considerably more detail. What matters is that the document is read and used – a 60-page plan that nobody knows helps no one.
What should testing demonstrate, and what is being tested? This section names the systems, modules, interfaces and release scope. Equally important is what is explicitly not tested – for example third-party systems the supplier is responsible for. Clear boundaries prevent misunderstandings about responsibilities later on.
Which test levels does the project have – component, integration, system and acceptance testing – and who is responsible for each? Then come the test types: functional tests, regression tests and non-functional tests such as performance, security or usability. For the last level before go-live, see our article Acceptance Testing: How to Get Software Sign-Off Right.
Not everything can be tested with the same depth. A good test plan rates functions by business criticality and likelihood of failure and derives the test depth from that. Critical core processes are tested intensively, peripheral functions with less effort. The project risks identified through risk management in IT projects are a valuable input here.
Which environments are used for testing, who provides them, and how close are they to production? Test data is a frequently underestimated bottleneck: will anonymised production data be used or synthetic data generated? Where personal data is involved, data protection must be considered from the start.
Who writes test cases, who executes them, who assesses defects and who signs off? A schedule with test phases and milestones belongs in the plan, aligned with the overall project plan. Especially important: the availability of business users for testing and acceptance must be planned early.
When can a test phase start (for example: build deployed, smoke test passed, test data available)? When is it complete (for example: all prioritised test cases executed, no open critical defects)? And when is it suspended because meaningful testing is not possible? Measurable criteria make the release decision traceable.
How are defects recorded, classified and tracked? Which severity levels exist, and who decides whether they are fixed? Then there is reporting: which metrics – such as test progress, open defects by severity, requirements coverage – are reported to whom and when? The end result is a test summary report with a clear release recommendation.
Scrum teams also need clarity about how they test – just in a different form. Instead of an extensive document at the start of the project, a lean, overarching test plan works well, defining test levels, environments, the automation approach and quality criteria. The details move into the team’s way of working: acceptance criteria in every user story, testing aspects in the Definition of Done and regression tests that grow with every sprint. How to plan these regression tests sensibly is covered in Regression Testing: How to Secure Stable Releases; the path to automated execution is described in Introducing Test Automation: A 6-Step Guide.
A test plan is not an end in itself but a shared understanding of how quality is demonstrated in the project. Clarifying objectives, scope, priorities, environments, responsibilities and release criteria early avoids debates shortly before go-live and creates a solid basis for the release decision. Why quality assurance as a whole determines project success is explained in Why Quality Assurance Decides Project Success.
The test strategy defines at a higher level how an organisation or programme tests in general. The test plan applies these guidelines to a specific project or release and describes scope, approach, resources, schedule and release criteria.
Usually the test manager or the person responsible for quality assurance. It is developed together with project management, development, business and operations, and it is reviewed and approved by the stakeholders.
Yes, but in a lean form. An overarching test plan covers test levels, environments, automation and quality criteria. The details live in the acceptance criteria of the user stories and in the Definition of Done.
30-minute initial consultation — free and without obligation. Together we look at your project and show what a suitable test plan for your requirements looks like.
Book a Free Initial ConsultationMore about our service: Software Quality Assurance in Hamburg →
Related: IT Project Management in Hamburg →