An ISTQB CT-AI Study Plan: Where the Time Actually Goes
Where the study time for ISTQB CT-AI v2.0 really goes: the order to read the syllabus in, the CTFL habits that mislead you, how to drill ML metrics, and how to read a mock score.
CT-AI is a small exam that people underestimate. Forty questions in sixty minutes sounds like an afternoon of revision, and then the confusion-matrix arithmetic arrives and the afternoon turns into three weeks. The official numbers and the exam rules live in our ISTQB CT-AI v2.0 exam guide. This post is about the part a reference page cannot give you: where the study time actually goes, in what order to take the material, and how to tell from a mock score whether you are ready.
Why CT-AI feels harder than its size suggests
Nothing in CT-AI is intellectually heavy. The difficulty is that the syllabus asks you to hold three unfamiliar things at once: a vocabulary borrowed from machine learning, arithmetic you have not done since school, and a testing model in which there is no single expected result to compare against. CTFL trained none of the three. Candidates who fail rarely fail on the testing content — they fail because they read the material once, recognised every term, and never rehearsed using it.
Where the study time actually goes
Look at the official content listing for v2.0 and count sections rather than chapters. Six of the seven chapters carry one or two sections each. Chapter 3, Machine Learning, carries four: an introduction to ML, data for machine learning, ML functional performance metrics for classification, and neural networks. That single chapter holds the vocabulary, the arithmetic and the one genuinely new mental model, and it deserves close to half of your total study time even though it is one chapter of seven.
What you cannot turn that into is a question count. ISTQB publishes no per-chapter question split for CT-AI — our exam guide explains why, and why anyone quoting you "chapter 3 is worth eight questions" invented the figure. Budget your hours by how long the material takes to learn, not by a weighting nobody published.
The order to learn in
Front to back is the wrong order for this syllabus, because chapters 5, 6 and 7 are all specialisations of chapter 3. Work in three passes instead.
Pass one — vocabulary, fast (a weekend)
Chapters 1 and 2 at reading speed, plus the introduction to machine learning from chapter 3. Do not try to master anything here; build a one-line-per-term glossary in your own words and check each term against the official ISTQB glossary. What you are buying is the ability to read the rest of the syllabus without stopping.
Pass two — machine learning, slowly (the bulk of your time)
Back to chapter 3, and stay there. Data for machine learning first (training, validation and test splits, data quality, labelling, leakage), then the functional performance metrics, then neural networks — and those only to the depth the syllabus asks for: structure and testing implications, not backpropagation mathematics. If you find yourself in a maths lecture, you have overshot the syllabus.
Pass three — the testing chapters, in one sweep
Chapters 4 to 7 read quickly once chapter 3 is solid, and they are best read together, because what gets tested is precisely their boundaries: input data testing versus model testing versus ML development testing, and where generative-AI and LLM testing sits among them. Write the three ML-specific areas on one page with one distinguishing sentence each. That page is worth more in the final week than another read-through.
Where CTFL habits mislead you
The expected result. CTFL teaches you to compare an actual result against a single expected one. For a model there often is not one, which is the entire reason metamorphic and back-to-back testing exist. If a technique looks strange, ask what it is substituting for the missing expected result.
Flaky means broken. In CTFL, a test that passes on retry is a defect in your test. In an AI-based system, non-deterministic output can be correct behaviour. The question becomes whether the variation stays inside the acceptance criteria — which is why acceptance criteria for probabilistic systems get a section of their own.
Defects live in code. Here they live in data just as often: mislabelled examples, leakage between training and test sets, bias inherited from history. A perfectly implemented model trained on the wrong data is the AI-specific defect you have never had to look for.
Coverage means code or requirements. Model coverage and input-data coverage are different animals, and the syllabus expects you to notice that a strong score on the test set says nothing about the inputs that set never contained.
Drilling the metrics so they survive time pressure
Reading about precision and recall does not transfer. The only thing that transfers is having produced the numbers by hand, repeatedly, from a matrix drawn in an orientation you did not choose.
A routine that works: sketch a two-by-two matrix, drop in four arbitrary numbers, and write out accuracy, precision, recall and F1. Five a day for a week. Then make the numbers deliberately nasty — 990 true negatives and 2 true positives — and say out loud which metric is lying to you. Finally do a few where the matrix is transposed or the rare class is the positive one, because the exam will not draw it the way your notes do.
Then the half most people skip: for a stated business goal, say which metric matters and why. Knowing that recall is TP/(TP+FN) is the first point; knowing that a fraud screen would rather chase false alarms than miss a fraud is the applied question.
How to read a mock result
A mock score is a diagnostic, not a prediction. Pull three things out of it, in this order:
The percentage, not the point count. Our mocks weight every question at one point, while the real exam spreads 44 points unevenly across 40 questions; the exam guide explains that caveat. So compare percentage with percentage, and never map a raw mock score onto the real threshold.
The pattern of misses by topic. Two wrong on metrics and two wrong on ML development testing are not the same result and do not lead to the same next week.
The answers you got right for the wrong reason. Read the rationale on every option, including on questions you scored, or you keep the lucky guess in your result and the hole in your head.
The clock. If you ran out of time, the fix is not more revision — it is deciding in advance to flag calculation items and come back to them.
When you can stop studying
Our numeric readiness bar is on the guide page; the behavioural version is simpler. You are ready when you can explain without notes why a model with 99% accuracy can be useless; when a confusion matrix produces four metrics out of you in under a minute; when you can name the two ML-specific test levels and say what each one catches that the other does not; and when your last three mocks landed in the same band instead of swinging. If that holds, book it. If the scores still swing, the problem is a topic and not your nerves — find it in the breakdown.
Practise with our free ISTQB CT-AI mock exams, each with a written rationale on every option. If you are still deciding whether CT-AI is the right certification at all, start with our ISTQB CT-AI certification guide; what moved in the current syllabus is covered in CT-AI v2.0 vs v1.0: what changed. Exam rules and the official numbers: the ISTQB CT-AI page.
Frequently asked
Not front to back. Take chapters 1 and 2 in one fast pass for the vocabulary, spend the bulk of your time in chapter 3 (Machine Learning), and only then read chapters 4 to 7 in a single sweep: they are specialisations of chapter 3 and are hard to tell apart before it is solid.
To the depth the syllabus asks: structure, how simple networks work, and what that implies for testing. Backpropagation mathematics, optimisers and frameworks are out of scope. Working through a deep-learning tutorial costs you time that chapter 3 needs elsewhere.
Almost always that one topic has not settled and shows up more or less depending on the question mix — usually the metrics or the boundary between the ML test levels. Look at the misses by topic rather than at the total: a swinging score points at a specific gap, not at a bad morning.
Write one sentence per area about what it finds that the other does not. Input data testing examines the data going into the model — quality, distribution, labels. Model testing examines the trained model against its functional performance criteria. ML development testing looks at the pipeline that produces both.
It is not mandatory, and self-study from the syllabus and the sample exam is a legitimate route. For CT-AI the value of a course sits mostly in chapter 3: guided calculation exercises and the ability to ask a question save real time there. If you already work with ML, you can do without it.
Part of the ExamCaliber editorial team. Every ExamCaliber question and rationale is written and reviewed by hand against the current syllabus — never scraped from exam dumps.