ISTQB Agile Test Leadership at Scale: Who Should Take CT-ATLaS

CT-ATLaS is for the person who answers for testing across several delivery teams at once, such as a head of testing in a scaled agile programme or a quality coach serving a dozen squads. It is not for a tester inside one Scrum team who wants sharper techniques, or an engineer who builds automation frameworks; ISTQB has other exams for both. The paper is 40 questions in 120 minutes, and you need 47 of 71 points.

Everything below comes from ISTQB's own v2.0 syllabus and its certification page, both read in October 2026. It tells you who should sit the paper, what you must hold before booking, what each of the five chapters asks you to do, and in what order an experienced lead can study. The vendor's wording is quoted where it matters; everything else is explained in plain terms.

Which roles gain from CT-ATLaS, and which should choose another ISTQB exam?

ISTQB describes the certificate as aimed at people who work in an organisation that is pursuing agility at scale or business agility, and who already understand agile and agile testing. Its list of suitable roles is long: Test Manager, Head of Testing, Test Analyst, Quality Engineer, Quality Assurance, Quality Coach, a member of an agile team, a member of the leader group of several agile teams, Project Manager, Release Train Engineer and Scrum Master.

That list is wide, but the common thread is narrow. Every role on it makes decisions or gives advice that reach beyond one backlog. The syllabus calls the person who holds the certificate an agile test leader, and it spends its five chapters on organisational questions: how quality is shared, how work flows between teams, how a test strategy is written for a whole company, and how testing is coordinated when some teams are not agile at all.

A quick way to place yourself

Your working week	Better fit
You chair a testing community of practice, advise several squads and report on quality to programme leaders	CT-ATLaS
You plan and run testing for one project, with a budget, a schedule and a risk register	Advanced Level Test Management (CTAL-TM)
You sit in one agile team and refine acceptance tests, exploratory sessions and test charters	Advanced Level Agile Tester (CTAL-AT)
You write and maintain automation code in a pipeline	Advanced Level Test Automation Engineering (CTAL-TAE)

ISTQB itself draws these lines. It says CT-ATLaS supplements the Advanced Level Agile Technical Tester, which concentrates on technical practices, and the Advanced Level Test Management certification, which concentrates on projects. Test Management also covers traditional and hybrid approaches, whereas this exam deals only with agile ones. If your organisation still runs waterfall projects with a separate test phase, the Test Management exam describes your day better.

The syllabus also names the other certificates a holder may want next: the Core Advanced exams in Test Management and Test Analyst, and the Specialist exams, in particular Test Automation Engineer, AI Testing and Model-Based Tester. Treat CT-ATLaS as the leadership branch of the ISTQB scheme, not as a step you must climb through.

What must you hold before booking, and what does the paper ask of you?

The entry criteria are stated in section 0.8 of the syllabus. You need either the ISTQB Foundation Level certificate at version 4.0, or an older Foundation Level certificate together with the ISTQB Agile Tester Foundation Level certificate. The syllabus adds that once the Agile Tester Foundation certificate is withdrawn, Foundation Level 4.0 becomes the only route in. ISTQB's certification page repeats the rule and adds that candidates need "sufficient practical experience", to be checked with the relevant national exam board.

Three further points are only recommended: at least three years of experience in an agile team or an agile organisation, familiarity with at least one agile scaling framework, and an accredited course from an ISTQB-recognised member board. None of them blocks a booking, but they change how hard the paper feels. A candidate who has never sat in a programme-level planning event will find the questions on coordination abstract.

Item	Detail
Exam code and version	CT-ATLaS v2.0
Vendor	ISTQB
Exam fee	USD $199
Duration	120 minutes
Questions	40
Passing score	47 / 71
Entry criterion	Foundation Level v4.0, or an older Foundation Level plus Agile Tester Foundation

Forty questions share 71 points, so the questions are weighted: harder ones are worth more. The pass mark of 47 is about 66 percent of the points. ISTQB's page adds a 25 percent time allowance for sitting the paper in your second language, which stretches 120 minutes to 150. Ask the exam provider how that is arranged before you pick a slot. ISTQB sells the paper through exam providers listed on its site, so confirm the final price and delivery options with the one you choose.

The syllabus also separates what is examined from what is not. Learning objectives at K2 (understand), K3 (apply) and K4 (analyse) are examinable, and so are the keywords listed under each chapter heading, which you must be able to recall. The hands-on objectives are not examined by the multiple-choice paper. Accredited courses cover them in exercises; a self-studying candidate should still try them, because they are the quickest way to understand the K3 and K4 questions.

Which syllabus version applies today?

The revision history in the syllabus shows two releases. Version 1.0 appeared on 13 May 2022 and carried three chapters; version 2.0, dated 29 September 2023, added chapters 4 and 5 and made minor updates to chapters 1 to 3. The release notes say the ISTQB General Assembly approved it on 29 September 2023 and that it launched on 4 October 2023.

The notes also set deadlines for member boards that had offered the v1.0 MVP in English: exam questions had to be valid against v2.0 by 4 April 2024, and v1.0 had to be retired by 4 October 2024. Both dates have passed, so v2.0 is the version to study, and it is the one listed on ISTQB's page today. If you find a blog or a book that mentions only three chapters, it describes the retired version and omits the strategy and test-process material that now makes up more than half of the course time (360 of 690 minutes).

ISTQB updates its certification pages without notice, so check the exam provider's listing for the current fee and language options on the day you book. The syllabus itself is the stable reference, and nothing in the exam rests on tools or product names: the standards and books cited in it are references, and their content is examinable only as far as the syllabus summarises it.

What is quality assistance, and why does the syllabus start there?

Chapter 1 is the shortest, at 60 minutes of course time, and it sets the vocabulary for the other four. Quality assistance is ISTQB's name for an approach to quality management in which testing professionals enable other people to carry quality responsibilities rather than holding them all themselves. The syllabus presents it as the approach test management should adopt to support a move towards business agility, and it states that test management as a discipline is still needed inside it.

The syllabus lists the differences from a traditional mindset. Quality assistance optimises for flow and value delivery, and it concentrates on prevention, automation and observability. It encourages built-in quality, both shifted left and shifted right, supports self-empowered teams, and embeds testing across the organisation instead of keeping it in silos. Agile test leaders serve rather than control, and they connect people through community of practice events.

The four skills

The single learning objective on skills asks you to give examples of four of them. Expect scenario questions where you choose which skill fits.

• Change leadership. Aligning quality work with the organisation's change programmes, taking account of how people cope with change, and nurturing a culture of continuous improvement.
• Quality coaching. A collaborative dialogue that prompts reflection in a team or in one person. The syllabus also covers the conditions under which coaching works.
• Facilitation. Helping people use their own knowledge to reach an outcome, so that responsibility for quality is shared.
• Training. Choosing methods that build skills, and involving the departments that support career growth so that training scales.

Mentoring and consulting are acknowledged as useful but are stated to be out of scope. That sentence is worth remembering: a distractor offering "mentoring" as one of the four skills is exactly the kind of trap a K2 question can set.

A short example makes the contrast concrete. Three squads keep missing their release dates because the shared regression suite fails at random. A traditional test manager would take ownership of the suite and report on it. An agile test leader would run a facilitated session with the three squads, coach their testers on isolating the unstable tests, and agree a rule in a community of practice about who fixes a failing shared test. The problem is solved by the teams, and the leader's job becomes the conditions around it.

How do you read a value stream, and which numbers must you know?

Chapter 2 (120 minutes) borrows from lean management. A value stream is a group of working steps, including the people and systems that carry them out and the information and materials they use. The syllabus names two common kinds: an operational value stream, from order to delivery, and a development value stream, from concept to market launch. In a value-driven organisation, testing roles are expected to improve the whole stream, not only the testing step inside it.

Value stream mapping is the technique for drawing and analysing those steps. A current state map shows how the work flows today; a future state map shows the target. The syllabus asks you to apply mapping (K3) and to analyse a stream for waste and quality problems using basic metrics (K4), so you must be able to calculate with the numbers, not only define them.

Metric	What it tells you
Lead time	Elapsed time from a request entering the stream until it is delivered
Processing time	Time spent actively working on the item
Wait time (delay time)	Time the item sits idle between steps
Flow efficiency	Processing time as a share of lead time (also called process cycle efficiency)
Percent complete and accurate	How much of the work arrives at the next step without needing rework
Phase containment efficiency	How many defects are caught in the phase that introduced them

Here is an invented example of the arithmetic. A change request takes 15 days from approval to production. Developers work on it for 3 days and testers for 2, and the other 10 days are queues: waiting for a test environment, waiting for a deployment slot, waiting for sign-off. Processing time is 5 days and lead time is 15, so flow efficiency is about 33 percent. Two thirds of the lead time is waiting. Improving the speed of test execution by 20 percent barely moves that figure; removing the environment queue does. That is the insight the syllabus wants an agile test leader to bring.

The eight wastes

Lean classifies non-value-adding activity into eight types, and the syllabus lists them: transport, inventory, motion, waiting, overproduction, over-processing, correction and non-utilised talent. In a software value stream these translate readily. Handing a build from team to team is transport. A pile of untested stories is inventory. Writing detailed test documents nobody reads is over-processing. A tester who could coach but only re-runs scripts is non-utilised talent. The metrics point to where to look; the wastes give names to what you find.

The syllabus adds a practical note on data: collecting metrics is hard, so observe the work as it happens and ask the people doing it what can be measured. Mapping is described as iterative and as a learning process that helps people see their own work flows and act differently on quality.

Where do PDCA, Five Whys and causal loop diagrams show up in the exam?

Chapter 3 (150 minutes) holds four learning objectives, two at K3 and two at K2, and they pair a method with its organisational setting. The first method is the Plan-Do-Check-Act cycle created by W. Edwards Deming. The syllabus's key principle is iteration: improvement efforts are treated as experiments. It suggests starting with a gap analysis, for instance a current state map set against a future state map, then proposing and testing changes. Variations such as Plan-Do-Study-Act and models such as IDEAL are mentioned as not covered.

The second learning objective asks how to embed PDCA across the organisation. Local experiments alone do not scale, so knowledge must be shared. The syllabus points to multi-team retrospectives and to organisational and product-level improvement boards. It also names the human condition that decides whether any of this works: a secure environment where people feel safe revealing errors. Part of an agile test leader's management responsibility is to promote that behaviour and to address the root causes when it is missing.

Root causes in a system

When several teams build one solution, a fix made by one team can cause trouble for another. The syllabus therefore teaches systems thinking and flexible root cause analysis, with a warning that concluding too quickly that there is one single root cause is a risk. It lists four typical bottlenecks in development value streams: environment creation, code deployment, system testing and software architecture. Five Whys is the basic lean technique. Causal loop diagrams (CLDs) help when the feedback structure of people or technical systems must be uncovered.

A CLD has four elements: variables, causal links between them, a plus or minus sign on each link, and loop markers. You are expected to follow six repeated steps: define variables, define the causal relationships, describe the effect one variable has on another, add other factors such as delays and goals, identify the reinforcing and balancing loops, and identify possible interventions.

A small illustration shows how the signs work. More release pressure leads to less time for testing (a minus link). Less testing leads to more escaped defects (a minus link back from testing to defects). More escaped defects lead to more urgent fixes, which in turn raise release pressure (plus links). That closed chain reinforces itself, so it is a reinforcing loop. An intervention might be to agree a fixed share of each iteration for quality work, which breaks the link between pressure and test time. The K3 objective expects you to apply the notation to a scenario of this sort, so practise drawing two or three loops by hand.

What goes into an organisational test strategy, and how does it differ from a team's plan?

Chapter 4 (165 minutes, rated K4) is the heaviest on judgement. It has two sections: how to establish an organisational test strategy, and how agile test leadership fits into the organisation.

DevOps practices inside the strategy

The syllabus uses the DevOps infinite loop of six stages: operate, monitor, explore, code, integrate and release. A strategy for a value-driven organisation has to include practices that speed flow through those stages, and the syllabus lists them: feature toggles, automated control of test and production environments, testing in production, canary releases, monitoring, hypothesis-driven development for a minimum viable product during exploration, self-service environment management, blue/green deployment and chaos engineering. It stresses that environments designed for resilience are what make testing in production possible. Where DevOps is immature, the strategy should set improvement goals instead of assuming the practices exist.

Creating and implementing the strategy

Test strategies exist at organisational, product and operational levels, and this certificate concerns the first. The syllabus suggests borrowing the idea of a definition of done: the organisational strategy may set the elements every team must include in theirs as a minimum, and it should be lightweight, user-friendly and a living document. It should be built by interested stakeholders in a community of practice, preferably one organised around a topic rather than a role, and it can be tailored up or tailored down. To keep it from becoming shelfware, leaders encourage teams to run experiments that test the strategy's practices. Leading the roll-out is a change-leadership task, and the syllabus names the ADKAR model for leading change at the level of the individual.

Checking that testing matches the business

The K3 objective asks you to implement assessment techniques that validate alignment with business and technical needs. The syllabus prefers self-assessments, facilitated or self-managed, because assessments imposed from above risk disempowering teams. Holistic maturity models measure three areas: outcomes in terms of business value, outputs in terms of delivery and performance, and maturity in terms of people and processes. A facilitated self-assessment has three steps: plan, conduct and conclude.

Where the leader works

The K4 objective asks you to analyse how agile test leadership fits an organisation that uses a scaling framework. The three levels differ in scale and in what the leader does.

Level	Typical contribution of the agile test leader
Organisational	Aligns the test strategy with the business strategy, builds business cases for large improvements, analyses trade-offs when budgets are allocated
Product	Leads the testing community of practice, helps teams find waste with value stream mapping, facilitates multi-team retrospectives, balances decentralised and centralised testing
Operational	Coaches teams of teams in test techniques, estimation, risk-based testing, pairing and design for testability, or provides services from a specialised group

The chapter closes with the move from traditional test management. New responsibilities include using value stream mapping and systems thinking and speaking up about dysfunction. Old ones that continue include coaching, training, fostering communities and acting as an escalation point for impediments. The anti-pattern is any command-and-control behaviour that undermines self-organised teams.

How are tests organised when many teams, some of them not agile, deliver one product?

Chapter 5 (195 minutes, K4) is the longest, and it has five learning objectives, two of them at K4. It starts from the problems that scale creates. Teams cannot test the whole solution alone, and responsibility for cross-team testing can become ambiguous so that nobody does it. Test effort has to be synchronised with non-agile and third-party teams. Testers should move earlier in product development, to hypothesis forming and exploring user needs. Stakeholders need transparency across self-organised teams, and test activities must be sliced to fit an iteration.

Coordination practices and metrics

The syllabus lists practices that coordinate testing across agile and non-agile teams: one backlog with cross-team refinement, big room planning such as PI planning, Scrum of Scrums, demos of integrated and tested increments, retrospectives and inspect-and-adapt events, impediment and risk boards, debt handling, and technical enablers.

For metrics it keeps to the same three areas as chapter 4. For delivery and performance it names four key metrics: deployment frequency, lead time for changes, change failure rate and time to restore a service. It points out that cost reductions that benefit the organisation do not necessarily add value for customers, and that an organisation not ready to define business value should start with delivery metrics. Leading indicators give early feedback; lagging indicators report actual results. All agile test leaders in the organisation should focus on the same metrics.

Structuring the hard activities

Converting test levels into test activities, the Agile Tester advice, is usually not enough at scale. The syllabus clusters the awkward activities by purpose: functional integration, technical integration and non-functional characteristics such as performance, reliability, security and accessibility. Teams should prefer testing inside the iteration, because deferring it to a separate level weakens the definition of done, and test automation helps them do so. Unsynchronised releases multiply the configurations to test, so teams need the same rhythm. A shared risk board makes cross-team risks visible. For non-agile units and for vendors, the leader helps set working agreements, and may even take part in a tender by describing the quality and testing parts of the request for proposal.

Who performs which testing

The last K4 objective asks which activities belong to stream-aligned teams and which to specialised teams. The syllabus uses four team types from SAFe's team topologies.

Team type	Test activities it typically takes on
Stream-aligned	Feature testing, hypothesis testing, work caused by corporate-level technology changes or organisation-wide risk
Platform	Shared test tools, test infrastructure and common components, offered as a service
Complicated-subsystem	Special testing or subsystems too complex for the other teams
Enabling	Temporary, consultative work, and research on new methods and tools for others

The syllabus adds considerations for the choice: a platform or enabling team can help with non-functional testing, independent testing does not require formal organisational borders, and non-agile teams can be treated as enabling teams that supply knowledge. Practise answering "which team should own this" with a reason, because that is how a K4 question is framed.

In what order should an experienced lead study, and how do you know you are ready?

The five chapters add up to 690 minutes, the 11.5 hours of instruction that accredited courses must deliver across at least two days. A working leader can read the syllabus in a weekend, but the K3 and K4 objectives need practice with scenarios, so allow a few evenings spread over weeks. The order below follows the dependencies between chapters instead of the page order alone.

1. Read chapter 1 and chapter 4 together. Quality assistance and the organisational strategy share a vocabulary: community of practice, definition of done, change leadership.
2. Do chapter 2 with a pencil. Draw a current state map of a process you know, label lead time and processing time, and compute flow efficiency. The calculation is the part candidates skip and then meet in the paper.
3. Do chapter 3 on the same drawing. Run a Plan-Do-Check-Act cycle on one bottleneck, then sketch a causal loop with at least one reinforcing and one balancing loop.
4. Read chapter 5 against your own organisation. For each type of team in the table, name a real example and the test activity it should own.
5. Close with the keyword lists. The keywords under each chapter heading are examinable at recall level, so test yourself on them.

Past the reading, rehearse the timing. Work through ISTQB's published sample exam questions first, then run a full paper under the clock with a CT-ATLaS practice exam so that 40 questions in 120 minutes, about three minutes each, feels ordinary before you book. Review each wrong answer by finding the syllabus sentence it contradicts; a wrong answer you cannot trace to a sentence usually means you were guessing between two plausible distractors.

Signs you are ready

• You can compute flow efficiency from a small table of times without looking up the formula.
• You can say, for each of the four skills, one action an agile test leader would take.
• You can sort five test activities into the four team types and justify each choice in one sentence.
• You can explain why a self-assessment is preferred over an assessment imposed by management.
• Your sample papers land comfortably above the pass mark of about 66 percent, with time left to review.

The chapter-by-chapter learning objectives are also set out on the syllabus page for this exam. For the vendor's own material, ISTQB's CT-ATLaS certification page and the v2.0 syllabus PDF are the primary sources, and they are free.

Frequently Asked Questions

How many points do you need to pass CT-ATLaS?

You need 47 of the 71 available points, roughly 66 percent. The paper has 40 questions and ISTQB weights them, so harder questions carry more points than easy ones. You have 120 minutes, plus 25 percent extra if the exam language is not your native one.

What do you need before you can take CT-ATLaS?

ISTQB requires either the Foundation Level certificate at version 4.0, or an earlier Foundation Level certificate plus the Agile Tester Foundation Level certificate. It also expects sufficient practical experience, to be confirmed with your exam board. Three years of agile experience and an accredited course are recommended, not mandatory.

How much does the CT-ATLaS exam cost?

The listed fee is USD $199 for the 120-minute, 40-question paper. ISTQB sells exams through its exam providers, so tax, currency and delivery options can differ by country. Check the amount with your chosen provider before booking, because it can change without notice.

Is CT-ATLaS harder than the Advanced Test Management exam?

They test different skills, so difficulty depends on your background. CT-ATLaS covers organisation-wide quality, value streams and test strategy in agile settings, while Test Management covers project-level planning, including traditional approaches. Candidates from scaled agile programmes usually find ATLaS closer to their own work.

Who is the CT-ATLaS certification for?

ISTQB aims it at people in organisations pursuing agility at scale who already understand agile testing: test managers, heads of testing, quality coaches, release train engineers, Scrum Masters and similar roles. It suits those who guide testing across several teams, not those who work inside a single team.

Select ratingPoorOkayGoodGreatAwesome

Rating: 5 / 5 (76 votes)