·
8 min
Test strategy: definition, how it differs from a test plan, and a template
Roman Kirchmeier - Autemos
A test strategy sets the principles an organization tests by: which risks come first, which test levels exist, what gets automated and when testing counts as done. The test plan applies those principles to one test project. In the German ISTQB syllabus, the test plan is officially called “Testkonzept” (GTB, CTFL syllabus 4.0.2 DE, 2025). Many German-language pages mix the two documents up. In HERMES, the Swiss federal project method, the strategy is even a chapter of the test concept. The template below has 12 sections, from risk analysis to DORA obligations.
TL;DR: A test strategy describes how testing is done: risks, test levels, automation, environments, criteria. The test plan applies it to one project and, per ISTQB CTFL 4.0.1, shows that testing adheres to it. Since 17 January 2025, EU financial entities need a risk-based testing program under DORA on top.
Figure 1: From test policy through test strategy to test plan (ISTQB CTFL 4.0.1)
What is a test strategy?
A test strategy is documentation that follows the organization's test policy and “describes the generic requirements for testing” (ISTQB Glossary v3.4, as reproduced by imbus, 2020). The same glossary gives a second meaning: the “part of the Test Plan that describes the approach to testing for a specific test project …” So there are two levels, organizational and project.
The organizational strategy covers every project and changes rarely. The project strategy derives what applies to one system, which ISTQB CTAL-TM v3.0 lists as a business outcome for test managers (ISTQB, 2024). How the strategy fits into rolling out automation is covered in our guide to test automation.
Are the classic strategy types still current?
The current Foundation syllabus no longer lists strategy types: the CTFL 4.0 release notes say “Section on test strategies/approaches removed” (ISTQB, CTFL 4.0.1, 2024). Older ISTQB syllabi such as CTFL 2018 (v3.1) distinguish analytical, model-based, methodical, process-compliant, consultative, regression-averse and reactive strategies. Plenty of pages still present these seven as current exam content.
How do test policy, strategy and plan relate?
Policy, strategy, approach and plan form a hierarchy in ISTQB terms, from the organization down to one project. CTFL 4.0.1 says a test plan “Demonstrates that testing will adhere to the existing test policy and test strategy (or explains why the testing will deviate from them)” (ISTQB, CTFL 4.0.1, 2024).
Test policy (Testrichtlinie): principles, approach and major testing objectives of the organization (imbus, ISTQB Glossary, 2020).
Strategy (Teststrategie): generic requirements for testing across the organization or a program.
Test approach (Testvorgehensweise): “The implementation of the test strategy for a specific project” (imbus, 2020).
Test plan (Testkonzept): “A test plan describes the test objectives, resources and processes for a test project.” (CTFL 4.0.1 §5.1.1)
The test approach isn't a separate document: CTFL 4.0.1 §5.1.1 lists it as content of the test plan itself. Our article on the test plan walks through the ISO 29119 structure section by section.
Where does HERMES put the strategy?
In HERMES, the strategy is a chapter inside the test concept. The outcome “Test concept” has a section “Teststrategie und Teststufen” (strategy and test levels), followed by test objects, test types, coverage, environment, test cases and a separate “test plan” subsection for order and timing (HERMES, Test concept, 2022).
Teams that serve ISTQB and HERMES write the organizational strategy once and reference it in the HERMES chapter.
Test strategy vs test plan: what's the difference?
The strategy defines how testing is done; the test plan defines what is tested, when, with which resources and by whom in one project. ISTQB CTFL 4.0.1 requires the plan to show adherence to the strategy or explain deviations (ISTQB, 2024).
Figure 2: Test strategy and test plan compared
Criterion | Strategy | Test plan (Testkonzept) |
|---|---|---|
Core question | How do we test? | What, when, who, with what? |
Scope | Organization, program or product line | One test project or test level |
Lifespan | Several projects, reviewed regularly | Duration of the project |
Typical content | Risk approach, test levels, automation principles, criteria, metrics | Context, stakeholders, risk register, test approach, budget, schedule |
Owner | Test management or quality leads | Project test manager |
Standard | ISO/IEC/IEEE 29119-2, organizational level | ISO/IEC/IEEE 29119-3, test plan template |
Agree on the terms at kickoff, since HERMES uses “Testplan” only for the timing part. Our article on test management covers how both documents are run day to day.
What goes into a test strategy? A 12-section template
A test strategy covers scope, risks, test levels and types, automation, environments and test data, criteria, metrics, tools, roles and regulatory requirements; our template puts them into 12 sections. The Basis column names the syllabus section or legal article behind each row.
Figure 3: The 12 sections of the test strategy template
No. | Section | Guiding question | Basis |
|---|---|---|---|
1 | Scope and objectives | Which systems, releases and interfaces are in or out? | CT-TAS §1.1.1 |
2 | Risks and prioritization | Which product risks have the highest risk level? | CTFL §5.2 |
3 | Test levels | Component, integration, system, acceptance: who tests what? | CTFL §5.1.1 |
4 | Test types | Functional, non-functional (load, security), regression | CTFL §5.1.1 |
5 | Automation strategy | Purpose, scope, tool, architecture, pilot | CT-TAS §1.1.1 to 1.1.2 |
6 | Test environments | Which stages, separated from production how? | DORA RTS Art. 8 |
7 | Test data | Where does data come from, how is it anonymized? | DORA RTS Art. 16 |
8 | Entry and exit criteria | When can an activity start, when is it complete? | CTFL §5.1.3 |
9 | Metrics and reporting | Which metrics, how often, to whom? | CTFL §5.1.1 |
10 | Tools | Test management, automation, CI/CD, defect tracking | CT-TAS §1.1.1 |
11 | Roles and independence | Who designs, automates, signs off? | CTFL §5.1.1 |
12 | Regulatory requirements | Which laws, circulars and standards apply? | DORA Art. 24 |
For sections 6 and 7, EU financial entities follow Commission Delegated Regulation (EU) 2024/1774 under DORA: “non-production environments only store anonymised, pseudonymised, or randomised production data” (Art. 16(5)) (EUR-Lex, 2024). More on that in our article on the test environment.
How does the risk-based approach work?
ISTQB defines risk-based testing as “The test approach, in which test activities are selected, prioritized, and managed based on risk analysis” (ISTQB, CTFL 4.0.1 §5.2, 2024). Risk level comes from likelihood and impact. In our view three levels (high, medium, low) are enough to start, with one rule: high risks get more test types, earlier tests and a stricter sign-off.
What goes into the automation strategy?
ISTQB CT-TAS v1.0 (May 2024) says a test automation strategy must address purpose, risks, scope, stakeholders, tool selection, the test automation architecture and environments. It recommends a pilot: “The use of a pilot project helps determine the tools and viability of selected technologies.” And the strategy “needs to be kept up-to-date” (ISTQB, CT-TAS, 2024).
As an example of something hard to automate, CT-TAS names a loan application where agents check and decide manually. Flows like that belong in the manual part of section 5.
Our checklist on which tests to automate covers selection. For spreading tests across levels, many teams use the test pyramid; Google's 70/20/10 split is a starting point “as a good first guess”, not a rule (Google Testing Blog, 2015).
How do you write a test strategy step by step?
You can write the strategy in seven steps, from collecting requirements to a scheduled review. Risk analysis sits at the center: ISTQB CTAL-TM v3.0 lists the outcome “Organize risk identification and risk assessment sessions within any software development lifecycle” (ISTQB, 2024).
Figure 4: Seven steps to a test strategy
Collect requirements: test policy, laws, circulars, contracts, group standards.
Identify and assess product risks with business, development and operations.
Map test levels and test types to the risks.
Decide on automation: purpose, scope, tool, pilot project.
Describe environments, test data and entry and exit criteria.
Define metrics, reporting and roles, then get management sign-off.
Set a fixed review date, for example before each planning cycle.
Keep it short enough that project leads read it before kickoff; schedules and test cases belong in the test plan.
What do DORA and ISO 29119 require?
Since 17 January 2025, EU financial entities must run a digital operational resilience testing program under DORA (Regulation (EU) 2022/2554) that follows a risk-based approach (Art. 24(3)), with appropriate tests “at least yearly” on all ICT systems supporting critical or important functions (Art. 24(6)) (EUR-Lex, 2022). Art. 24(4) requires independent testers, internal or external. Art. 25 names test types, including scenario-based, compatibility, performance, E2E and penetration testing.
Swiss banks and securities firms fall under FINMA Circular 2023/1, in force since 1 January 2024. Its change-management section requires separating the environments for development or testing from the ICT production environment (FINMA Circular 2023/1, 2022).
The reference standard is ISO/IEC/IEEE 29119. Part 2, published 28 October 2021, describes test processes on three levels: organizational, test management, and design and execution (IEEE Standards, 29119-2:2021, 2021). Part 3 provides 84 pages of documentation templates (IEC Webstore, 2021).
Which parts of the strategy does Autemos cover?
Autemos is an AI-assisted platform for automating functional tests across web, mobile, API and desktop. It executes the automation part of your strategy and reports results back; it doesn't write the strategy.
Section 5, automation: visual test workflows; the AI Recorder drafts steps from a Jira ticket, and the team approves every AI step before it runs.
Section 7, test data: datasets from CSV, XLSX or JSON with per-environment configuration.
Section 9, reporting: test cases and executions sync both ways with Jira and Xray, plus Allure reports. See the Jira and Xray integration.
Section 10, tools: export to Playwright (Java or TypeScript) and Appium (Java); tests run without Autemos, which lowers the vendor-dependency risk named in CTFL 4.0.1 §6.2.
Autemos has no load, performance, security or penetration testing, doesn't measure code coverage and doesn't provision environments. Unit tests stay with developers. DORA names performance and penetration testing, so your strategy needs other tools there.
Frequently asked questions
What is the difference between a test strategy and a test plan?
The strategy describes how an organization tests; the test plan applies that to one test project. Per ISTQB CTFL 4.0.1, the plan shows that testing adheres to the test policy and strategy, or explains deviations.
Is a “Testkonzept” the same as a test plan?
Yes, in the German ISTQB syllabus CTFL 4.0.2, “Testkonzept” translates “test plan”. In the Swiss HERMES method, though, “Testplan” means only the subsection of the test concept that sets order and schedule.
Who writes the strategy?
Test management or quality leads usually own the organization-wide strategy, with management sign-off. The project test manager derives the project strategy, which ISTQB CTAL-TM v3.0 lists as a business outcome. In HERMES, the test concept sits with the “Testverantwortlicher” role.
How often should the strategy be updated?
Review the strategy on fixed dates and after major changes to architecture, tools or regulation. DORA Art. 24(1) requires financial entities to review their testing program.
Which standard covers test documentation?
ISO/IEC/IEEE 29119 is the international standard for software testing. Its Part 3 (2021) provides 84 pages of documentation templates. Our article on the test plan explains the plan under this standard.
Conclusion
The strategy says how you test; the test plan says what happens in one project, and HERMES makes the strategy a chapter of the test concept.
Start with the 12 sections of the template, put risk analysis first, and cover automation with the seven points from CT-TAS. For EU financial entities, DORA Articles 24 and 25 belong in section 12; for Swiss banks, FINMA Circular 2023/1. Schedule the review from day one.
Autemos handles the automation part and keeps results traceable in Jira and Xray. Your strategy is yours to write. To see how that looks in your setup, book a demo.
