- CT-TAS (Certified Tester Test Automation Strategy) is the ISTQB certification for planning test automation strategically: what to automate, with what resources, at what cost, how to measure its value and how to scale it across the organization.
- It is a Specialist module, version 1.0 (May 2024). Prerequisite: the ISTQB Foundation Level (CTFL) certificate.
- It has 6 chapters and requires at least 12.75 hours of accredited training.
- The exam: 40 questions, 60 minutes (75 in a non-native language), and you pass with 32 out of 49 points (65%).
- It is the strategic counterpart to CTAL-TAE: TAE is the technical how (architecture, frameworks, scripts); TAS is the what, when and why (investment, ROI, risks, roles, deployment).
- Ideal for test leads, test managers, test architects and experienced automation engineers who need to justify or scale automation.
Almost every company "automates". Far fewer can answer questions like these with data: when do we break even? Why do we have 2,000 UI tests and almost no API tests? Should we buy a tool or go open source? Which metrics do we show leadership? Without those answers, automation becomes an expensive project nobody can prove is worth it.
The ISTQB CT-TAS certification is built for exactly that. In this guide I explain what it is, how it differs from CTAL-TAE, what the syllabus covers chapter by chapter, what the exam looks like and how to prepare.
What CT-TAS is and where it sits in the ISTQB portfolio
CT-TAS is an ISTQB Specialist module released as version 1.0 on May 3, 2024. The syllabus describes it this way: it presents the many factors that come into play when planning test automation in an organization, and it leaves technical implementation out of scope, since that is covered by the CTAL-TAE syllabus. Its purpose is to provide a strategic view of implementing automation across projects in a systematic, consistent way that demonstrates value to the organization.
CT-TAS vs. CTAL-TAE
| CT-TAS (Specialist) | CTAL-TAE (Core Advanced) | |
|---|---|---|
| Core question | What, when and why to automate, and how to scale it? | How do I design, build and maintain the automation solution? |
| Key topics | Cost of ownership, licensing, roles, test distribution, ROI, metrics, deployment, transition to continuous testing | Automation architecture, layers, frameworks, implementation, reporting, maintenance |
| Profile | Test lead, test manager, architect, senior TAE | Automation engineer, SDET, developer |
| Exam | 40 questions, 60 min | 40 questions, 90 min |
One detail that trips people up: inside the syllabus, TAS is also used for Test Automation Solution (the automation solution the team builds) and TAE for the Test Automation Engineer, the person. Do not confuse them with the certification names.
Which one first? If you are technical and build frameworks, start with CTAL-TAE. If you lead, own the budget or defend automation to leadership, CT-TAS pays off faster. Ideally an automation leader holds both. See the full certification map in our ISTQB certification guide.
Who it is for and prerequisites
The syllabus targets anyone involved in testing and automation: testers, test analysts, test automation engineers, test consultants, test architects, test managers and developers, as well as people who need a basic understanding: project managers, quality and development managers, business analysts, IT directors and consultants.
- Formal prerequisite: the ISTQB Foundation Level certificate (CTFL v4.0 or earlier). If you need it, see our ISTQB Foundation Level 4.0 course.
- Strongly recommended: experience as a senior test engineer, test lead or developer, plus some experience bringing technology into the enterprise. ISTQB also asks for "sufficient practical experience" and leaves the specific criteria to the member board or exam provider.
- Not needed: expert-level programming, although you should understand how an automated suite runs in a pipeline.
What you will be able to do: business outcomes
The syllabus defines 15 business outcomes (TAS-BO1 to TAS-BO15). In summary, a certified person can:
- Understand the software and system factors that influence automation success.
- Identify the costs and risks of implementing an automation solution.
- Understand the roles and responsibilities of the people who contribute to automation.
- Plan the integration of automation across test levels.
- Identify strategic considerations in different lifecycle models.
- Understand the applicability and viability of automation.
- Plan solutions that meet organizational needs and understand deployment strategies.
- Understand automation dependencies in the test environment.
- Understand the costs of setting up and maintaining automation.
- Know which metrics drive decisions and which reports each stakeholder needs.
- Identify how automation brings value to the project and the organization.
- Define the transition from manual to automated testing.
- Define a strategy where projects share assets and methods for consistent implementation across the organization.
Learning objectives are at K2 (understand) and K3 (apply).
Syllabus content chapter by chapter
| Chapter | Minimum time | Key topics |
|---|---|---|
| 1. Introduction and Objectives for Test Automation Strategy | 45 min | Automation objectives, technical success factors, investment criteria for selecting projects |
| 2. Test Automation Resources | 60 min | Cost of ownership (in-house, vendor, outsourcing), licensing models, strategy factors, roles and skills |
| 3. Preparing for Test Automation | 225 min | Test distributions (pyramid and others), approach by architecture, shift left and shift right, sequential, Agile and DevOps lifecycles, what to automate and what not to |
| 4. Organizational Deployment and Release Strategies | 135 min | Time to market, defect verification, operational scenarios, deployment strategy, risks and mitigation, environment dependencies, data and interfaces |
| 5. Test Automation Impact Analysis | 150 min | ROI, metrics, organizational considerations, project characteristics, decisions from reports |
| 6. Implementation and Improvement Strategies | 150 min | Manual to automated and automated to continuous testing transitions, evaluating assets and practices for improvement |
Chapter 1. Introduction and Objectives for Test Automation Strategy
A short chapter that sets the starting point: defining clear goals and objectives for automation (not "automate everything", but, for example, "cut regression from 5 days to 4 hours so we can release every two weeks"), identifying the technical success factors of an automation project and summarizing the investment criteria for choosing good candidate projects. A stable system with a long life ahead and frequent releases is a better candidate than one being retired in six months.
Chapter 2. Test Automation Resources
This is about money and people. First it compares the cost of ownership of three paths: an in-house solution on open-source or commercial tools, a vendor solution, or outsourcing the automation. Each splits control, risk and cost differently.
Then come licensing models: open source (no license fee and a community, but internal support costs), per-user or per-machine licenses, floating licenses (based on concurrent use) and runtime licenses, typical of cloud device and browser farms where you pay per use.
Next, the strategy factors: available time, level of expertise and number of engineers, hardware, licenses, adaptability, maintenance, platforms (web, desktop, mobile), CI/CD support and integration with test management and reporting. It closes with roles and skills: automation engineers with strong programming and architecture knowledge, at least one domain expert who drives the concept and roadmap, and leadership to build the team. It also offers a healthy reminder: just as exhaustive testing is impossible, 100% automation is not achievable.
Chapter 3. Preparing for Test Automation
The longest chapter. It starts with automated test distributions based on Mike Cohn's pyramid (component, service and UI) and its problematic shapes:
- Pyramid: many fast tests at the bottom and few at the top. The usual target state.
- Ice cream cone: the inverted pyramid; most defects are found at the UI level, the most expensive to automate and maintain.
- Hourglass: heavy at the top and bottom, almost nothing at the service level; integration defects appear.
- Umbrella: everything depends on costly UI tests; slow feedback and expensive maintenance.
A very useful exercise from the syllabus: draw your current distribution and your target. If your business runs on APIs, many UI tests can move down to the service layer with component integration, contract and API tests.
It then explains how to choose an approach based on the architecture of the system under test, how to optimize the distribution to achieve shift left and shift right (K3), and how automation fits into sequential, Agile and DevOps lifecycles with continuous testing (K3).
It closes with viability. Criteria for choosing what to automate: is it technically possible? Is the team ready? Is there an ROI? Will it run often? Is it repeatable and easy to maintain? Does it cover frequent business workflows? Challenges only automation can address: manual execution that takes too long, synchronization, results needed in a pipeline, parsing large logs, timing precision, permutations across operating systems, browsers and devices, large data volumes and non-functional testing such as stress or reliability testing. And conditions that are hard to automate: visual consistency across platforms, processes with heavy human involvement (such as manual review of a loan application), OS restrictions or very long waits, such as a two-hour inactivity logout.
Chapter 4. Organizational Deployment and Release Strategies for Test Automation
This chapter brings strategy down to earth. First, planning: how automation shortens time to market, how it helps verify reported defects and how to build operationally relevant scenarios, that is, tests that reflect how users actually use the system.
Then, the deployment strategy for the automation solution and its risks. The syllabus lists technical issues (too many abstractions that make it hard to see what the code really does, huge test data tables that cannot be migrated between environments, dependencies on libraries not available in every environment), project risks (lack of people to maintain it, unplanned maintenance due to system changes, delays, non-standard UI objects, outdated test cases that keep wasting execution time) and failure points such as migrating to another environment or deploying to production, and above all forgetting that automation is software and must be tested too. To mitigate them: configuration management, a documented and versioned deployment procedure, and treating first-time deployments differently from maintenance deployments.
Finally, dependencies within the test environment: automation components, infrastructure and the data and interface requirements for integrating with the system under test.
Chapter 5. Test Automation Impact Analysis
The chapter leaders appreciate most. It starts with return on investment (ROI = savings / investment), a K3 objective. Savings consider manual and automated time per test case, number of test cases and number of runs; investment considers setup time, script development and maintenance, execution time and the percentage of failing scripts.
A simple example using the syllabus model (in hours, not money): 200 regression test cases that take 10 minutes manually and 1 minute automated. Each run saves 200 × 9 min = 30 hours. The upfront investment is 80 hours of setup plus 100 hours of development (30 minutes per script), and each run costs about 5 hours of maintenance and analysis. Net savings per run are 25 hours, so the 180-hour investment pays back from the eighth run. If the project will only have five regression cycles, the syllabus is clear: automation would not pay off.
It then classifies automation metrics: pass-fail ratio, ratio of failures to real defects (how many failures are automation problems), execution time, number of automated test cases, functional coverage and code coverage. Next it analyzes value to the organization (policies, active projects, experts, environments, licenses) and the project characteristics that determine the best implementation: domain, platforms, language and stack, maturity, stakeholder buy-in, team knowledge, budget and quality characteristics. It closes with how to analyze reports to support decisions.
Chapter 6. Implementation and Improvement Strategies for Test Automation
The final chapter is about evolution. First, the transition from manual to automated testing: transition costs, functional overlap, shared data, test interdependency, preconditions, coverage and executable tests. Then the transition to continuous testing: adapting suites, stubs, drivers, interfaces and infrastructure to the updated solution and integrating it into the CI/CD pipeline.
It ends with a K3 objective: evaluating automation assets and practices to find improvements. Some syllabus recommendations: track hours spent building, fixing and saved; define consistent infrastructure and configuration across projects; create shared development guidelines; modularize scripts for reuse; remove overlaps; and if automation is making the pipeline queue up, run only a smoke suite on each change and trigger the full regression separately or on demand.
Download the official syllabus
The syllabus is available in English and Spanish. Everything is examinable except the introduction and appendices.
The CT-TAS exam
Verified structure
| Item | Value |
|---|---|
| Questions | 40, multiple choice |
| Total points | 49 |
| Passing score | 32 points (65%) |
| Duration | 60 minutes; 75 in a non-native language |
| Prerequisite | ISTQB Foundation Level certificate |
| Cognitive levels | K2 and K3 |
Source: the CT-TAS page on istqb.org and the official ISTQB exam structure tables. Expect scenario questions ("given this situation, what would you recommend?") and at least one ROI calculation.
Exam options
- Online from home (iSQI FLEX): remote proctoring 24/7 with a webcam, microphone, your phone as a second camera and a government-issued ID.
- Pearson VUE: test center or OnVUE.
- At your company: for 6 or more people, Cool Testers brings a proctor.
Paper exams are no longer offered.
Where to buy it
You can buy it directly from iSQI, our partner and official exam provider, or through Cool Testers with our certification exam (1 or 2 attempts), ideal if your employer pays or you need an invoice. You have 1 year to take it. Want help choosing? Message us on WhatsApp.
How to prepare
- Review CTFL 4.0, especially the test pyramid, test levels and the tools section.
- Read the syllabus in the language you will sit the exam in. The lists (factors, criteria, metrics, risks) are typical exam material.
- Practice ROI calculations with your own project: count real test cases, times and runs and find the break-even point.
- Draw the test distribution of your current system and your target. Check whether you have an ice cream cone or an umbrella.
- Write a one-page strategy for your team: objectives, scope, tools and licenses, roles, metrics and transition plan. It is the best way to lock in all six chapters.
- Work through the official sample exam on istqb.org.
- Combine theory and practice. Our Build a Test Automation Practice course focuses on the organizational side of bringing automation into a company, and the ISTQB Test Automation Engineering course covers the technical CTAL-TAE side. Both are available on demand for companies; request a quote.
Benefits and career paths
- Speak leadership's language: ROI, cost of ownership, risks and metrics. That is what turns a good automator into an automation leader.
- Target roles: test automation lead, test architect, QA manager, automation consultant.
- Better-grounded decisions: tools, licenses, outsourcing or an in-house team, and what not to automate.
- Scaling across the organization: the syllabus is designed to move you from isolated projects to a common strategy with shared assets.
- The perfect complement to TAE: together they cover strategy and technical execution.
Related certifications and next steps
- Before: CTFL 4.0 (mandatory).
- Natural pair: CTAL-TAE, automation engineering. If you lead, take TAS and then TAE; if you are technical, the other way around.
- DevOps: CT-QDO to take automation into continuous testing in a pipeline.
- Management: CTAL-TM and, later, Expert Test Management.
- Agile: CTAL-ATT (while still available) or CT-ATLaS.
- AI: CT-GenAI, increasingly part of automation strategies.
If you are choosing a tool, our comparison Playwright vs Selenium vs Cypress may help.
Frequently asked questions
What is the difference between CT-TAS and CTAL-TAE?
CT-TAS is strategic: what to automate, costs, ROI, roles, metrics and deployment across the organization. CTAL-TAE is technical: how to design, build and maintain the automation solution.
What is the prerequisite for CT-TAS?
The ISTQB Foundation Level (CTFL) certificate and sufficient practical experience. CTAL-TAE is not required.
What does the CT-TAS exam look like?
40 multiple-choice questions worth 49 points; you pass with 32 (65%). It lasts 60 minutes, or 75 in a non-native language.
Do I need to know how to code?
It is not required and the exam has no code. Still, understanding how an automated suite works helps a lot with the syllabus.
Is there a Spanish syllabus?
Yes. A Spanish version of the v1.0 syllabus is available alongside the English original.
How much study time do I need?
An accredited course lasts at least 12.75 hours. If you self-study, add practice applying the concepts to your own project.