The second set of questions is the strategy layer. Why are we automating? What should we automate, and what should we leave alone? How does this automation program connect to the actual quality goals of the organization? Who is responsible for it? How do we know whether it is working?
Test automation strategy is the thinking that answers those questions before the first line of test code is written, and then continues to guide decisions as the program grows.
Strategy is not the same as planning
It is easy to confuse strategy with planning. Planning is about tasks, timelines, and who does what. Strategy is about direction: what you are trying to accomplish, which tradeoffs you are willing to make, and how you will know if the work is paying off.
In test automation specifically, strategy involves decisions like:
Which test levels are appropriate for automation and which are not? Unit tests, API tests, and end-to-end tests have very different automation characteristics. They catch different kinds of problems, run at different speeds, and fail for different reasons. A strategy has to make explicit choices about where to invest.
Which tests within those levels should be automated first? High-risk areas that are tested repeatedly make stronger automation candidates than obscure features that rarely change. The selection criteria matter because automating the wrong things wastes time that could have gone to more valuable coverage.
How does automation connect to the delivery pipeline? A suite that only runs on request is a different thing from a suite that gates a deployment. The relationship between automation and the pipeline has to be designed, not assumed.
What happens when the suite grows? A collection of tests that works well at 200 tests can become unmanageable at 2,000 if the architecture was not built for scale. Strategy means thinking about where the program is going, not just where it is now.
Why this layer is often missing
Test automation frequently starts from the bottom up. An engineer writes a few automated tests for a feature, someone else adds more, and over time there is a collection of automated scripts that the team runs periodically. Nobody made a strategic decision about any of it. It just accumulated.
This is not a failure. It is how most things start. The problem is when the accumulation continues without any strategic thinking being applied. The suite gets large and slow. Tests start failing intermittently for reasons no one can trace. People lose confidence in the results. The suite gets run less often, which defeats most of its purpose.
A strategy does not prevent all of these problems, but it does give the team a framework for addressing them. It means there is a shared understanding of what the automation is supposed to do, who is responsible for it, and how to evaluate whether it is delivering value.
What a strategy actually covers
The ISTQB Test Automation Strategy certification provides a useful framework for thinking about what a real strategy addresses. Based on what ASTQB describes about its scope, the core areas include:
Costs and risks. Automation is not free. There are setup costs, ongoing maintenance costs, infrastructure costs, and the opportunity cost of engineering time spent building and fixing tests instead of doing other work. A strategy has to account for all of these, not just the visible ones.
Return on investment. This means being honest about what the automation is actually saving. A suite that takes twenty hours a week to maintain and catches defects that exploratory testing would have caught anyway is not delivering strong ROI. Understanding how to measure and improve ROI is a strategy-level skill.
Roles and responsibilities. Who owns the automation? Who maintains it? Who reviews it when it fails? Automation that belongs to everyone often effectively belongs to no one. Strategy means being clear about accountability.
Fit with the development model. How automation integrates into the team's workflow depends on whether the team works in Agile sprints, a DevOps continuous delivery model, a traditional waterfall structure, or something in between. Different models have different constraints and different opportunities. Shift-left approaches push testing earlier in the development process; shift-right approaches extend it into production monitoring. Strategy has to take the actual development model into account.
Metrics that drive decisions. Which numbers actually tell you whether the automation is working? Pass rates, execution time, maintenance cost, defect detection rate, and coverage trends all tell different things. A strategy specifies which metrics matter for the organization's goals and how they will be tracked.
Transitioning from manual testing. Most teams do not build automation from scratch. They have existing manual testing processes, and the automation has to be introduced alongside them, not simply dropped in as a replacement. How that transition works, at what pace, and for which test types requires deliberate planning.
Strategy across the organization
One of the distinctive things about automation strategy, as described in the ISTQB Test Automation Strategy syllabus, is that it addresses automation across an organization, not just within a single project. That means thinking about how different teams share automation assets and methods, how standards are maintained across projects, and how automation knowledge is built and transferred as teams change.
This is a different problem from getting automation working on one project. It requires a governance mindset: defining what good automation looks like, making that visible and accessible to other teams, and ensuring that investments in automation infrastructure are not duplicated unnecessarily.
Who needs to think about strategy
Test automation strategy is not just for people with "strategy" in their title. It is relevant for any automation engineer who is making decisions about what to build and how to build it. It is relevant for QA leads and test managers who oversee automation programs. It is relevant for developers who write tests and for technical leads who make architectural decisions.
It is also relevant for managers and stakeholders who do not write tests themselves. Understanding what makes automation valuable, and what makes it a waste of time, makes it easier to ask the right questions about automation proposals, understand what metrics actually mean, and make good decisions about investment.
Where the ISTQB Test Automation Strategy certification fits
The ISTQB Test Automation Strategy (TAS) certification covers this strategic layer directly. ASTQB describes it as addressing test automation needs beyond technical tool implementation, providing a systematic view of how automation can be implemented across projects in a consistent way that demonstrates value to the organization. The exam is 40 questions and 60 minutes. ASTQB lists ISTQB Foundation Level as the prerequisite; ISTQB also notes that candidates are expected to have sufficient practical experience.
TAE and TAS are complementary certifications. Together they offer a comprehensive automation body of knowledge: the hands-on engineering skills to build automation well, and the strategic decision-making to guide it effectively across an organization. Someone who holds both is in a meaningfully different position than someone who holds only one.
The Test Automation Pro connection
ISTQB Test Automation Strategy is one of the three certifications that make up the ASTQB Test Automation Pro designation, alongside Foundation Level and Test Automation Engineering. The designation is awarded, upon request, to professionals who earn all three through ASTQB & AT*SQA. It is designed to signal exactly the combination this article is about: someone who understands testing fundamentals, can engineer automation solutions, and can think strategically about how those solutions deliver value.
If you are working toward Test Automation Pro or exploring the path, the certification overview explains how the three certifications fit together and what each one covers.
FAQ
What is the difference between test automation strategy and test automation engineering?
Engineering is the technical layer: how to build automation solutions that are modular, maintainable, and well-integrated. Strategy is the decision-making layer: what to automate, why, how to measure success, and how the automation program fits the organization's goals. ISTQB has a certification for each, and both are required for the ASTQB Test Automation Pro designation.
Do you need a strategy for a small team?
Yes. The scale of the strategy changes, but the questions do not. Even a team of two writing automated tests benefits from being explicit about what they are trying to accomplish, which tests to prioritize, and how they will know if the effort is paying off.
Is test automation strategy only for test managers?
No. Any engineer making decisions about what to build and how to structure a test suite is doing strategic thinking whether they call it that or not. The ISTQB Test Automation Strategy certification is described by ASTQB as appropriate for testers, test analysts, automation engineers, test consultants, test architects, test managers, software developers, project managers, and business analysts.
What happens when there is no strategy?
Without strategy, automation tends to accumulate without direction: coverage is uneven, maintenance costs are unpredictable, ROI is unclear, and it is difficult to explain the value of the program to stakeholders. Eventually, confidence in the suite erodes and it gets used less and less.