ISTQB CT-AI v2.0 Guide for QA Engineers: What Changed in 2026
Understand the ISTQB CT-AI v2.0 scope, syllabus changes, exam facts, practical exercises, migration choices, and a focused study plan for QA engineers.
ISTQB CT-AI v2 is the 2026 specialist syllabus for testing AI-based systems, not for using AI to automate ordinary testing. Version 2.0 replaces the mixed scope of v1.0 with a seven-chapter, machine-learning-lifecycle path covering data, models, system testing, generative AI, and ML development. Existing v1.0 certificates remain valid, and the old exam has published sunset dates. For the wider tooling context, start with the AI test automation pillar; this guide answers what changed, who should switch, and how a QA engineer can prepare without relying on exam dumps.
The source of truth is the CT-AI v2.0 GA syllabus, dated April 17, 2026, plus ISTQB's April 21 release announcement. Treat course slides, practice sites, and summaries as secondary aids. They can lag the release or preserve v1 terminology after the scope changed.
The 2026 Change in One Decision Table
| Question | CT-AI v1.0 | CT-AI v2.0 | Practical decision |
|---|---|---|---|
| What is in scope? | Testing AI-based systems and using AI in testing | Testing AI-based systems only | Choose v2 for ML, GenAI, data, and model quality work |
| How is the content organized? | 11 chapters spanning both directions | 7 chapters organized around the ML lifecycle | Rebuild notes by lifecycle; do not renumber old flashcards |
| Is GenAI testing explicit? | Predates today's dedicated treatment | Includes a dedicated GenAI and LLM testing section | Study exploratory testing, evaluation challenges, and red teaming |
| Is practical work emphasized? | Four-day accredited training minimum in the original release | Three-day recommended training with hands-on objectives | Practice calculations and test design, not definitions alone |
| What happened to AI-assisted testing? | Included | Removed from CT-AI | Use CT-GenAI or an implementation guide for AI4Testing |
| Must a v1 holder retake? | Certificate already awarded | No mandatory upgrade or bridging exam | Retake only if the new learning outcomes justify it |
The table reflects ISTQB's own v2 FAQ, not an inferred curriculum comparison. The FAQ says the syllabus moved from 11 chapters to 7, recommended training moved from four days to three, v2 focuses exclusively on testing AI-based systems, and v1 certificates remain valid. It also says there is no bridging exam.
Why ISTQB Split "Testing AI" from "AI for Testing"
The split is the most important fact in this ISTQB CT-AI v2 guide. "Testing AI" means evaluating an AI-based product or component: its input data, trained model, probabilistic behavior, robustness, bias, deployment behavior, or GenAI output. "AI for testing" means using an AI capability to help test conventional software: generating cases, exploring a UI, repairing a locator, or summarizing failures.
Version 1.0 deliberately covered both. The official retiring v1.0 page still describes its audience as people testing AI-based systems and/or applying AI in testing. Version 2.0 removes the second direction so it can go deeper into the first. ISTQB now points candidates interested in using generative AI during testing toward CT-GenAI.
That boundary prevents a common preparation failure: spending weeks comparing test-generation products for an exam centered on data representativeness, model metrics, test oracles, metamorphic relations, drift, and ML deployment. The sibling guide on AI4Testing versus Testing AI applies the distinction to team strategy. The two practices can coexist in one QA organization, but they need different risks, evidence, and skills.
The Seven-Chapter Lifecycle Map
The syllabus has seven numbered content chapters. Appendices and references appear later in the document, so "seven chapters" does not mean the PDF has only seven sections or a short reading load.
1. Introduction to artificial intelligence
The opening chapter establishes the system vocabulary needed for testing. It differentiates AI-based and conventional systems, discusses categories of AI, introduces generative AI, and covers implementation choices such as hardware, model hosting, pretrained models, frameworks, and the effects of standards and regulation. A tester should leave this chapter able to identify where learned behavior enters a system and where ordinary deterministic testing remains applicable.
2. Quality characteristics for AI-based systems
This chapter connects behavior to AI-specific quality characteristics and acceptance criteria. The syllabus aligns its treatment with ISO/IEC 25059. That does not turn every characteristic into one universal score. A safety-related classifier, a recommendation service, and a writing assistant have different harms, tolerances, and evidence. Translate characteristics into observable acceptance criteria tied to the deployment context.
3. Machine learning foundations
QA engineers need enough ML literacy to challenge a test design. The chapter covers forms of learning, the ML workflow, data preparation, training/validation/test datasets, confusion-matrix metrics, neural-network basics, and neural-network coverage measures. One learning objective explicitly asks candidates to calculate common classification metrics from confusion-matrix data. Reading definitions without doing calculations leaves a real gap.
4. Testing AI-based systems
This is the bridge from foundations to test strategy. It covers locked versus adaptive systems, statistical testing, test-oracle problems, GenAI and LLM testing, red teaming, AI/ML-specific test levels, and risk-based testing. The official syllabus makes red teaming an application-level learning objective, not merely a term to recognize.
5. Input data testing
Input data is executable risk in an ML product. This chapter covers bias, data pipelines, representativeness, constraints, and label correctness. It also includes a hands-on objective to perform input data testing. A mature QA plan therefore asks who supplied the data, what populations and operating conditions it represents, which constraints must hold, and how label quality is established.
6. Model testing
The model chapter assembles techniques suited to learned behavior. The syllabus includes functional performance testing, adversarial testing, back-to-back testing, metamorphic testing, experience-based testing, drift testing, overfitting and underfitting detection, and A/B testing. These are not interchangeable synonyms. Each addresses a different missing oracle, threat, or comparison.
7. ML development testing
The final chapter looks at risks introduced by ML development, configuration, frameworks, data allocation, interfaces, and deployment targets. The syllabus names deployment concerns such as cross-device behavior and API handling. This matters to SDETs because a model that looks acceptable in a notebook can still fail through preprocessing differences, serialization, resource limits, interface contracts, or target hardware.
Exam Facts That Changed and Facts That Did Not
According to the official CT-AI v2 certification page, CTFL remains a prerequisite. The listed structure is 40 multiple-choice questions, 44 total points, a passing score of 29 points, and 60 minutes. Candidates taking the exam in a non-native language receive the documented 25 percent additional time. Confirm booking, language, accessibility, and provider rules with the selected exam provider because local administration is outside the syllabus.
The v2 FAQ says the exam format remains unchanged even though questions now derive from v2 learning objectives. That distinction matters: familiar timing does not make old question banks aligned. The certification page links official sample questions and answers; at the time of this update it lists sample materials as v2.1. Use those to learn question style and diagnose weak topics. Do not use leaked items, "actual exam" collections, or memorized dumps. They are neither reliable evidence of competence nor a safe way to track a newly restructured syllabus.
English-language v1.0 training, exams, and retakes remain available until April 21, 2027; other languages remain available until October 21, 2027, according to the official transition FAQ. After those dates, ISTQB says training and examinations will use v2. A certificate already earned under v1 remains valid.
A Six-Week Study Plan for Working QA Engineers
Use learning objectives as the backlog and practical artifacts as the definition of done. Adjust hours to experience, but preserve the sequence because later techniques depend on the earlier data and metric concepts.
Week 1: establish the boundary and vocabulary
Read the introduction, business outcomes, chapter 1, and chapter 2. Create a one-page system map for an AI product you know: conventional components, data pipeline, model, inference boundary, users, affected groups, and monitoring. For every quality characteristic, write one context-specific risk and one candidate acceptance criterion. If the criterion says only "high accuracy," it is not yet operational.
Week 2: work through ML data and metrics
Study chapter 3. Build small confusion matrices and calculate the metrics required by the learning objectives. Explain why the same matrix can be acceptable in one risk context and unacceptable in another. Trace training, validation, and test sets through the workflow and state what decision each supports. Keep the held-out test set separate from tuning decisions.
Week 3: design system and GenAI tests
Study chapter 4. Compare a locked model with an adaptive model, then list the observability and regression implications of each. Write oracle strategies for outputs without one exact expected answer: property checks, reference comparisons, human evaluation, statistical thresholds, and metamorphic relations. Design a bounded red-team exercise with explicit authorization and stop conditions.
Week 4: test a dataset
Study chapter 5 and perform the hands-on work. Define schema, range, uniqueness, missingness, relationship, provenance, and label-agreement checks. Segment results across relevant populations rather than reporting only an aggregate. Record limitations when a subgroup is too small to support a confident conclusion.
Week 5: test a model and deployment path
Study chapters 6 and 7. Select model techniques based on risk instead of trying every named technique. Run at least one metamorphic relation, one robustness or adversarial probe, and one deployment contract check. Explain what each result proves and, equally important, what it does not prove.
Week 6: retrieve, practice, and correct
Use the official sample exam under timed conditions. Map every error back to a learning objective and the relevant syllabus paragraph. Reperform calculations without notes. Review hands-on artifacts as if another tester must reproduce them. Finish by explaining the complete lifecycle aloud, from input data risk to production drift, without collapsing it into a tool list.
The QASkills directory can supply reusable testing workflows for an AI coding agent, and the Playwright CLI skill can support browser-based practice. Those are AI4Testing resources, not CT-AI syllabus replacements. Keep the category boundary visible in your notes.
Example 1: Turn "Representative Data" into Testable Work
Suppose a support-ticket classifier routes cases into billing, account access, product defect, or abuse queues. "The dataset is representative" is too vague to test. A practical input-data review can produce this artifact:
This tool-neutral contract makes a small part of the expectation executable without claiming to measure representativeness by itself:
datasetContract:
requiredFields: [ticketId, submittedAt, region, language, text, queueLabel]
allowedQueueLabels: [billing, account-access, product-defect, abuse]
uniqueFields: [ticketId]
prohibitedOverlap: [training, held-out-evaluation]
reportsRequired: [class-distribution, region-language-segments, label-review]
| Risk | Check | Evidence | Failure response |
|---|---|---|---|
| A newly launched region is absent | Compare dataset share and expected operating share by region and language | Versioned distribution report with source dates | Collect data or limit the documented deployment population |
| Old product taxonomy corrupts labels | Validate labels against the current allowed queue set | Constraint results and rejected rows | Relabel or map through an approved migration |
| Rare abuse cases disappear in aggregate metrics | Report class counts and per-class outcomes | Segmented evaluation report | Change sampling/evaluation; do not hide the class in overall accuracy |
| Two annotators disagree systematically | Measure agreement and adjudicate a sample | Annotation guide, agreement result, adjudication log | Clarify policy and relabel affected records |
The example applies chapter 5 concepts without pretending a universal representativeness percentage exists. The deployment context determines the comparison population and acceptable uncertainty. A passing schema check cannot establish fairness, and a balanced sample can still have incorrect labels.
Example 2: Use a Metamorphic Relation When the Oracle Is Weak
Consider a model that assigns a fraud-risk score to a transaction. For many real transactions, the exact correct score is unknown. A domain-approved metamorphic relation can still test consistency: changing a formatting-only field, such as whitespace in an optional merchant note, should not materially change the score when preprocessing is specified to normalize that field.
The test procedure is concrete:
- Select a versioned evaluation sample that includes normal and edge cases.
- Generate a transformed sample by applying only the approved formatting change.
- Run both through the same model, preprocessing code, configuration, and hardware path.
- Compare outputs using a tolerance justified by the requirement, not one chosen after seeing failures.
- Investigate violations as possible preprocessing, feature leakage, numerical, or model-stability defects.
The core relation can be expressed as pseudocode before choosing a test framework:
baseline = model(preprocess(original_sample))
variant = model(preprocess(formatting_only_transform(original_sample)))
require distance(baseline, variant) <= requirement_approved_tolerance
This is not a claim that every score must be bit-identical. It tests a stated relation under controlled conditions. The CT-AI syllabus includes applying metamorphic testing to derive cases, but the product team still owns the relation and threshold.
Concrete Failure Paths During Preparation and Practice
You study AI test-generation tools instead of AI systems
Symptom: notes center on prompts, copilots, and locator healing. Cause: v1 content or broad "AI testing" search results were used. Recovery: return to the v2 learning objectives and move AI-assisted testing notes into a CT-GenAI or AI4Testing folder.
You memorize metrics but cannot choose one
Symptom: precision and recall formulas are correct, but you cannot explain the cost of false positives or false negatives. Recovery: attach every calculation to a decision, affected user, and error cost. Rework examples with different class prevalence and risk tolerance.
Your test set influenced model tuning
Symptom: the final reported performance was repeatedly consulted while changing features or hyperparameters. Recovery: record the leakage, create a new held-out evaluation where feasible, and document the limits of earlier results. Renaming the dataset does not restore independence.
A GenAI check expects one exact paragraph
Symptom: every semantically valid variation fails. Recovery: separate deterministic constraints from rubric-based, statistical, adversarial, and human evaluation. Read the testing LLM applications guide for broader implementation patterns, while using the CT-AI syllabus for certification scope.
You treat a certificate as production approval
Symptom: a team cites CT-AI completion instead of product evidence. Recovery: build a risk-based strategy for the actual system, data, users, and deployment. Certification establishes a shared body of knowledge; it does not certify a model or satisfy organization-specific assurance obligations.
Should You Finish v1.0 or Switch to v2.0?
Stay with v1 if you are far into accredited preparation, intend to sit before the relevant sunset date, and value finishing the mixed curriculum. Move to v2 if you are starting now, work on AI-based products, or need the lifecycle, GenAI, data, and model emphasis. A valid v1 holder does not need to retake. A professional may still choose v2 training for learning value, but ISTQB explicitly says no bridging exam exists.
If your day-to-day goal is generating or repairing conventional tests with AI, compare AI4Testing and Testing AI, then use the AI-generated code review playbook and self-healing governance guide. CT-AI v2 deliberately does not teach those operational workflows.
Version and Scope Limitations
This guide is current to July 14, 2026 and references the CT-AI v2.0 GA syllabus dated April 17, the April 21 release, and the official pages available on the update date. ISTQB can revise sample materials, exam-structure documents, translations, and provider links without changing the syllabus version. Verify those assets before booking.
The syllabus summarizes referenced standards, including ISO/IEC 25059, but the standard's full text and an organization's regulatory obligations are separate sources. CT-AI also does not prescribe one production toolchain, one fairness metric, one red-team method, or one acceptance threshold. The examples here illustrate syllabus application; they are not exam questions and are not universal compliance controls.
Frequently Asked Questions
1. What is ISTQB CT-AI v2.0?
It is ISTQB's current specialist certification syllabus for testing AI-based systems. It covers AI and ML foundations, AI quality characteristics, input data, model and system testing, GenAI/LLM testing, and ML development testing through a lifecycle-oriented structure.
2. What was removed from CT-AI v2?
Content about using AI to support software testing was removed. ISTQB directs candidates interested in generative AI applied to the testing process toward CT-GenAI. CT-AI v2 uses its narrower scope to deepen testing of AI-based systems.
3. Does a CT-AI v1 certificate expire when v1 exams retire?
No. ISTQB states that certificates obtained under v1 remain valid and there is no mandatory retake. The sunset dates govern availability of v1 training and exams, including retakes, rather than already issued certificates.
4. Is CTFL still required for the CT-AI v2 exam?
Yes. The official certification page lists ISTQB Certified Tester Foundation Level as the entry requirement. Confirm that your certificate and chosen provider satisfy booking requirements before paying.
5. How difficult is the CT-AI v2 exam?
Difficulty depends on the candidate's testing, data, and ML background. The learning objectives include understanding and application, including metric calculations, dataset constraints, metamorphic test design, red teaming, and hands-on work. A definitions-only study method is therefore incomplete.
6. Are exam dumps a good way to prepare?
No. Use the syllabus, learning objectives, accredited training if desired, and official sample questions and answers. Dumps can be unauthorized, inaccurate, or aligned to v1, and memorization does not build the practical reasoning emphasized by v2.
7. Does CT-AI v2 teach Playwright agents or self-healing tests?
No. Those are examples of AI used for conventional testing, outside the new CT-AI scope. Official Playwright agents can still be useful in a QA workflow, but they belong to AI4Testing rather than the CT-AI v2 body of knowledge.