ISTQB CTAL-TAE v2.0 Syllabus: What Changed Since the 2016 Edition

Updated on 12 October 2026. What’s new: the current pass mark is 43 points out of 66, across 40 questions, on ISTQB's exam page

ISTQB did not patch the Test Automation Engineering syllabus for version 2.0. It rewrote it. The May 2024 release replaced the 2016 edition, kept the engineer's own work (architecture, pipelines, upkeep) and moved the strategy material into a separate CT-TAS syllabus. The paper is 40 questions in 90 minutes, and you need 43 of the 66 points to pass.

Many articles about this exam still describe it as a light refresh with "AI and DevOps added". That is not what the syllabus says about itself. Below is what ISTQB actually changed, what each chapter now examines, how the six scripting approaches differ, and a study route that fits someone who already writes automation code. Everything about the syllabus comes from ISTQB's own v2.0 PDF, and everything about the exam from the vendor's exam page, both read in October 2026.

What did ISTQB change when it replaced the 2016 syllabus?

The syllabus's own revision history lists two releases: the general availability release of 21 October 2016 and the v2.0 release of 3 May 2024. Its release-notes appendix is short and unusually frank. It calls the 2024 text "a major update and rewrite of release 2016", says that for this reason there are no release notes chapter by chapter, and gives two reasons: the content has been "significantly enhanced for the test automation engineering role", and strategic content has moved to the new Test Automation Strategy syllabus.

Read that as a change of job description. The 2016 syllabus tried to serve both the person who builds the automation and the person who decides whether and how to automate. The 2024 syllabus keeps the builder. Decisions about return on investment, rollout and organisational strategy now belong to the CT-TAS certificate, which is a separate exam. If you studied for the older paper, expect less management vocabulary and a lot more engineering vocabulary.

What the engineering emphasis looks like in the text

• Design patterns are named. The facade pattern, the singleton pattern and the page object model are spelled out, together with encapsulation, abstraction, inheritance, polymorphism and the five SOLID principles. The syllabus says outright that test automation is a software development activity.
• Pipelines have their own chapter. Chapter 5 puts test levels into CI/CD pipelines and covers testware configuration management and contract testing for API dependencies.
• Infrastructure is examinable. Testability, observability, controllability and the five kinds of environment (local development, build, integration, pre-production and production) appear in Chapter 2.
• Verification of the automation itself is a chapter. Chapter 7 asks how you know your own scripts and tool setup behave correctly, including static analysis of automation code.
• Improvement is concrete. Chapter 8 covers wait mechanisms, schema validation, test histograms and restructuring testware when the system changes.

What did not change, and what is overstated elsewhere

Artificial intelligence does appear, but as a short topic inside Chapter 8, not as a theme of the rewrite. The syllabus mentions tools that use machine learning to read test logs and tools that use image recognition to repair locators automatically, which it calls self-healing. That is a paragraph or two of the examinable text. Likewise, "cloud-based and containerised testing" is not a heading anywhere: containers and virtualisation are mentioned once, as ways to create test environments. Study the chapters, not the headlines.

Which exam is this today, and what does ISTQB call it?

ISTQB's own page is titled "Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) v2.0", and the syllabus file is named ISTQB_CTAL-TAE_Syllabus_v2.0. Some candidates and course sellers shorten it to CT-TAE or just "TAE 2.0". They all mean the same paper. Version 2.0 is the version ISTQB lists as current in October 2026, and it is the version our own CTAL-TAE syllabus page covers.

Exam detail	CTAL-TAE
Exam code	CTAL-TAE
Vendor	ISTQB
Full name	ISTQB Certified Tester Advanced Level Test Automation Engineering
Version	Version 2.0
Price (USD)	$249
Duration	90 minutes
Questions	40
Passing score	43 / 66

Because 40 questions are worth 66 points, some questions are worth more than one point, so a few heavy scenario questions matter more than their count suggests. The exam is booked through an exam provider that ISTQB or your national member board lists. Confirm the final amount with your chosen provider when you book.

Who may sit it?

ISTQB's page says candidates must hold the Foundation Level certificate, version 4.0 or any earlier version, and have "sufficient practical experience". The syllabus is more specific about what it recommends: about six months as a test engineer or developer, and an accredited course. It adds that the syllabus does not teach software engineering, so you are expected to bring programming skill with you. That last sentence is the best warning in the document for anyone planning to learn the material from a standing start.

Where does each of the eight chapters put its weight?

The syllabus gives every chapter a time allocation and a highest cognitive level. Added together, the chapters come to 1,170 minutes of teaching. K2 means you must understand, K3 apply and K4 analyse, so the chapters marked K4 are the ones where questions are built around a described situation rather than a definition.

Chapter	Minutes	Highest level	Learning objectives
1 Introduction and objectives for test automation	45	K2	3
2 Preparing for test automation	180	K4	4
3 Test automation architecture	210	K3	5
4 Implementing test automation	150	K4	3
5 Implementation and deployment strategies	90	K3	3
6 Test automation reporting and metrics	150	K4	3
7 Verifying the test automation solution	135	K3	4
8 Continuous improvement	210	K4	4

Two things stand out. First, the architecture chapter and the continuous-improvement chapter are tied for the longest slot, yet they ask for different skills: Chapter 3 wants you to apply patterns, Chapter 8 wants you to analyse a deployed solution and recommend changes. Second, the introduction is only 45 minutes. Candidates who spend a week on the advantages and disadvantages of automation are studying the smallest part of the paper.

The twenty-nine learning objectives are the real checklist. Every one begins with a verb such as explain, apply, analyse or restructure, and the exam questions follow that verb. If an objective says "apply layering of test automation frameworks", expect a scenario in which you must place a piece of code in the correct layer, not a request to define the word layer.

How do the scripting approaches differ, and when does each one stop paying off?

Section 3.1.4 compares seven ways to produce automated tests. It is the most table-friendly part of the syllabus, and questions often hand you a project description and ask which approach suits it. The summary below paraphrases the syllabus's own pros and cons.

Approach	What it is	Where it helps	Where it breaks
Capture/playback	Records a manual session and replays it	Quick to start, little code	Hard to maintain, needs the system available to record, only fits a small and stable scope
Linear scripting	Hand-written scripts without custom libraries	Easier to edit than recordings	Same scaling limits, and some programming is needed
Structured scripting	Reusable steps and user journeys in test libraries	Easy to maintain, port and extend; business logic separated from scripts	Needs programmers and an up-front investment in the framework
Test-driven development	Failing test first, then code, then refactor	Better code structure, fewer defects reaching higher levels	Slow to learn; done badly it gives false confidence
Data-driven testing	One script run against many rows of data	Cheap to add cases; analysts can specify tests in data files	Needs real test data management
Keyword-driven testing	Test steps written as keywords from the user's viewpoint	Business and test analysts can take part	Keywords are costly to build, and large effort for a small system
Behavior-driven development	Given-when-then scenarios in feature files	Shared language between developers, business and testers	Edge cases still need adding, and over-complex steps make debugging costly

Two traps the syllabus points out

The first is the no-code label. Tools that hide the generated script are called no-code, tools that expose it are called low-code, and both belong to the capture/playback family with its maintenance problems. The second is a warning aimed at BDD: many teams treat it as only a way of writing test cases in natural language and leave out the business representatives and developers, which removes most of the point. If a question describes a team in that situation, the answer is about collaboration, not about tooling.

A worked comparison

Picture a login check that must run with forty different user accounts. Written as a linear script, you duplicate the steps forty times and edit each copy when the login page changes. Written as a structured script, the login steps live once in a library. Fed by a data file, the same script runs forty times from forty rows. Written as keywords, an analyst who cannot code can put "login with account type" in a table. Each version is the same test, and each puts the maintenance cost in a different place, which is exactly the judgement the objective asks you to make.

What does the architecture chapter expect you to be able to design?

Chapter 3 starts with the generic test automation architecture, or gTAA, a high-level model of how automation talks to everything around it. It defines four interfaces: to the system under test, to project management, to test management and to configuration management. It also names four capabilities that tools and libraries provide.

• Test generation creates test cases from a test model, and is optional. Model-based testing tools can supply it.
• Test definition holds test cases and suites separately from the system under test and the tools.
• Test execution runs the selected tests and includes logging and reporting.
• Test adaptation connects the tests to the system through APIs, protocols and services.

The test automation solution is what you build from these: tools, libraries, plug-ins and adaptors. At its centre sits the framework, usually a test harness (also called a test runner) plus libraries, scripts and suites. The syllabus's advice on layers is deliberately modest: keep the number low, because a layer for every single purpose makes the design complicated.

The three layers to place correctly

Test scripts hold the test cases and suite annotations and call services in the business-logic layer, and they must not call the core libraries directly. Business logic holds every library that depends on the system under test and either inherits from the core libraries or uses their facades. Core libraries hold everything that is independent of any one system, so a second project on the same technology stack can reuse them. The syllabus's example has two framework builds sitting on one set of core libraries, with a second engineer building a third for another application.

Design patterns, in one line each

• The facade pattern hides implementation detail and exposes only what testers need when writing cases.
• The singleton pattern makes sure a single driver talks to the system under test.
• The page object model gives each page its own class, so a change to the page means a change in one place.

The four object-oriented principles and the five SOLID principles are there to justify these choices. You will not be asked to write code in the exam, but you will be asked which principle is being broken when a described design misbehaves.

What do the chapters on environments, pipelines and reporting add?

These chapters (2, 4, 5, 6 and 7) hold close to 700 of the 1,170 minutes, and they are where the 2024 rewrite is most visibly new. They read like a handbook for the engineer who has just been told to put the tests into the build.

Environments and testability

Chapter 2 treats testability as a non-functional requirement that is designed in alongside features, typically by an architect with the automation engineer's input. It splits the idea into observability (interfaces that show you what the system did), controllability (interfaces that let you act on it) and architecture transparency. Practical enablers include accessibility identifiers, environment variables and deployment variables. The chapter then walks through where automation runs: the local development, build, integration, pre-production and production environments. A useful detail is that monitoring should be present from the integration environment onward, because that is where defects first need tracing, and that white-box checks stop at that point, leaving black-box testing only.

Pilots and deployment risks

Chapter 4 centres on the pilot. A pilot is short, but its outcome steers the project, so it should settle the programming language, the tools, the test levels and the test cases to start with, and it should already try to plug into the CI/CD pipeline. Risks it expects you to analyse include firewall openings, CPU and memory use, packaging of testware, logging, test structuring and automatic updates to agents and devices. The six logging levels (fatal, error, warn, info, debug, trace) are listed with a purpose for each.

Where tests sit in a pipeline

Test type	Usual pipeline position
Configuration tests of the automation project	During the build, checking that referenced files exist
Component tests	Build step, acting as the quality gate of continuous integration
Component integration tests	Alongside component tests in the same stage
System tests	Continuous deployment, as the last quality gate
System integration tests	Continuous delivery, as a gate between components

The syllabus gives two ways to run slower tests after deployment. Run them inside the deployment phase, so a failure can roll the deployment back, at the price of a redeploy whenever you rerun. Or run them as a separate pipeline triggered by a successful deployment, which suits changing suites but means the tests no longer act as a gate and any rollback is usually manual. Expect a scenario that makes you pick between the two.

Reporting, metrics and verifying the solution

Chapter 6 lists where data comes from (system logs, framework logs, build and deployment logs, production monitoring, screenshots and recordings) and what a log should contain. It insists on a third result besides pass and fail: a test automation solution failure, meaning the defect is not in the system under test. Chapter 7 then turns the lens on the automation itself, covering automated installation of the tool set, repeatable setup and teardown, checking that a script behaves correctly, identifying where automation produces unexpected results, and using static analysis on automation code.

How does continuous improvement work on a real suite?

Chapter 8 is the one that rewards experience, and it is the one most candidates underestimate because it sits last. Its four objectives ask you to find improvement opportunities in data, to analyse a deployed solution, to restructure testware after changes in the system, and to summarise where automation tools can be used.

Waiting for the system: three mechanisms

Mechanism	What it does	Judgement
Hard-coded wait	Sleeps for a fixed number of milliseconds	A root cause of many automation defects, because response times vary
Polling	Checks repeatedly until a condition is true	Waits only as long as needed; always needs a timeout
Event subscription	Reacts to an event the system publishes	Most reliable, but the tool and the system must both support it

Schema validation, with a worked example

The syllabus's example is an API response with six mandatory elements that must all be strings. Written by hand, that is six type assertions and six not-null assertions. With schema validation the response is checked against the specification in one step, the test code is much shorter, and when the schema breaks, the tool reports which element failed, which points straight at the root cause. The point to remember is that fewer assertions can mean better detection.

Test histograms and self-healing

A test histogram shows how results for each test case trend over many runs, which exposes fragile tests you should refactor or rethink. Self-healing is the AI example: tools notice that a locator changed, use image recognition and machine learning to find the new one, repair the test and list the change in the report, which speeds up the follow-up version control work. Treat it as one tool in the kit, not the headline of the exam.

The rest of the chapter lists areas of a solution to improve: scripting, execution (parallel runs, splitting a suite across a night), verification methods shared across tests, the architecture itself, the framework, setup and teardown, documentation and upgrades. A recurring principle is that retrofitting testability late is expensive, so think about it at the start.

What study route suits an engineer who already writes automation code?

Start with the entry rule rather than the content: confirm that your Foundation Level certificate is valid for this paper, because ISTQB requires one before the exam. Then spend your first sitting on the table of learning objectives in Appendix A of the syllabus, marking each objective green, amber or red by how confidently you could explain it to a colleague.

1. Read the syllabus end to end once, quickly. It is 65 pages with a lot of white space, and the PDF is free from ISTQB.
2. Spend the most time on the K4 chapters. Chapters 2, 4, 6 and 8 are analysis chapters. Write a one-line verdict for every pilot risk, log level and improvement area you meet.
3. Draw the framework layers from memory. If you can place a given class in the right layer and name the pattern that applies, Chapter 3 is secure.
4. Build a pipeline map. Sketch which test levels run at which stage and what happens on failure in each of the two deployment approaches.
5. Learn the glossary terms in the keyword lists. Each chapter opens with keywords, and the syllabus says all of them must be remembered even if no objective mentions them. The ISTQB glossary defines them.
6. Finish with a timed paper. ISTQB publishes a free sample set; at the time of writing the file on its site is version 2.3 of the CTAL-TAE sample exam questions. Sit it in 90 minutes without notes and review every miss against the objective it tests.

Four to six weeks of part-time study is a sensible planning figure for someone with day-to-day automation experience, and longer for someone who has only used record-and-playback tools, since the structured-scripting and design-pattern material will be new. That is our planning estimate, not an ISTQB figure.

A second full-length rehearsal tells you more than rereading, so a CTAL-TAE practice exam from ProcessExam, taken under the 90-minute limit, shows whether your weak spots are knowledge or time.

Where does the certificate lead?

The syllabus's own career section points to three directions. The Test Automation Strategy specialist certificate (CT-TAS) takes up the decision-making material that left this syllabus. The Core Advanced certificates (Test Analyst, Technical Test Analyst and Test Manager) lead on to the Expert Level. And the Specialist stream covers areas such as performance testing, security testing, AI testing and mobile application testing. For an engineer, the practical meaning is a documented, vendor-neutral statement that you understand how automation is designed, deployed and kept healthy, not just how to run a tool. The up-to-date list of exam providers, fees and rules is on ISTQB's CTAL-TAE v2.0 page, and the full text is in the v2.0 syllabus PDF.

Frequently Asked Questions

What is CTAL-TAE v2.0?

It is the 2024 edition of ISTQB's Certified Tester Advanced Level Test Automation Engineering syllabus, released on 3 May 2024. ISTQB describes it as a major rewrite of the 2016 edition, with a stronger engineering focus and the strategic content moved to the separate CT-TAS syllabus.

Where can I download the ISTQB test automation engineer syllabus PDF?

ISTQB publishes the Test Automation Engineering v2.0 syllabus as a free PDF on its website, linked from the CTAL-TAE v2.0 certification page along with sample exam questions and answers. Download it from ISTQB directly so you are sure to have the current version and not an old copy.

What is the passing score for CTAL-TAE?

You need 43 points out of a total of 66 on the paper. The exam has 40 multiple-choice questions to answer in 90 minutes, and because 66 points are spread over 40 questions, some questions are worth more than one point. ISTQB lists these figures on its exam page.

Do I need the Foundation Level certificate before CTAL-TAE?

Yes. ISTQB states that candidates must hold the Certified Tester Foundation Level certificate, version 4.0 or an earlier version, and have sufficient practical experience. The syllabus also recommends roughly six months of experience as a tester or developer, plus an accredited course.

How much does the CTAL-TAE exam cost?

The listed price is USD $249. Exams are booked through an exam provider recognised by ISTQB or a national member board, so confirm the final amount, and what the booking includes, with your chosen provider before you book your date. Budget separately for any course you choose to take.

Select ratingPoorOkayGoodGreatAwesome

Rating: 4.8 / 5 (112 votes)