ISTQB Technical Test Analyst (TTA): Syllabus v4.0 and Study Roadmap

People often assume the ISTQB Technical Test Analyst exam is a programming test. It is closer to a code-reading and judgement paper: you trace short pseudo-code to count coverage, pick a technique for a described project, and weigh security, reliability and performance risks. The CTAL-TTA v4.0 paper has 45 questions in 120 minutes and needs 51 of 78 points, and this roadmap walks through what each of its six chapters asks of you.

Is the Technical Test Analyst paper a coding test, and who is it meant for?

No, but it does assume you can read code. ISTQB's Technical Test Analyst page describes the certificate as a thorough introduction to the technical testing skills many organisations now rely on: risk-based testing, white-box testing, static and dynamic analysis, non-functional testing and test automation. Nothing on the paper asks you to write a program. Instead, you read a ten-line fragment and say how many tests reach 100% decision coverage, or you read a scenario about a payment gateway and say which performance test type answers the stakeholder's worry.

The audience is anyone involved in testing who wants more technical depth: people doing test analysis, test consulting or software development. The prerequisite is the Certified Tester Foundation Level certificate plus enough practical experience, and ISTQB leaves the exact experience rule to each Member Board or exam provider, so confirm it with yours before you pay.

How is this role different from the Test Analyst?

The Test Analyst certificate, CTAL-TA, is about test design from the business side: data, behaviour and rules in the requirements. The Technical Test Analyst looks at the same product from underneath. Where a Test Analyst asks whether the discount rule is applied correctly, a Technical Test Analyst asks whether every condition in the code that applies it has been exercised, whether the service survives a spike, and whether the code can be changed safely next year. The two certificates share a Foundation-level starting point and little else on the syllabus.

What does Chapter 1 ask about risk?

Chapter 1 is the smallest block of the syllabus, 30 minutes of course time, and both of its learning objectives are K2 (understand and summarise). The Test Manager owns the risk-based strategy; the Technical Test Analyst contributes the technical product risks (security, reliability, performance) and the project risks around test environments. Expect questions that ask which of three activities, identification, assessment or mitigation, a described task belongs to. It is cheap marks, and worth reading once the night before.

How is the v4.0 paper built, and where do its 1,200 syllabus minutes go?

The paper is multiple choice, and ISTQB's own sample paper shows how the 78 points arise. Set A in the v4.2 sample exam holds 45 questions: 20 worth one point, 17 worth two and 8 worth three. So a K2 recall question and a K4 scenario question are not equal, and the pass mark of 51 points (about 65%) rewards the harder questions more than the question count suggests.

Item	Detail
Exam code	CTAL-TTA
Certification	ISTQB Certified Tester Advanced Level - Technical Test Analyst (CTAL-TTA)
Questions	45
Duration	120 minutes (ISTQB adds 25% for candidates not sitting in their first language)
Passing score	51 / 78 points
Exam fee	USD 249
Prerequisite	Certified Tester Foundation Level plus practical experience
Booking route	Pearson VUE is one listed route; Member Boards also run exams
Syllabus version	CTAL-TTA v4.0

The timing is easy to misjudge. 120 minutes for 45 questions is a little under 2 minutes 40 seconds each, but a K4 question that makes you trace a loop or compare two architectures can take four minutes by itself, so the easy ones have to be quick. Work out your own pace before exam day: a first pass at about 75 seconds per K2 question buys time for the three-point scenarios.

Is v4.0 still the current syllabus?

Yes. ISTQB's exam page, checked in October 2026, lists CTAL-TTA Syllabus v4.0 with sample exams at v4.2. The syllabus itself carries a general-availability date of 30 June 2021. That matters if you own an older book: the 2019 edition included basis path testing and call graph analysis, and v4.0 removed both, rewrote data flow analysis as a K3 skill, rewrote the reliability and performance sections and added a short section on operational profiles. A study guide that spends pages on basis paths is teaching you something the current paper no longer examines.

Which chapter is worth the most study time?

The syllabus gives minimum course time per chapter, 20 hours in total. These are teaching minutes, not question counts, but they are the best published guide to depth. Read them next to the highest knowledge level in each chapter, because a K4 objective means a scenario question worth up to three points.

Chapter	Course minutes	Highest level	What a question asks you to do
1. Tasks in risk-based testing	30	K2	Match a task to identification, assessment or mitigation
2. White-box test techniques	300	K4	Design tests to a coverage target; choose a technique for a project
3. Static and dynamic analysis	180	K3	Find control flow and data flow anomalies; pick a dynamic analysis aim
4. Quality characteristics	345	K4	Turn a non-functional requirement into a test type and a defect profile
5. Reviews	165	K4	Spot problems in an architecture or code fragment against a checklist
6. Test tools and automation	180	K3	Build keywords from a process; judge why automation misses its return

Two chapters, 2 and 4, make up more than half of the 1,200 minutes, and the syllabus is the place to check the exact learning objectives for each. The full text is free in ISTQB's CTAL-TTA v4.0 syllabus PDF, and the CTAL-TTA syllabus outline on this site lists the same objective areas if you want a checklist to tick off.

How do statement, decision, MC/DC and multiple condition coverage differ on one decision?

Chapter 2 is where the paper turns arithmetic, so it is best learned on one decision rather than four definitions. Take the condition A and (B or C), three atomic conditions, so N = 3.

Technique	Tests needed for this decision	What it proves
Statement testing	As few as 1, if one run reaches the guarded statement	Each executable statement ran at least once
Decision testing	2: one TRUE outcome, one FALSE outcome	Both branches of the whole decision were taken
Modified condition/decision (MC/DC)	N + 1 = 4	Each condition alone can flip the outcome
Multiple condition testing	2 to the power N = 8	Every combination of the three conditions was run

What does an MC/DC set look like?

Here is a valid MC/DC set for A and (B or C), written as (A, B, C) with the result:

1. (true, true, false) gives TRUE
2. (false, true, false) gives FALSE: only A changed from test 1, so A alone flips the result
3. (true, false, false) gives FALSE: only B changed from test 1, so B alone flips the result
4. (true, false, true) gives TRUE: only C changed from test 3, so C alone flips the result

Four tests cover three conditions, matching the N+1 rule in the syllabus. The syllabus adds that a single test can serve several condition combinations, so N+1 is a typical count, not a fixed one. Questions often give you a decision with four conditions and ask for the minimum MC/DC test count: that is five, against 16 for multiple condition coverage. The gap is the reason MC/DC is the pragmatic choice for safety-critical code. If you want the formal definition and its history, Wikipedia's article on modified condition/decision coverage gives a clear background read.

Which traps does the syllabus warn about?

• Short-circuit evaluation. In "A and B", a language may never evaluate B when A is false, so some required condition combinations cannot be reached. Compilers can often be told to switch short-circuiting off for testing, but safety-critical rules may require the tested code and the delivered code to be identical.
• Coupled conditions. When one variable appears twice in a decision, you may not be able to vary one occurrence alone, so a clean MC/DC pair does not exist for it.
• Branch versus decision. The two are used interchangeably because the same tests cover both. A program with no decisions leaves decision coverage undefined (zero divided by zero), and ISO 29119-4 resolves this by requiring one test.
• 100% means "no more tests suggested". Full coverage is not full testing. It means the technique has no further tests to propose for that structure, and the expected results still come from the specification, not the code.

Where does API testing fit?

The syllabus is careful to call API testing a type of testing, not a coverage technique, and the learning objective is K2. Be ready for three ideas: negative testing matters because callers misuse interfaces; combinatorial testing is common because endpoints take many parameters; and loosely coupled services lose or duplicate transactions, so retry and recovery paths need tests. For RESTful APIs, the syllabus separates input coverage (operations, parameters, sequences of calls) from output coverage (every correct and error status code, every response property type).

How do you choose a white-box technique when a scenario hands you a project?

This is the single K4 objective in Chapter 2, and it is where candidates who memorised definitions lose points. The syllabus gives you a ladder and a method for climbing it.

The subsumption ladder

At 100% coverage, branch and decision coverage each subsume statement coverage, MC/DC subsumes decision and branch coverage, and multiple condition coverage subsumes MC/DC. In plain words: a test set that reaches a higher rung automatically reaches every rung below it. So a requirement needs only one criterion. Asking for both 100% statement coverage and 100% MC/DC is redundant, and an exam option that asks for both is a hint it is wrong.

Why the syllabus says to demand 100%

Asking for 80% coverage sounds sensible, but the 20% left untested tends to be the code that is hardest to reach, which is also the most complex and the most error-prone. The syllabus therefore recommends specifying 100% for one chosen criterion, with ISO 29119-4 letting you discount infeasible items so that 100% stays achievable. It is normal to set different levels for different parts of one system: flight control and in-flight entertainment do not carry the same risk.

Safety-related systems follow a standard

When failure could harm people or the environment, a regulatory standard fixes the coverage level for each integrity level. The syllabus uses IEC 61508 as the example, with four safety integrity levels:

IEC 61508 level	100% statement	100% branch	100% MC/DC
SIL 1	Recommended	Recommended	Recommended
SIL 2	Highly recommended	Recommended	Recommended
SIL 3	Highly recommended	Highly recommended	Recommended
SIL 4	Highly recommended	Highly recommended	Highly recommended

"Highly recommended" is treated as mandatory in practice, while "recommended" is often waived with a rationale. The syllabus also notes that ISO 26262 (automotive) and DO-178C (airborne software) define their levels differently, so a question should hand you the table it expects you to use.

Non-safety systems: eight factors

Without a regulator, the choice is a judgement, and the syllabus lists the factors it expects you to weigh: the contract, the customer, any sector regulation, the organisation's test strategy, coding style, historical defect data, the skills in the team and the tools available. A team whose code has no multi-condition decisions gains nothing from MC/DC, and a coverage target no installed tool can measure is a risk in itself. Read the scenario for exactly these clues.

What do static analysis, dynamic analysis and reviews catch that ordinary tests miss?

Chapters 3 and 5 are about finding defects without writing test cases, and together they hold just under nine hours of course time, a little more than Chapter 4 alone.

Control flow and cyclomatic complexity

Control flow analysis works on a graph of the program and finds badly designed loops, unreachable code, uncalled functions and wrongly sequenced operations. The same graph gives cyclomatic complexity, a positive integer counting independent paths. McCabe's argument, which the syllabus repeats, is that higher complexity means code that is harder to maintain and holds more defects, so any component with a high value should be reviewed for splitting.

Data flow anomalies

Data flow analysis follows each variable through three actions: defined, used and killed. The pairs and sequences that signal an anomaly are what the K3 question asks you to find:

• a definition followed by another definition or a kill with no use in between
• a definition that is never killed, a possible memory leak for dynamically allocated variables
• a use or kill before any definition
• a use or kill after a kill

Practise on short listings, marking d, u and k beside each line for one variable at a time. Also keep the distinction the syllabus draws: data flow analysis is static and inspects code, while data flow testing is dynamic and builds tests for definition-use pairs. Tools also report anomalies on paths that can never run, so a flagged anomaly is a warning to check, not proof of a defect.

Maintainability through static analysis

Static analysis tools check coding standards, search for repeated code that could become a shared component, and report coupling and cohesion. A maintainable design has low coupling (little reliance between components) and high cohesion (each component focused on one task). Tools raise warnings, not verdicts, so code can be syntactically correct and still be flagged. For web sites, the same tools can also check the structure of the site and look for exposure to injection and cross-site scripting.

Dynamic analysis: leaks, wild pointers and profiling

Dynamic analysis needs the code to run. A memory leak shows up as a steadily worsening response time, and it hides in testing because systems are restarted often, which reallocates memory; it first appears in production. A wild pointer may cause four outcomes: the program works by luck, crashes, misbehaves, or corrupts data (which can be a security problem too). The scary case is the program that works until a rebuild moves memory around. Profilers belong here as well: they count how often components are called, and the Pareto pattern of about 80% of run time in 20% of components tells developers where tuning pays.

Reviews and checklists

Chapter 5 has one K2 objective, why preparation time matters, and two K4 objectives: analyse an architectural design and analyse code or pseudo-code against the checklist given in the syllabus. The architecture checklist for web time behaviour lists connection pooling, load balancing, distributed processing, caching, lazy instantiation, transaction concurrency, OLTP and OLAP isolation, and data replication. The code checklist is language-neutral and covers structure, documentation, variables, arithmetic (comparing floating-point numbers for equality, testing divisors for zero), loops and branches. A K4 question will give you a snippet with one violation of this list; learn the categories well enough to name which item was broken.

Which quality characteristics does Chapter 4 test, and how does each one fail?

Chapter 4 is the largest block at almost six hours of course time and has the broadest reach. It follows ISO 25010 and covers security, reliability, performance efficiency, maintainability, portability and compatibility, plus planning issues and operational profiles. The skill tested is translation: a stakeholder concern in, a test type and likely defects out.

Characteristic	Sub-characteristics in the syllabus	Typical test or measure
Security	Confidentiality, integrity, authenticity, accountability, non-repudiation	Vulnerability scans, penetration-test attack plans, access-control checks
Reliability	Maturity, availability, fault tolerance, recoverability	Reliability growth testing, failure injection, recovery drills
Performance efficiency	Time behaviour, resource utilisation, capacity	Load, stress and scalability tests
Maintainability	Analyzability, modifiability, testability, modularity, reusability	Static analysis, reviews and dynamic maintainability checks
Portability	Adaptability, installability, replaceability	Install, migrate and swap-in tests on target platforms
Compatibility	Coexistence	Running beside other products in the same environment

Planning issues come first

The only K4 objective at the start of the chapter asks you to analyse non-functional requirements and write the sections of a test plan. Non-functional requirements are often vague or missing, so the syllabus suggests treating the existing version as a benchmark and asking several stakeholder groups (users, operations, maintenance staff), not just the customer. Production-like environments are expensive, and the options it names are production itself, a scaled-down copy, cloud resources or virtualisation. Data protection law may forbid copying production data, so anonymised test data must be planned, not assumed.

Security: know the threat list

The threats named in the syllabus include unauthorised copying and access, unintended side effects, cross-site scripting, buffer overflow, denial of service, man-in-the-middle attacks, broken encryption and logic bombs. Know one example of each, and know that security tests are scheduled at component, integration and system levels and repeated after release, especially in systems that keep receiving updates such as the Internet of Things.

Reliability: formulas worth memorising

Maturity is how well the system meets reliability needs in normal operation. High-reliability systems are tested with a reliability growth model: run realistic inputs from an operational profile, record failures and predict mean time between failures. Availability can be measured as MTTF divided by the sum of MTTF and MTTR, so a system that fails often but recovers quickly can still score well. Fault tolerance tests simulate failures to see if the system carries on, and recoverability tests check backup, restore and failover.

Performance: four terms that get confused

• Time behaviour covers response time (time to first response), turnaround time and throughput.
• Load testing raises load gradually from low and watches response time and resource use.
• Stress testing either pushes load past the maximum expected until the system fails, or cuts resources such as memory or bandwidth, then checks recovery.
• Scalability testing checks that the system scales up and down as demand changes.

The syllabus adds that performance testing has two goals: checking acceptance criteria (a page must appear within a stated number of seconds) and giving developers information on bottlenecks. A question may make you say which goal a described test serves.

The remaining three, briefly

Maintainability testing is static (reviews and analysis) and dynamic (measuring the effort to change). Portability covers installing, adapting to new environments and replacing one component with another. Compatibility in v4.0 means coexistence, two products sharing an environment without harming one another. Operational profiles describe how the system will really be used and drive the load and reliability tests above.

What do you need to know about automation and tools in Chapter 6?

Chapter 6 has three hours of course time and one K3 objective, constructing keywords from a business process; the rest are K2.

Treat the automation project as software development

The syllabus says a test automation project needs architecture, design, reviews and its own testing. The Technical Test Analyst's tasks include picking the tool (which can mean building one), defining interfaces to test management, defect and continuous integration tools, writing adapters, choosing keyword-driven or data-driven design, estimating cost with the Test Manager and scheduling maintenance time. A recurring theme is that capture and playback scripts break when the interface changes, so they are fine as a starting point and poor as the architecture.

Data-driven and keyword-driven, with a keyword example

Data-driven automation keeps one script and feeds it rows of test data. Keyword-driven automation names business actions and lets non-programmers combine them. For a K3 question you take a business process and list its keywords. For a flight booking process they might be: Login, SearchFlights, SelectFlight, EnterPassengerDetails, Pay, ConfirmBooking and Logout, each with parameters. A good answer keeps keywords at business level, reusable, and independent of screen layout.

Why automation fails to pay back

The K2 objective on failed return on investment is about technical causes: weak architecture, brittle interface-level scripts, unstable test environments, poor handling of unexpected software failures and test cases that assume a system state they did not create. Questions usually describe a symptom, such as scripts failing after every release, and ask for the root cause.

Specific tools, one line each

• Fault seeding inserts known defects to judge how good the tests are; fault injection adds faults at run time to test error handling.
• Performance tools generate load and measure; the issues are tool licence cost and realistic environments.
• Web tools check links, HTML and security exposures.
• Model-based testing tools generate tests from a model.
• Component test and build tools support unit tests and continuous integration.
• Mobile tools use emulators and real devices.

What route through the six chapters gets you exam-ready, and what can come next?

Plan on the syllabus's 20 hours of course time as the minimum, then add the practice that makes it stick. A five-week route that fits a working tester looks like this:

1. Week 1. Chapter 1, then statement and decision testing. Trace ten short fragments and compute coverage by hand.
2. Week 2. MC/DC, multiple condition testing, API testing and the technique-selection method. Build your own MC/DC sets for decisions with three, four and five conditions.
3. Week 3. Chapters 3 and 5. Mark define-use-kill sequences on listings, and review a code fragment against the syllabus checklist.
4. Week 4. Chapter 4, with the table above rebuilt from memory. Write a one-line test approach for each characteristic.
5. Week 5. Chapter 6, then two full 120-minute papers, one early in the week and one at the end.

Stretch it to six weeks if Chapter 4 or the code-reading is new to you. Before the first timed paper, download the free ISTQB CTAL-TTA v4.2 sample exam, because it is the closest thing to the real format and point mix. When you want more timed material to rehearse the 120-minute pace and the K4 scenarios, a CTAL-TTA practice exam gives you extra full-length attempts to review.

How do you read your practice score?

Aim for 65% or better consistently on papers you have not seen, which is the 51-of-78 line. Log every miss by chapter and by cause: wrong arithmetic, misread scenario, forgotten definition or timing. If most misses are arithmetic, do more hand-traced coverage. If they are scenario misreads, practise underlining the stakeholder's actual constraint before you look at the options.

What does the certificate open up?

The certificate shows a hiring manager that you can reason about code coverage, non-functional risk and automation architecture, which suits roles such as test automation specialist, performance tester or security-minded QA engineer. ISTQB notes that holders can go on to other Core, Agile or Specialist stream certifications. Within the Advanced Level, the natural companions are the Test Analyst certificate for design depth and the Test Manager certificate for leadership, and the syllabus itself points to the Test Automation Engineer syllabus for deeper automation work.

Frequently Asked Questions

How many questions and how much time does the CTAL-TTA exam give you?

The CTAL-TTA v4.0 exam has 45 multiple-choice questions and runs 120 minutes. ISTQB adds 25% extra time for candidates who sit the paper in a language that is not their first. That averages under three minutes per question, so scenario questions need a deliberate pace.

What is the passing score for the Technical Test Analyst exam?

You need 51 of 78 points, which is about 65%. Questions are not all worth the same: ISTQB's v4.2 sample paper has 20 one-point, 17 two-point and 8 three-point questions. Harder K3 and K4 questions therefore carry more of the total than their number suggests.

How much does the CTAL-TTA exam cost?

The CTAL-TTA exam fee is USD 249 for the v4.0 certification. Exam providers and ISTQB Member Boards set their own local pricing and booking rules, so check the fee and any extras with the provider you plan to use before you pay.

What are the prerequisites for the ISTQB Technical Test Analyst certification?

Candidates must hold the Certified Tester Foundation Level certificate and have sufficient practical experience. ISTQB does not publish one global experience rule. It tells candidates to ask their Member Board or exam provider which criteria apply before booking the Advanced Level exam.

Which version of the CTAL-TTA syllabus is current?

ISTQB lists CTAL-TTA Syllabus v4.0 as the current syllabus, with sample exams at version 4.2. The syllabus dates from June 2021 and removed basis path testing and call graph analysis from the earlier 2019 edition, so older study material may cover topics the paper no longer examines.

Select ratingPoorOkayGoodGreatAwesome

Rating: 5 / 5 (79 votes)