ISTQB CT-TAS Syllabus v1.0: Topics, Exam Format and Study Plan

Updated on 3 October 2026. What’s new: exam fee corrected to USD $199, and Foundation Level is a required entry condition under syllabus v1.0

CT-TAS is the ISTQB exam for the person who decides whether, what and how much to automate, so it asks for judgement rather than code. You get 40 questions in 60 minutes, the paper is worth 49 points and 32 of them pass. Everything is drawn from one syllabus, version 1.0, which was still the current one on ISTQB's own certification page when we checked in October 2026.

Picture the situation the exam is built around. A team has 1,200 manual regression tests, a release every two weeks and a manager who asks whether automation will pay for itself. A tester who can write Selenium scripts does not automatically know the answer. The answer depends on project length, tool licences, test distribution, environments, who maintains the suite and what the reports will be used for. The Certified Tester Test Automation Strategy syllabus covers exactly those questions, and this article walks through them in the order the syllabus does.

Is CT-TAS a coding exam, and what must you hold before booking it?

No. ISTQB positions the Test Automation Strategy Specialist qualification as the strategic companion to the Advanced Level Test Automation Engineering exam (CTAL-TAE). The engineering exam deals with architecture and implementation. CT-TAS deals with the decisions around it: costs, risks, roles, rollout, return on investment, metrics and organisation-wide consistency. The syllabus itself says it addresses automation needs beyond technical tool implementation and integration challenges.

That shapes who benefits. The syllabus names testers, test analysts, test automation engineers, test consultants, test architects, test managers and developers as the core audience, and also people who only need a working understanding of automation, such as project managers, quality managers, business analysts and IT directors. A manager who has never written a script can sit this paper. An engineer who lives in code but has never costed a tool licence or defended a budget will find it less familiar than expected.

Entry condition

The certificate you need first is Foundation Level. ISTQB's CT-TAS page states that candidates must hold the Certified Tester Foundation Level, version 4.0 or an earlier version, and have sufficient practical experience. The syllabus is more relaxed in tone and calls the entry criterion an interest in testing and test automation, but it still carries a note that the Foundation Level certificate must be obtained before taking the exam. Treat Foundation Level as required. What counts as sufficient practical experience is set by the national member board or the exam provider you book through, so ask them before you pay.

The exam in one table

Detail	CT-TAS
Certification	ISTQB Certified Tester - Test Automation Strategy (CT-TAS)
Syllabus version	Version 1.0
Exam fee	USD $199
Duration	60 minutes
Questions	40
Passing score	32 / 49
Category	Specialist

A few details sit around that table. Some questions are worth more than one point, which is why the total is 49 rather than 40. ISTQB adds 25 per cent more time for candidates sitting in a language that is not their native one. The fee depends on the exam provider and region, and ISTQB's page does not print a price, so confirm it when you book. ISTQB lists the exam through its Find an Exam Provider service, and the certification is current, with the syllabus, a sample paper and an answer key all published on the ISTQB CT-TAS certification page.

What K2 and K3 mean for you

Every objective is tested at one of two levels. K2 means understand: you explain, compare, classify or identify. K3 means apply: you take a described situation and work something out. The syllabus has 33 learning objectives, 27 at K2 and 6 at K3. The K3 objectives are the ones to rehearse with a pencil, because they ask you to demonstrate shift-left optimisation, prepare for DevOps practices, show a return on investment, identify organisational considerations, analyse project characteristics and evaluate existing automation assets. Everything else rewards clear definitions and the ability to tell two plausible options apart.

Where do the 765 syllabus minutes go, and what does that say about the paper?

The syllabus does not publish a points-per-chapter split in its own text. What it does publish is teaching time per chapter, totalling 765 minutes, or 12.75 hours, for accredited courses. Teaching time is a fair proxy for how much material each chapter holds, so use it to decide where your reading hours go.

Chapter	Teaching time	Highest level	Objectives
1. Introduction and Objectives for Test Automation Strategy	45 minutes	K2	3
2. Test Automation Resources	60 minutes	K2	4
3. Preparing for Test Automation	225 minutes	K3	9
4. Organizational Deployment and Release Strategies	135 minutes	K2	9
5. Test Automation Impact Analysis	150 minutes	K3	5
6. Implementation and Improvement Strategies	150 minutes	K3	3

Two readings of that table are useful. First, chapter 3 is nearly a third of the whole syllabus, so a candidate who skims it is gambling with the largest block of material. Second, chapters 5 and 6 have few objectives but run at K3 and take 150 minutes each, which means fewer topics studied more deeply, including arithmetic and evaluation. Chapters 1 and 2 are short, but they feed every later chapter, because the cost factors and roles they introduce come back in the rollout and ROI questions.

Questions can also cross sections. The syllabus warns that an answer may need material from more than one section, so read each chapter once for content and a second time for links. If you want to see the structure laid out chapter by chapter on our side, the CT-TAS syllabus and exam details page mirrors it.

How does the syllabus tell you what to automate, and at which test level?

Chapters 1 to 3 answer the first strategic question: should this project automate, and if so, where. They are the heaviest part of the exam, so they get the longest section here.

Goals, success factors and the investment test

A strategy starts with a defined purpose, the risks, the scope, the stakeholders, the tools, the automation architecture and the environments. The syllabus lists objectives such as better test efficiency, wider coverage, shorter execution time, higher test frequency and tests that manual testers simply cannot perform. It also lists technical success factors: a testable system under test, a defined and maintained strategy, a clear architecture, a usable framework, reporting, troubleshooting, traceability and a plan for retiring tests. Not every factor is needed, and the syllabus admits that in practice few projects have them all, so the skill being tested is weighing which are missing.

Before committing, you apply four investment criteria: the cost of introduction (engineers, hardware, training), the current phase of the lifecycle, the expected duration of the project, and the maintenance cost. Starting early gives automation more time to repay itself, and a short project may never reach that point. Selecting the approach and the tools is described as a strategic job for a test architect or test manager.

Ownership, licences and people

Chapter 2 compares three ways to own a solution. Building in-house on open-source or commercial tools keeps cost, risk and governance inside the organisation but needs skilled engineers. A vendor solution shares ownership, which is quick when a piloted tool already fits and slow when you need a defect fixed or a feature added. Outsourcing removes the hiring burden, provided the contract defines measurable expectations.

Licensing comes in four models you should be able to tell apart in a scenario:

• Open source: no licence fee, community support, and the freedom to modify the tool.
• Per user or per machine: efficient when you know how many engineers will work long term.
• Floating: shared between people at different times, counted by concurrent use rather than headcount.
• Runtime: charged only for execution time, typical of cloud services that host browsers, operating systems or device farms.

The syllabus adds a warning that on-demand cloud resources can backfire, since machines left running can cost more than owning the hardware. On people, it asks for engineers with strong programming and architecture knowledge, at least one subject-matter expert who understands the business domain, and the soft skills to train and motivate the team. It also states that 100 per cent automation coverage is not achievable, so engineers must help prioritise the conditions that matter most.

Test distributions: pyramid, ice cream cone, hourglass and umbrella

This is the most reliably tested idea in chapter 3. The syllabus starts from the test automation pyramid, with unit or component tests at the base, service-level tests in the middle and UI tests at the top, and breaks the service layer into component integration, contract and API testing. It then describes four shapes you may be asked to recognise:

Shape	What it looks like	Typical consequence
Pyramid	Many fast low-level tests, fewer at the top	The usual target state when time and resources allow
Ice cream cone	Defects mostly found through the UI, little component testing	Defects are found late and automation costs more
Hourglass	Heavy at the top and bottom, service level mostly missing	Integration defects slip through; many UI tests can move down if APIs hold the logic
Umbrella	Almost everything is costly UI testing	Slow defect turnaround and expensive maintenance

The practical method is to draw the current state and the target state, then plan the route between them. The syllabus is realistic: a pyramid may not be reachable quickly, so a sensible target might be moving from umbrella to hourglass first. For an unbalanced distribution it recommends a bottom-up approach, raising component test coverage before anything else. Mainframes are treated separately, because terminal emulation, batch jobs and databases replace APIs and components. Contract testing, where a consumer and a provider agree on the shape of their exchange, earns its own mention as a way to find root causes earlier.

Shift left and shift right belong here too. Shift left moves testing earlier, using test doubles such as mocks and stubs so tests do not depend on real services and data. Shift right moves checks after release, combining automation with observability to support canary releases and dark launches and to decide whether a release candidate stays or rolls back.

Lifecycle models and test suitability

The syllabus compares how automation fits waterfall, the V-model, Agile and DevOps. Waterfall brings feedback too late for a good return. The V-model plans tests earlier but still implements automation late. Agile aims for in-sprint automation, with the automation work counted in each story's exit criteria, and a less mature team should first achieve in-sprint testing with automation one sprint behind. DevOps extends this to the whole delivery chain, putting low-level automated tests in the same pipeline that builds the software and leaving manual effort for exploratory testing and end-user feedback.

Finally, section 3.3 asks which tests are worth automating. Good candidates are technically feasible, repeatable, run frequently, easy to maintain, part of a smoke, regression or confirmation suite, and cover common business workflows with a sensible return. Tests only automation can do include precise timing, synchronised execution, log parsing, permutations across operating systems, browsers and devices, large data volumes and stress or reliability testing. Hard cases include subjective look and feel, flows that need human judgement such as a loan application with unusual conditions, and technical blockers such as operating-system restrictions.

What does a sound rollout plan have to cover before the first script runs?

Chapter 4 moves from "should we" to "how do we deploy this safely", and it is a K2 chapter of 135 minutes with nine objectives. Questions here tend to ask you to pick the option that fits a described risk.

Planning the solution

The syllabus gives automation three jobs that planners can point to. It shortens time to market, helped by quality gates (enforced measures the software must meet before it moves on), parallel execution and shift left. It verifies reported defects through automated confirmation tests, which become regression candidates because defects like to return in later releases. And it supports operational acceptance with scenarios such as static code analysis, end-to-end runs, failover, backup and restore, load testing, security checks and monitoring against a service level agreement, where scripts written for testing are repurposed to alert on production failures.

Deployment strategy in five parts

A deployment strategy for the automation solution itself covers the test environment, the tools, access to the system under test, script storage and data provisioning. The details are practical, which is exactly why exam questions about them are answerable by reasoning:

• Environments: scripts should run in test and pre-production with minimal change, often just a different URL.
• Tools: a commercial tool may need access to a licence server that exists in test but not in pre-production.
• Access: credentials and endpoints are parameters, not hard-coded values.
• Storage: scripts, frameworks and configuration live in a repository under configuration management so each version matches a system version.
• Data: avoid static data where possible, or have setup scripts create what the tests need, weighing the convenience of preloaded data against dependence on whoever loads it.

Risks and mitigation

The syllabus sorts risks into technical issues (excess abstraction in keyword-driven tests, oversized data tables, dependence on libraries missing from other environments), project risks (staffing, unplanned maintenance after system updates, late updates to the solution, outdated tests clogging suites) and failure points (moving environments, deploying to production, and forgetting that automation is software that needs testing). The mitigation theme is repeated: the automation solution has a lifecycle of its own, so it needs configuration management, documented features, a clear deployment procedure and separate handling of first-time deployment and maintenance deployment.

Infrastructure, data and interfaces

Section 4.3 lists what must be in place to run anything: host machines, a network, a platform (cloud or containers), software dependencies and access to the system under test, including a browser of the right type and version for web applications. It then asks how the automation will talk to the system: through an API without a UI, through a database interface that checks stored values, or through contract tests that prove two services can communicate. The recurring advice is to keep components reusable and not to overcomplicate the environment, because hours lost fixing the framework are hours not spent testing.

How do ROI, metrics and reports turn into a decision you can defend?

Chapter 5 is where arithmetic and reasoning meet, and where K3 questions concentrate. It has five objectives across four topics.

The ROI model

The syllabus defines return on investment as savings divided by investment, and for simplicity measures both in time rather than money. Savings come from four inputs: the time to run a test manually, the time to run it automatically, the number of tests and the number of runs. Investment comes from setting up, writing scripts, maintaining them, running them, handling failed scripts and the number of runs. Two conclusions are worth memorising. If the planned project duration is shorter than the turning point at which automation repays itself, automation is not worth introducing. And because investment depends heavily on execution time, putting tests at the right level of the pyramid improves the return.

Here is an illustration made up for practice; the figures are ours, not the syllabus's. Suppose a full manual regression pass takes 40 hours and the automated version takes 2, run once per sprint. Setting up and writing the scripts costs 120 hours, and upkeep is 4 hours a sprint. Savings are 38 hours a sprint, so at the end of sprint 3 savings are 114 hours against an investment of 132, while at the end of sprint 4 they are 152 against 136. The turning point falls in sprint 4. A project with only three sprints left should stay manual; one with thirty should automate.

Metrics, and what each one can mislead you about

The syllabus classifies metrics about the automation solution itself. Each has a use and a trap:

Metric	What it tells you	What to remember
Pass-fail ratio	How many automated tests pass compared with those that fail	A common and cheap measure
Ratio of failures to defects	How many tests fail because of one defect	Many failures from a single cause point to a design problem
Execution time	How long the suite takes, including build time	Matters more as the suite grows
Number of automated tests	Progress of the project	Says nothing about coverage on its own
Functional coverage	Share of requirements covered by automated tests	Needs traceability to requirements
Code coverage	Code exercised by component tests	No percentage is enough on its own; more tends to raise confidence

The cost of measuring should be as low as possible, usually by automating collection and reporting. Reports then feed decisions, so section 5.4 asks you to analyse report data to decide, for example, whether a failing suite shows a product problem, a test problem or an environment problem.

Organisation and project characteristics

Before starting, you look at the organisation: its development policies and practices, existing automation projects that might be reused, in-house experts, available test environments and the licences already owned. Reusing a cloud provider and tool licences the company already pays for is the kind of obvious saving the syllabus rewards. Then you analyse the project: its domain and regulations, the platforms, the programming language and technology stack (matching the developers' language eases collaboration), the maturity of the project and, last, stakeholder buy-in. A greenfield project suggests an incremental roadmap built around a minimum viable product, while a project near its end does not justify a large, robust solution.

What changes when a team moves from manual regression to continuous testing?

Chapter 6 is short in objectives but carries a K3 evaluation task, so it rewards understanding of why a transition goes wrong.

Leaving manual regression behind

Regression testing is the easiest place to begin, because regression suites keep growing until manual teams cannot keep up. The syllabus lists the factors to plan for:

• Transition costs: manual and automated testing run side by side for a while, so costs rise before they fall.
• Functional overlap: repeated steps such as a login sequence should become one reusable component rather than being copied into every test.
• Data sharing: shared data should live in a single source, not be duplicated as it was in manual test cases.
• Test interdependency: an order number created in one test and needed by the next must be captured, or the later tests fail.
• Preconditions: accounts, roles and data must exist before a test can run reliably, and can themselves be set up by script.
• Functional coverage: automating every manual test is not the same as covering everything that could be automated, and the time saved should go into finding new gaps.
• Executable tests: a manual test that does not run correctly should be fixed before it is converted.

Reaching continuous testing

Continuous testing means running suites as soon as a change reaches the test environment. Adapting the automation solution for it means updating the suites, the stubs and drivers, and the infrastructure, then weighing the risks and benefits of any defects in the new version and publishing release notes of known defects. Extending the delivery pipeline so automated tests verify the system straight after deployment is the natural step, provided the tool can reach the system, the code repository and the data scripts.

Evaluating what you already have

The K3 objective in 6.2.1 asks you to evaluate automation assets and practices to find improvements. The syllabus's warning sign is concrete: if maintaining the automation takes longer than the manual testing it replaced, something is wrong. Track hours spent building, hours spent fixing and time saved against manual execution. Use code coverage tools and a requirements traceability matrix to find gaps, agree one infrastructure and configuration approach across projects, publish common development guidelines, and automate preconditions. The goal is the point of the whole qualification: projects share assets and methods so that automation is consistent across the organisation.

To tie the chapters together before you move on to preparation, the five-step path below is a handy mental model of a strategy from idea to rollout. It is our summary, not an ISTQB diagram, but each step maps to a syllabus chapter.

How do you prepare for CT-TAS in five weeks?

Because the exam draws on one document, the best preparation starts with that document. Download the CT-TAS syllabus v1.0 PDF and the sample paper and answer key that ISTQB publishes alongside it (the ISTQB sample questions, version 1.2). Self-study is allowed, though ISTQB recommends accredited training when you can get it. The schedule below assumes about six to eight hours a week and a candidate who already works in testing.

Week	Study focus	Finish the week by
1	Chapters 1 and 2: objectives, success factors, ownership, licences, roles	Writing the four licence models and three ownership models from memory
2	Chapter 3, first half: distributions, shift left and shift right, lifecycle models	Drawing each distribution shape and one fix for it
3	Chapter 3, second half, then chapter 4: suitability, deployment, risks, infrastructure	Listing, from memory, five deployment concerns with a mitigation each
4	Chapter 5: ROI, metrics, organisation and project analysis, report decisions	Solving three ROI turning-point examples without notes
5	Chapter 6, then timed papers	Two timed runs of 40 questions in 60 minutes

Habits that suit a strategy exam

Study with your own project in mind. For each chapter, write one sentence about how it applies to a system you know, because scenario questions are easier when you have already asked what you would do there. Keep a glossary page for the keywords listed under each chapter heading, since the syllabus says every keyword must be remembered even if no objective mentions it. When two answers both look reasonable, ask which one the syllabus would choose, and look for its qualifiers: short project, mainframe, limited time, regulated domain.

When you reach week 5, a timed run shows more than reading does. A set of exam-style questions, such as our CT-TAS practice exam, lets you rehearse the 60-minute pace and see which chapters leak points; read the explanation for every miss and go back to the syllabus paragraph behind it. With 40 questions in 60 minutes you average 90 seconds a question: plenty for a definition, little for a K3 calculation, so finish the easy items fast and keep minutes in hand for the working-out ones.

On the day

Start each scenario by finding the verb in its closing line, which tells you whether you are choosing a risk, a mitigation, a metric or a decision. Mark long calculations and return to them. Remember that a 32 out of 49 pass mark means roughly two thirds of the points, and that you can miss a fair number of single-point questions as long as the multi-point ones go your way. Candidates who sit in a non-native language get the extra 25 per cent, so ask for it when you book if it applies to you.

Is CT-TAS worth adding to your certificate list, and where does it lead?

It is worth it if your work involves deciding about automation rather than only doing it. The business outcomes ISTQB lists for the qualification read like a manager's checklist: understand the factors that influence success, identify costs and risks, plan integration across test levels, understand deployment strategies, choose metrics that drive decisions, show value at project and organisation level, define the move from manual testing, and set a strategy that lets projects share assets and methods. There are fifteen outcomes in all, and they describe a conversation with a budget holder more than a coding task.

Roles that gain from it include test managers, test architects, lead automation engineers, quality managers and consultants who advise several teams. For an engineer, it gives vocabulary for arguments that usually end with "because I said so": a payback calculation, a distribution diagram or a metric that supports your case. ISTQB does not publish salary data for this qualification, so none is quoted here; if pay matters, check a salary survey for your region and role.

What to take next

The syllabus itself points to the next steps. If you want the hands-on, architectural side, the Advanced Level Test Automation Engineering certification is the natural companion, and the syllabus refers to its sections for architecture and framework detail. Others can continue to the Core Advanced Levels (Test Analyst, Technical Test Analyst, Test Manager) and then the Expert Level, or sideways into other Specialist qualifications such as performance, security, AI testing and mobile application testing. Holders of this certification may choose to proceed along any of those streams.

The strategy certificate is the one that pays off in meetings, not in a script editor. If you can explain why a team should keep a regression suite manual for three more sprints, or why an umbrella-shaped suite needs component tests before more UI scripts, you are using what the exam teaches. Read the syllabus once, work the examples, rehearse under the clock and book the paper when two timed runs land comfortably above the pass line.

Frequently Asked Questions

What does CT-TAS stand for and what does it cover?

CT-TAS is the ISTQB Certified Tester Test Automation Strategy Specialist qualification. Its six chapters cover automation goals, resources and costs, test distribution and lifecycle fit, deployment and release strategy, impact analysis with ROI and metrics, and the move from manual to continuous testing.

What is the passing score for the CT-TAS exam?

You need 32 points out of 49 to pass. The paper has 40 questions and lasts 60 minutes, and some questions carry more than one point, which is why the total exceeds the question count. Candidates sitting in a non-native language receive 25 per cent extra time.

How much does the CT-TAS exam cost?

Our records list the CT-TAS exam fee as USD $199. ISTQB does not print a price on its certification page, and exam providers and member boards set the final fee for their region, so confirm the amount and any local taxes with your provider when you book.

Do you need Foundation Level before taking CT-TAS?

Yes. ISTQB states that candidates must hold the Certified Tester Foundation Level, version 4.0 or an earlier version, plus sufficient practical experience. The member board or exam provider decides what counts as sufficient experience, so ask them before you register for the paper.

Does the CT-TAS exam involve programming?

No. CT-TAS tests strategic decisions about automation, such as costs, licensing, test distribution, rollout, return on investment and metrics. The programming and architecture detail sits in the separate Advanced Level Test Automation Engineering exam, so a manager without coding skills can prepare for this paper.

Select ratingPoorOkayGoodGreatAwesome

Rating: 4.8 / 5 (111 votes)