ISTQB CTAL-TA v4.0: Exam Format, Syllabus and Mock Test Plan

Updated on 8 October 2026. What’s new: exam details corrected to 45 questions and USD $249, and the guide now follows syllabus v4.0 released in May 2025

A CTAL-TA mock test written for syllabus v3.1 will drill you on material ISTQB has since reshaped. Version 4.0 appeared on 2 May 2025: equivalence partitioning and boundary value analysis folded into domain testing, CRUD and metamorphic testing arrived, and the paper now holds 45 questions in 120 minutes, with 51 of 78 points needed to pass. This guide shows what to practise and how to read your practice scores.

Is a mock test built for CTAL-TA v3.1 still any use now that v4.0 is current?

Partly, and the part that is no longer useful is the part that used to carry the most marks. ISTQB's Test Analyst certification page calls v4.0 the latest released version, and I checked it in October 2026. It keeps the v3.1 information available only until its sunset dates, which it gives as 16 May 2026 for English-language exams and 16 November 2026 for non-English ones. The syllabus's own revision history describes v4.0 as a major update with an overall revision and a scope update, not a set of errata.

The release notes inside the syllabus explain what moved. The table below lines up the two versions so you can judge any practice paper against it.

Measure	Syllabus v3.1.2	Syllabus v4.0
Learning objectives	31	36
K2 objectives (understand)	16	22
K3 objectives (apply)	5	11
K4 objectives (analyse)	10	3
Training time	1,290 minutes	1,215 minutes
Black-box techniques	Equivalence partitioning, boundary values, pairwise, use cases and others as separate items	Grouped as data-based, behavior-based and rule-based
Reviews and defect work	A chapter on reviews only	Defect prevention: models, reviews, result analysis, defect classification
Test tools	A chapter of their own	Folded into Section 1.3, with keyword-driven testing at K3

Read the K3 and K4 rows twice. The old syllabus asked you to analyse techniques at K4; the new one asks you to apply them at K3, so questions now hand you a concrete specification and expect a worked answer: a set of test values, a count of coverage items, a minimised decision table. A v3.1 mock test full of "which technique is best here?" questions trains the wrong skill.

A three-question check for any practice paper

• Does it use the words domain testing, combinatorial testing, CRUD testing, metamorphic testing, test charter and crowd testing? If none appear, it is written for v3.1.
• Do the technique questions ask you to calculate or construct something, rather than only recall a definition?
• Does it say which syllabus version it follows? ISTQB's own sample paper does: it is numbered v4.1 and marked as compatible with syllabus v4.0.

Material that fails the check is not worthless. Risk-based testing, usability, interoperability and review techniques survived the rewrite. Just do not let a v3.1 score decide when you book.

What must you hold before booking, and how is the Test Analyst paper built?

You need the Certified Tester Foundation Level certificate first. ISTQB's page words it as holding Foundation Level v4.0 (preferred) or a previous version, plus sufficient practical experience, and the syllabus adds two recommendations rather than rules: about six months as a system or user acceptance tester or as a developer, and a course accredited by an ISTQB member board. The K3 questions are easier if you have written real test cases.

Exam detail	CTAL-TA
Full name	ISTQB Certified Tester Advanced Level - Test Analyst
Exam code	CTAL-TA
Syllabus version	CTAL-TA v4.0
Category	Core Advanced
Number of questions	45
Duration	120 minutes
Passing score	51 / 78
Exam fee	USD $249

The pass mark is stated in points, not questions, because questions are weighted. ISTQB's free v4.1 sample paper contains 45 questions worth 78 points in total, which matches the exam format. Counting them gives the mix below. Treat it as indicative: the live paper is assembled under ISTQB's exam rules, but the sample is the best public picture of it.

Points per question	Questions in the sample paper	Points contributed
1	18	18
2	21	42
3	6	18
Total	45	78

Fifty-one of 78 is about 65 per cent of the points. Candidates who sit the paper in a language that is not their native one receive 25 per cent extra time, which turns 120 minutes into 150 on the ISTQB page's wording. Divide 120 minutes by 78 points and you get roughly 92 seconds per point, so a one-point question deserves about a minute and a half, a two-point question about three minutes and a three-point scenario about four and a half. Those are working figures for pacing, not ISTQB rules.

Which chapters earn the most study time, and which are cheap to learn?

The syllabus gives training minutes per chapter, and they add up to 1,215, or 20.25 hours of an accredited course. They are a guide to effort rather than a promise about marks, since this syllabus does not print a question count per chapter. Still, one chapter holds more than half of the time.

Chapter	Minutes	Share	Objectives	Level mix
1. The Tasks of the Test Analyst in the Test Process	225	18.5%	12	11 K2, 1 K3
2. The Tasks of the Test Analyst in Risk-Based Testing	90	7.4%	2	1 K2, 1 K4
3. Test Analysis and Test Design	615	50.6%	13	4 K2, 8 K3, 1 K4
4. Testing Quality Characteristics	60	4.9%	4	4 K2
5. Software Defect Prevention	225	18.5%	5	2 K2, 2 K3, 1 K4

The level counts explain the time. The syllabus's time allowance works out at a quarter of an hour per K2 objective, an hour per K3 objective and an hour and a quarter per K4 objective, so the 22 K2 objectives take five and a half hours, the 11 K3 objectives eleven hours and the 3 K4 objectives three and three-quarter hours. Over half of the course is spent on skills you must perform, and Chapter 3 owns eight of the eleven. Chapter 4 is the cheapest: four explain-level objectives in an hour of teaching. Chapter 2 looks small but holds the regression-selection objective, one of only three K4 items, so do not skip it. The full topic list is on the CTAL-TA syllabus page, and the vendor's own wording is in the v4.0 syllabus PDF.

What do Chapters 1 and 2 expect from you in the test process and in risk work?

Test activities across lifecycles

The syllabus says the test analyst concentrates on four of the seven test process activities: analysis, design, implementation and execution. How that plays out depends on the lifecycle. In a sequential model your work shifts over time, from supporting planning early to executing late. In an incremental model you repeat the same activities for each increment and pay special attention to regression suites. In an iterative model the role is adaptive and the regression suite needs constant care. One advice holds for all three: be involved from the first phase.

Know the entry criteria for test analysis (planning done, a defined test basis, product risks evaluated), and know that an anomaly seen during execution is not always a defect in the test object. The syllabus lists missing preconditions, wrong test data, faults in scripts or the environment, and misread specifications as other causes. When an automated test fails, the analyst may need to re-run it by hand to rule out a false positive.

Work products: test cases, environments, oracles and data

Section 1.3 is where v4.0 added the most new material, and every item is explain-level except keyword-driven testing.

• High-level and low-level test cases. A high-level case names conditions: "transfer more than the daily limit; expected: transfer rejected with a limit message". A low-level case fixes the data: "account balance 500.00, daily limit 300.00, transfer 350.00; expected: rejection and balance still 500.00". One high-level case can become several low-level ones.
• Nine quality criteria for test cases: correctness, feasibility, necessity, understandability, traceability, consistency, precision, completeness and conciseness. Expect a scenario in which one test case breaks a named criterion, for example a step saying "enter a suitable amount", which fails precision.
• Test environment requirements. For each environment item the syllabus asks for an identifier, a description, who is responsible, the period it is needed and its fidelity to production.
• Test oracles. A test oracle tells you the expected result. When no cost-effective oracle exists you face the test oracle problem, caused by data complexity, non-determinism, probabilistic behaviour or missing requirements. The listed answers are pseudo-oracles, model-based testing, property-based testing, metamorphic testing and human oracles.
• Test data. Know the difference between pseudonymised data (personal details replaced by artificial identifiers) and anonymised data (identifying information removed), why hard-coded data in low-level cases hurts maintenance, and what time-sensitive data does to a test that was valid last month.
• Keyword-driven testing (K3). Keywords are action or verification keywords, living on at least two layers: a domain layer in business language and a test interface layer that talks to the system. A good keyword has a verb, uses the imperative, has one meaning and is reusable. "Add Item To Cart" with a product parameter is an action keyword; "Verify Cart Total" is a verification keyword.

Risk and the regression question

Chapter 2 asks you to explain how a test analyst contributes to product risk analysis, using frequency of use, criticality, financial or reputational damage, test basis quality and legal or safety needs as inputs. The K4 objective is the harder one: analyse the impact of a change to decide the scope of regression testing. The syllabus names six selection approaches: risk-based selection tied to a risk register, history-based selection, coverage-based selection, a requirements traceability matrix, operational profiles and impact analysis. It calls impact analysis the most reliable technique for selecting automated tests, and says no single approach is clearly superior for manual tests, so expect questions that ask you to pick or combine approaches for a stated situation.

Which Chapter 3 techniques must you be able to apply, and what does a worked answer look like?

This is the heart of the exam, and v4.0 sorts the techniques by the kind of model underneath them. The hub below shows the five families; the sections after it work through each one.

Data-based: domain, combinatorial and random testing

Domain testing extends equivalence partitioning and boundary value analysis to partitions defined by several variables and Boolean conditions. Each atomic condition is a border, and you choose four kinds of point: ON, OFF, IN and OUT. Suppose a rule says free delivery applies when order total is at least 50 and customer age is greater than 17 (integers). The first border is closed, the second is open.

Border	ON point	OFF point	IN point	OUT point
Total >= 50 (closed)	50.00, on the border	49.99, just outside	80.00	10.00
Age > 17 (open)	18, inside and closest	17, on the border	40	5

Simplified domain coverage needs one ON and one OFF point per border, so two borders need four points. Reliable domain coverage adds an IN and an OUT point per border, so eight, before sharing points between borders. The syllabus says reliable coverage finds considerably more domain defects for only slightly more items. The trap in the open border is that the ON point is inside the partition and the OFF point sits on the border, the reverse of the closed case.

Combinatorial testing targets failures that appear only when particular parameter values meet. Two criteria matter: base choice coverage (pick a base value for every parameter, then vary one at a time) and pairwise coverage (every pair of parameter values appears in some test). Take three browsers, three operating systems and two languages: 18 full combinations, yet pairwise coverage needs only 9 tests, because the two largest parameters already force 3 x 3 pairs. The syllabus cites a limited study in which about 97 per cent of failures involved one or two conditions, which is why pairwise is so popular, and says higher risk can justify all combinations instead.

Random testing is K2: know its benefits (cheap volume, less bias from misplaced trust) and limits (it ignores data meaning, makes redundant tests, depends on an automated oracle and has no recognised coverage criterion). Use an operational-profile distribution to validate and a usage-agnostic one to verify. Fuzz testing and chaos engineering are applications of it.

Behavior-based: CRUD, state transition and scenario testing

CRUD testing checks the lifecycle of data entities with a matrix of functions against entities, each cell holding C, R, U or D. Completeness testing is static: does every entity have every operation? If a Customer entity can be created, read and updated but no function deletes it, that gap is an anomaly to investigate. Consistency testing is dynamic and includes negative cases such as reading an entity that was never created. Coverage is the operations executed divided by the operations in the matrix.

State transition testing adds two criteria to the Foundation Level ones. N-switch coverage covers valid sequences of N+1 consecutive transitions, so 0-switch equals valid transition coverage and a 1-switch is a pair of incoming and outgoing transitions at a state. Round-trip coverage covers loops that return to the starting state without repeating another state. Take a ticket with transitions New to Open, Open to Resolved, Resolved to Closed and Resolved to Open (reopened). There are 4 transitions to cover for 0-switch. The 1-switch pairs are New-Open-Resolved, Open-Resolved-Closed, Open-Resolved-Open and Resolved-Open-Resolved, which is 4 again. The only loop is Open, Resolved and back to Open. Remember the warning that the number of N-switches can grow exponentially, so 2-switch and above is reserved for high failure risk.

Scenario-based testing models workflows with activity diagrams or use cases. A use case has one main scenario, extensions that still reach the goal and exceptions that do not. When the model has loops, simple loop coverage tests each loop skipped, run once, run more than once and run the maximum number of times.

Rule-based: decision tables and metamorphic testing

Decision table testing now includes minimisation and a checksum. A full table has as many rules as the product of the values of its conditions. Merge action-equivalent rules with a don't-care dash, then check the table's consistency, feasibility, completeness and correctness. The checksum adds up how many original rules each minimised rule represents. Take three yes/no conditions (member, order over 50, coupon), which give 8 rules in the full table.

Minimised rule	Member	Order over 50	Coupon	Original rules covered
R1	Yes	Yes	-	2
R2	Yes	No	Yes	1
R3	Yes	No	No	1
R4	No	-	-	4

The checksum is 2 + 1 + 1 + 4 = 8, equal to the full table, so there are no gaps or overlaps. If R4 had read "No, Yes, -" the sum would drop to 6, and a checksum below the original means the minimised table is incomplete; a higher one points to overlapping rules. Equal checksums do not by themselves prove equivalence. For high-risk rules the syllabus advises skipping minimisation and covering the feasible columns of the full table.

Metamorphic testing builds follow-up tests from a source test using a metamorphic relation, which makes it a way round the oracle problem. Imagine a product search. Source test: searching for "laptop" returns 120 results. Relation: adding a price filter must never return more results, and every filtered result must also appear in the original list. You can generate many follow-up tests without knowing the exact expected counts. The syllabus notes it is a preferred technique for AI-based systems and that no recognised coverage measure exists for it yet.

Experience-based: charters, checklists and crowds

A test charter gives a session a mission, and the lightweight pattern is "Explore [target] with [resources] to discover [information]". For example: explore the refund workflow with expired cards and partial refunds to discover rounding and status errors. Charters can also hold scope, entry criteria, limitations, risks and historical defect data, and the more technique detail you add, the less room the tester has to roam. Checklists come in two forms: read-do, with concrete items such as invalid inputs, and do-confirm, which prompts ideas. Good items are clear, specific and phrased so that the answer is yes, no or not applicable. A checklist is never finished.

Crowd testing spreads work across diverse people and devices. Benefits are environment variety, scale, speed, low cost and a real-user view; limits are uneven quality, coordination across time zones, security of shared software and a flood of duplicate reports. The syllabus is clear that it supplements technique-based design and does not replace it.

Choosing a technique and automating the design

The K4 objective, selecting techniques to mitigate product risks, is a judgement question with many inputs: test objectives, product risk, test basis, recurring defect types, tester experience, lifecycle, contract and regulation, and project constraints. The table gathers the syllabus's own pointers.

Situation in the question	Technique that fits	Why
Many configuration options that interact	Combinatorial, pairwise or base choice	Interaction failures need parameter combinations
Stateful workflow with a repeating cycle	State transition with round trips, plus scenarios	Cyclical activities carry their own risk
Business rules with several conditions	Decision table testing	It targets logic and control-flow defects
No practical way to know the expected result	Metamorphic or experience-based testing	They work without a full oracle
Thin documentation, short schedule or low risk	Charters and checklists	Coverage is hard to define and speed matters
High risk or a regulated product	Stronger coverage: all combinations, 2-switch, unminimised table	Higher risk justifies more rigorous coverage

Techniques also combine: boundary values for guard conditions in a state model, or scenario-based testing with round-trip coverage for a cyclical business process. For automation, know the benefits of generating tests from a test model, among them extended capability, less maintenance, better traceability and less repetitive work, and the risks, namely conditions the model overlooks, underestimated model upkeep, stakeholders who find the model hard to read and the generic automation risks.

What do Chapters 4 and 5 add, and why do they deserve more time than their size suggests?

Quality characteristics

Functional testing is split into three sub-characteristics from ISO 25010. Completeness asks whether everything requested is implemented, and scenario-based and traceability work fit it best. Correctness asks whether results are right for valid and invalid inputs and leans on a good oracle, at any test level. Appropriateness asks whether the functions help users do their tasks, and suits exploratory and collaboration-based testing, often from system testing onwards.

Usability testing covers interaction capability, user experience and accessibility. The syllabus points to the WCAG conformance levels A, AA and AAA, and to three evaluation methods: usability reviews, usability test sessions with representative users, and questionnaires such as SUMI and WAMMI. Flexibility testing, for the analyst, means adaptability (combinations of target environments, so combinatorial techniques reappear) and installability (install, uninstall, update and reconfigure). Compatibility testing splits into interoperability, which the analyst usually owns, and coexistence, which belongs to the Technical Test Analyst syllabus.

Defect prevention

Chapter 5 is new in shape and holds two K3 and one K4 objective, so it behaves like a technique chapter. The measures to recognise are defect removal efficiency, phase containment effectiveness and cost of quality. Modelling the specification, with a state model, CRUD matrix or combinatorial model, exposes incompleteness, inconsistency and ambiguity before code exists. Five review techniques are named: ad hoc, checklist-based, scenario-based, role-based and perspective-based reading, where each reviewer also tries to produce the work product they would derive from the text.

The K4 objective asks you to analyse test results to improve defect detection. Know five approaches: predicted versus actual defect clusters, defect detection percentage, structural coverage analysis, test gap analysis and defect arrival pattern analysis (the Rayleigh curve is the classic reference). A warning from the syllabus is worth keeping: failed tests are not the same as defects, because one defect can cause many failures and one test can expose several defects. Root cause analysis closes the chapter, supported by defect classification such as orthogonal defect classification, IEEE 1044, severity-based schemes and defect taxonomies.

How do you use mock tests so that the score tells you something real?

Score by points, not by questions, and log every miss. A paper with 45 questions can be passed by missing eight easy one-pointers or failed by missing three three-pointers, so a raw percentage of correct questions flatters you.

Phase	What you do	What you keep
Baseline	Sit ISTQB's v4.1 sample paper untimed, answering before you read the justifications	A points score and a list of chapters with misses
Chapter drills	Practise Chapter 3 technique by technique, then Chapters 1, 5, 2 and 4, rebuilding each worked answer by hand	A one-page sheet per technique with your own examples
Mixed timed sets	Take 20 to 25 mixed questions against a clock set at 92 seconds per point	Minutes left and points lost to time
Dress rehearsal	Sit a full 45-question, 120-minute paper in one sitting	A final score, to compare with the 51-point line

If you want more papers than ISTQB publishes, a CTAL-TA mock exam gives you extra timed sets to run through the same four phases, as long as you check that its questions follow v4.0.

The miss log that makes the next paper better

For every wrong or guessed answer write four things: the chapter, the objective's K-level, the reason, and the fix. Reasons fall into only a few groups: you did not know the term, you knew it but could not apply it, you misread the stem, or you ran short of time. If most misses are "could not apply", you need more worked examples, not more reading. If they are "misread", slow down on the first read of each stem, because scenario questions hide the decisive constraint in one clause.

When are you ready?

Use a margin, because a practice paper is not the real one. A rule of thumb, my own and not ISTQB's: three papers in a row at around 75 per cent of the points, finished with ten minutes to spare, and no chapter where you lose more than a third of the points. The 65 per cent pass line leaves little room for a bad day, so the margin is cheap insurance. Never reuse a paper until you have forgotten its answers; a second pass over the same questions measures memory.

What does the Test Analyst certificate say about you, and what could come after it?

The syllabus describes the role plainly: it focuses on the customer's business needs more than on technical aspects, does mainly functional testing with some user-facing non-functional work, prefers black-box and experience-based techniques over white-box ones, and uses defect prevention to improve testing. The certificate proves you can do that work to a recognised standard, which helps because the title "test analyst" means different things in different companies. It does not teach you a tool, so pair it with hands-on practice in whatever stack your team uses.

The syllabus lists nine business outcomes for a certified test analyst:

• support testing that suits the lifecycle in use
• apply risk-based testing principles
• select and apply suitable test techniques
• document testing at the right level of detail and quality
• decide which types of functional testing to run
• contribute to non-functional testing
• contribute to defect prevention
• improve efficiency with tools
• specify requirements for test environments and test data

On progression, the syllabus says holders may also be interested in the other Core Advanced levels, Technical Test Analyst and Test Management, and after them the Expert Level in Test Management or Improving the Test Process. It also points to Agile Technical Tester and Agile Test Leadership at Scale, and to specialist certifications for particular technologies or industries. Pick by role: if you design tests for business behaviour you are already in the right place; if your work leans to code and tools, the technical or automation routes fit better; if you plan and lead, look at test management. ISTQB maintains the current list at istqb.org, so check it before you commit to the next exam.

Frequently Asked Questions

Is an ISTQB Test Analyst mock test useful for CTAL-TA?

Yes, if it follows syllabus v4.0. Use a mock test to find weak chapters, practise the 120-minute pace and rehearse worked answers for domain, combinatorial and decision table questions. Score in points, log every miss, and ignore papers still built on the older v3.1 techniques.

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

The CTAL-TA exam has 45 questions and lasts 120 minutes. ISTQB adds 25 per cent extra time for candidates who sit it in a language that is not their native one. Questions carry one, two or three points, so manage the clock by points rather than by question count.

What is the passing score for CTAL-TA?

You need 51 points out of 78, which is about 65 per cent. Questions are weighted at one, two or three points, so a candidate can miss several easy questions and still pass, or miss only a few heavy scenario questions and fail. Check your practice results in points.

Do you need Foundation Level before taking CTAL-TA?

Yes. ISTQB says candidates must hold the Certified Tester Foundation Level, with version 4.0 preferred but an earlier version accepted, and have sufficient practical experience. The syllabus also recommends roughly six months in testing or development and an accredited training course, though it does not make those two compulsory.

How much does the CTAL-TA exam cost?

The listed CTAL-TA exam fee is USD $249. ISTQB certifications are booked through exam providers and member boards, so confirm the exact price, currency and any local taxes with the provider you choose before you register. The fee is for the exam only, not for any training course.

Select ratingPoorOkayGoodGreatAwesome

Rating: 3.6 / 5 (5 votes)