- CTAL-TAE (Certified Tester Advanced Level Test Automation Engineering) is ISTQB's certification for people who design, build and maintain test automation solutions. The current version is 2.0 (2024).
- Prerequisite: ISTQB Foundation Level (CTFL). Development or testing experience and programming skills are recommended.
- The syllabus has 8 chapters: objectives, preparation, architecture, implementation, CI/CD, reporting and metrics, verification and continuous improvement.
- The exam has 40 questions worth 66 points, the pass mark is 43 (65%) and it lasts 90 minutes (113 if it is not your native language).
- It is tool-neutral: what you learn applies to Playwright, Selenium, Cypress, Appium, Postman or anything else.
- We offer the ISTQB Test Automation Engineer course on demand for companies, online or on-site.
Anyone can record a script that clicks through a page. The hard part comes next: keeping a hundred tests working when the UI changes, running them unattended in the pipeline, making their results useful for decisions and keeping maintenance costs from eating the benefit. That is the territory of the ISTQB Test Automation Engineering (CTAL-TAE) certification.
In this guide I explain what version 2.0 is, who it is for, what the syllabus covers chapter by chapter with practical examples, what the exam looks like and how to prepare.
What CTAL-TAE is and where it sits in the ISTQB portfolio
CTAL-TAE is an Advanced Level module in the ISTQB portfolio, alongside Test Analyst, Technical Test Analyst and Test Management. Version 2.0 was released in May 2024 and replaced the 2016 version (previously called "Test Automation Engineer"), which ISTQB has put into its sunset phase.
Version 2.0 modernized the content: integration with CI/CD pipelines, API and contract testing, design patterns such as Page Object and Flow Model, SOLID principles, static analysis of automation code and the use of AI for tasks such as self-healing locators.
Its natural companion is Test Automation Strategy (CT-TAS): TAE is the technical "how to build it"; TAS is the strategic "what and why" at organization level. For the full map and costs in your currency, see our ISTQB certification guide.
Who it is for and prerequisites
The syllabus says CTAL-TAE is aimed at anyone involved in testing and test automation: testers, test analysts, test automation engineers, test consultants, test architects, test managers and software developers. It also suits people who need to understand automation without building it: project managers, quality and development managers, business analysts and IT directors.
- Formal prerequisite: the ISTQB Foundation Level (CTFL) certification before taking the exam. If you don't have it, start with our ISTQB Foundation Level 4.0 course.
- Recommended: at least six months of experience as a test engineer or developer, and an accredited course.
- Programming: the syllabus states that it does not teach software engineering but expects a test automation engineer to have software engineering skills and experience. In practice, you should already have automated something with some language and tool.
What you will be able to do: business outcomes
The syllabus defines 12 business outcomes:
| Code | A certified TAE can... |
|---|---|
| TAE-B01 | Describe the purpose of test automation |
| TAE-B02 | Understand test automation through the software development lifecycle |
| TAE-B03 | Understand the configuration of an infrastructure that enables test automation |
| TAE-B04 | Learn the evaluation process for selecting the right tools and strategies |
| TAE-B05 | Understand design concepts for building modular and scalable automation solutions |
| TAE-B06 | Select an approach, including a pilot, to plan automation deployment |
| TAE-B07 | Design and develop new or modified automation solutions that meet technical needs |
| TAE-B08 | Consider the scope and approach of automation and the maintenance of testware |
| TAE-B09 | Understand how automated tests integrate into CI/CD pipelines |
| TAE-B10 | Collect, analyze and report on automation data to inform stakeholders |
| TAE-B11 | Verify the test automation infrastructure |
| TAE-B12 | Define continuous improvement opportunities for test automation |
Objectives are examined at K2 (understand), K3 (apply) and K4 (analyze).
Syllabus content chapter by chapter
| Chapter | Time | Key topics |
|---|---|---|
| 1. Introduction and Objectives for Test Automation | 45 min | Pros and cons, automation in waterfall, V-model and agile, tool selection |
| 2. Preparing for Test Automation | 180 min | Infrastructure, environments (local, build, integration, preproduction, production), SUT analysis, tool evaluation |
| 3. Test Automation Architecture | 210 min | gTAA, solution design, framework layers, scripting approaches, OOP, SOLID, design patterns |
| 4. Implementing Test Automation | 150 min | Pilot and deployment, deployment risks, maintainability |
| 5. Implementation and Deployment Strategies | 90 min | Tests in pipelines, testware configuration management, API dependencies, contract testing |
| 6. Test Automation Reporting and Metrics | 150 min | Data collection, logs, result analysis, reports and dashboards |
| 7. Verifying the Test Automation Solution | 135 min | Verifying environment and tools, correct test behavior, unexpected results, static analysis |
| 8. Continuous Improvement | 210 min | Data-driven test improvement, technical recommendations, refactoring testware, tool opportunities |
The syllabus sets a minimum of 21 hours of accredited training in total (the per-chapter times in the table add up to 19.5 hours).
Chapter 1. Introduction and Objectives for Test Automation
It starts with the basics, but with an engineer's eye. Advantages: more tests in less time, unattended execution, fast feedback, consistency and tests that would be impossible by hand (thousands of data combinations, load). Disadvantages: upfront costs, maintenance, the need for technical skills, a false sense of security and the risk of automating bad tests.
It explains how automation differs in waterfall, the V-model and agile, where automation happens inside the sprint and at every level, and how to select suitable tools for a given system: SUT technology (web, mobile, API, desktop), team languages, pipeline integration, licensing and community.
Chapter 2. Preparing for Test Automation
Before writing a line of code, you prepare the ground. The chapter describes what the infrastructure needs (access to the SUT, test data, environments, controllability and observability, test interfaces) and how automation is used in each environment: the developer's local environment, build, integration, preproduction and production (for example, smoke tests after deployment).
Its two K4 objectives are among the most important on the exam: analyze a SUT to determine the right automation solution and illustrate the technical findings of a tool evaluation. Example: a React web app with a REST API, a team that codes in TypeScript and a pipeline on GitHub Actions. The analysis would lead to automating most checks at the API layer, a small set of UI flows with a TypeScript-friendly tool, and documenting the evaluation with comparable criteria.
Chapter 3. Test Automation Architecture
The most technical chapter and one of the longest (210 minutes). It presents the generic test automation architecture (gTAA), with its interfaces to the SUT, project management, test management and configuration management, and its capabilities: test generation (optional, for example from models), definition, execution (with logging and reporting) and adaptation (adaptors that connect to the SUT via APIs, protocols or UI).
Then it explains the test automation framework (TAF) layers, which you need to be able to apply (K3):
- Test scripts: test cases and suites; they call the business logic layer, never the core libraries directly.
- Business logic: SUT-dependent libraries (steps, user flows, API calls).
- Core libraries: SUT-independent, reusable in any project on the same stack.
It compares approaches to automating test cases with their pros and cons: capture/playback, linear scripting, structured scripting, TDD, data-driven, keyword-driven and BDD. And it closes with design principles: the four object-oriented programming principles (encapsulation, abstraction, inheritance and polymorphism), the SOLID principles and the most important patterns for a TAE: facade, singleton (a single driver talking to the SUT), the Page Object Model and the Flow Model, which adds a facade of user actions on top of the page objects.
Example: if the "Pay" button changes its identifier and 80 tests use it, with Page Object you fix the locator in one place. With Flow Model, the "complete purchase" action also lives in a single method reused by every test.
Chapter 4. Implementing Test Automation
This covers taking automation from paper to project. First, the pilot (K3): define scope, language, tools, test levels, selected test cases and development approach; build prototypes to compare options; integrate into CI/CD from the pilot onward; and evaluate non-technical aspects such as team experience, structure and licensing. When it ends, the TAE and the test manager evaluate the outcome and decide.
Next, analyzing deployment risks and planning mitigation (K4): packaging, logging, test structuring and updates. Finally, the factors that support or hurt maintainability: naming conventions, modularity, documentation, test independence, data handling and wait handling.
Chapter 5. Implementation and Deployment Strategies
Here automation connects with DevOps. The K3 objective is to apply test automation at different test levels within pipelines: configuration tests of the framework itself and component tests during the build, component integration in continuous integration, system and system integration tests as quality gates in continuous delivery or deployment, plus nightly regression and periodic non-functional tests. The syllabus compares two ways of running system tests: inside the deployment phase (they can stop and roll back a deployment) or in a separate pipeline (more flexible, but they don't act as a quality gate).
It also explains testware configuration management (environment configuration, data, suites and test cases under version control) and API testing dependencies: connections between APIs, documentation and contract testing, consumer-driven or provider-driven, to verify that two services communicate according to an agreed contract. If you work with APIs, our API automation with Postman training is a good hands-on complement.
Chapter 6. Test Automation Reporting and Metrics
Automation nobody understands is useless. The chapter covers how to collect data (K3) from the solution and the SUT: test logs, automation solution logs, SUT logs, integration with other tools and visualization. The K4 objective is to analyze that data to understand the results: telling a real SUT defect apart from an environment or test problem. It ends with how to build and publish a test progress report, who to report to, how to create dashboards and the use of AI and machine learning to analyze logs.
Chapter 7. Verifying the Test Automation Solution
Who tests the tests? This chapter. It includes planning the verification of the environment (K3): tool installation and configuration, repeatable setup and teardown, connectivity with internal and external systems, and testing the framework's components. Then how to verify that a test or suite behaves correctly (suite composition, repeatability, tool intrusiveness), how to investigate unexpected results (intermittent tests, false positives and false negatives, missing assertions) and how static analysis improves automation code. A classic example from the syllabus: a plaintext password inside a test script, which a static analysis tool catches before it reaches the repository.
Chapter 8. Continuous Improvement
The last chapter carries as much training time as architecture (210 minutes) and accounts for 13 of the exam's 66 points. It covers:
- Improving test cases with data (K3): result histograms to find fragile tests, AI for self-healing locators and schema validation for APIs and databases, which saves writing dozens of individual assertions.
- Analyzing a deployed solution and recommending improvements (K4): scripting, execution, verification, architecture, framework, setup and teardown, documentation, features and updates.
- Restructuring testware when the SUT changes (K3): consolidating functions, refactoring the architecture, standardizing names and retiring obsolete scripts.
- Other tool opportunities: environment control, data aging, screenshot and video generation.
Download the official syllabus
All sections are examinable except the introduction and appendices.
The CTAL-TAE exam
Verified structure
| Item | Value |
|---|---|
| Questions | 40 multiple-choice |
| Total points | 66 (K2 = 1 point, K3 = 2, K4 = 3) |
| Pass mark | 43 points (65%) |
| Duration | 90 minutes; 113 if you take it in a language that is not your native one (+25%) |
| Cognitive levels | 20 K2, 14 K3 and 6 K4 questions |
| Prerequisite | ISTQB Foundation Level (CTFL) |
Distribution by chapter according to ISTQB's official tables:
| Chapter | Questions | Points |
|---|---|---|
| 1. Introduction and objectives | 3 | 3 |
| 2. Preparation | 5 | 9 |
| 3. Architecture | 6 | 10 |
| 4. Implementation | 4 | 7 |
| 5. CI/CD and deployment | 6 | 8 |
| 6. Reporting and metrics | 4 | 8 |
| 7. Verification | 6 | 8 |
| 8. Continuous improvement | 6 | 13 |
Exam options
- Online from home with remote proctoring (iSQI FLEX): available 24/7; for Advanced exams, book at least 48 hours ahead. You need a webcam, a microphone, a second camera using your phone and a government-issued ID.
- Pearson VUE: at a test center or online with OnVUE.
- On-site at your company: for groups of 6 or more, Cool Testers brings a proctor.
Paper-based exams are no longer offered.
Where to buy it
The exam is not included in the course. You have two options:
- Directly from iSQI, our partner and official exam provider, with a 20% coupon off the price on their site for your first attempt, which we send when you enroll. Best if you are paying yourself.
- Through Cool Testers: our certification exam with 1 or 2 attempts. A good fit if your company pays or you need an invoice. You have 1 year to take it.
How to prepare
7-week plan
| Week | What to study | Goal |
|---|---|---|
| 1 | Chapters 1 and 2 | Analyze a real SUT and write a tool evaluation with criteria |
| 2 | Chapter 3 | Draw your project's gTAA and split your code into layers |
| 3 | Chapter 3, patterns | Implement Page Object and Flow Model in a mini project |
| 4 | Chapters 4 and 5 | Pilot plan, deployment risks and a pipeline with tests per level |
| 5 | Chapters 6 and 7 | Results dashboard; investigate a flaky test |
| 6 | Chapter 8 | Propose technical improvements to an existing solution |
| 7 | Sample exam | Practice K3 and K4; review keywords |
Common mistakes
- Studying through the lens of your tool. The exam is tool-neutral: it asks about concepts, not Playwright or Selenium syntax.
- Underestimating chapter 8. It carries the most points.
- Mixing up layers. In the syllabus, scripts never call the core libraries directly.
- Studying 2016 material. The structure and objectives changed.
Our ISTQB Test Automation Engineer course
Our ISTQB Test Automation Engineer course is delivered on demand for companies: online or on-site, on your dates, with a certified instructor and examples tailored to your team's technology. Request a quote. If you are an individual and want to know when we open a group, let us know on WhatsApp.
For hands-on tool work, we run open groups for Playwright, Selenium and Postman, and for companies, Build a Test Automation Practice.
Benefits and career paths
- From scripter to engineer: it shows you can design maintainable architectures, not just write scripts.
- Tool-neutral: what you learn survives a change of framework.
- DevOps: you integrate tests as quality gates in real pipelines.
- Decision-ready arguments: you can evaluate tools, plan pilots and measure results, which is what leaders ask for before investing.
- For companies: a team that builds automation on a shared architecture reduces maintenance and dependence on a single person.
Typical roles: test automation engineer, SDET, QA automation lead, automation architect and QA in DevOps teams.
How it relates to other certifications and what comes next
- Before: CTFL 4.0, mandatory.
- Strategy: Test Automation Strategy (CT-TAS), the natural next step according to the syllabus itself.
- Technical: Technical Test Analyst (CTAL-TTA).
- DevOps: Quality in DevOps (CT-QDO).
- Specialties: Performance Testing, Mobile Application Testing and Model-Based Testing.
- AI: CT-GenAI.
Frequently asked questions
Do I need to know how to code for CTAL-TAE?
The syllabus doesn't teach programming, but it assumes software engineering skills. In practice, you should have automated tests in some language before taking the exam.
What is the prerequisite for the exam?
The ISTQB Foundation Level (CTFL) certification. At least six months of testing or development experience is recommended.
How many questions does the CTAL-TAE v2.0 exam have?
40 multiple-choice questions worth 66 points. You pass with 43 (65%). You have 90 minutes, or 113 if you are not taking it in your native language.
Does the exam ask about Selenium, Playwright or another tool?
No. The syllabus is tool-neutral: it covers architecture, design, integration, metrics and improvement, which apply to any tool.
What is the difference between CTAL-TAE and CT-TAS?
CTAL-TAE is technical: how to design, build and maintain the solution. CT-TAS is strategic: how to define and govern automation across the organization.
Do you run open TAE groups?
We deliver it on demand for companies, online or on-site. If you are an individual, message us on WhatsApp and we will let you know when we open a group.
Is the exam included in the course?
No. You can buy it directly from iSQI with the 20% coupon we send when you enroll, or through Cool Testers if your company pays or you need an invoice.