ISTQB CT-AI: Testing Machine Learning Systems for Real Risks

The Certified Tester AI Testing (CT-AI) qualification from ISTQB addresses a specific testing problem: software whose behavior depends on data, learned models and probabilistic outputs cannot always be tested as though a fixed input should produce one fixed answer. The current CT-AI v2.0 syllabus broadens its coverage of AI-based systems, including generative AI and large language models. ISTQB states that this version replaces CT-AI v1.0, with transition arrangements allowing v1.0 examinations for limited periods. The latest version should guide preparation unless a candidate deliberately books an available earlier-version assessment.

A fraud-screening system might label a transaction suspicious with a confidence score rather than issue a simple yes/no decision. Two transactions that look similar to a human may receive different scores because of patterns in training data. An ordinary functional test that verifies an API responds correctly is insufficient. Testers must examine data quality, model performance, robustness, fairness, repeatability where appropriate and the consequences of false outcomes. The role requires understanding what the AI system is intended to accomplish and how unacceptable behavior can be detected even when outputs are not perfectly predictable.

Identify AI quality characteristics and realistic acceptance criteria

Testing begins with the product's business purpose. A music recommendation service and a diagnostic decision-support model both use machine learning, yet they demand different assurance levels. Define the affected users, decisions, data, possible harms and expected quality. AI systems may raise concerns about correctness, reliability, robustness, transparency, explainability, fairness, safety, privacy and security. These qualities are related but not interchangeable. A model can achieve high overall accuracy and still fail badly for a smaller population or a rare high-consequence condition. Good acceptance criteria reflect the specific application and the people affected.

Quality requirements need measurable or otherwise assessable conditions. A vague objective such as “the model shall be fair” is difficult to test. A better requirement specifies which outcomes must be compared across relevant groups, which disparities are unacceptable and how exceptions are investigated. Similarly, “robust against unexpected inputs” should lead to an agreed range of data quality defects, shifts and adversarial cases. Some measures involve tradeoffs; increasing sensitivity to a rare hazardous event may increase false alarms. Testers must understand these tradeoffs and communicate them to risk owners without pretending that every criterion can be maximized simultaneously.

An AI-based system is more than a model file. Its behavior depends on inputs, preprocessing, feature transformations, thresholds, deployment infrastructure, user interface and any human review process. If a model produces a correct score but the application displays it as an unquestionable decision, the system may still fail its intended safety or fairness requirements. Define test boundaries that include the components that turn the output into an action. Record versions of models, datasets and configurations because a result tied to one release may not apply to a later one. Testing must be able to describe exactly what was evaluated.

ISTQB CT-AI v2.0 introduces quality considerations for modern AI, including generative applications. A large language model may produce plausible but unsupported statements, reveal sensitive information from a retrieval source or mishandle a prompt that includes conflicting instructions. Testing LLM application reliability requires evaluation criteria tied to its use: groundedness in approved sources, safe handling of user data, consistency with access rules and correct escalation when uncertain. A chatbot drafting marketing text calls for different thresholds than one advising on financial or clinical matters. Test design should follow risk and expected outcomes rather than merely collect prompt examples.

Test datasets and machine-learning models at the right levels

Machine learning quality depends heavily on the data used for training and evaluation. Dataset testing should examine completeness, validity, balance, representativeness, labeling quality, provenance, privacy constraints and the risk of leakage between training and test sets. A model that appears excellent because near-duplicate records leaked from training into evaluation has not demonstrated generalization. If the deployment population differs from the training population, even correct historic metrics may be misleading. Testers should ask which data periods, user groups, environments and failure cases are represented. Document known gaps and uncertainties before promoting model performance claims.

For a classification system, metrics such as precision, recall, specificity, confusion matrices and false-positive or false-negative rates address different questions. In fraud detection, missing a fraudulent transaction and falsely stopping a legitimate customer have different costs. An accuracy figure can disguise poor detection when fraud is rare. For a predictive-maintenance model, false negatives might lead to equipment failure, while excessive false positives could cause unnecessary maintenance stoppages. Use application-specific criteria and evaluate error patterns rather than focus solely on a flattering aggregate score. When a metric depends on a decision threshold, test relevant threshold choices.

Testing at different levels can reveal different weaknesses. Input-data testing checks that source records and transformations meet expectations. Model testing evaluates the learned function, quality metrics, robustness and bias using appropriate datasets. Machine-learning development testing examines the broader process that produces and updates models, including versions, training procedures, experiments and pipelines. Integration testing verifies that model services, preprocessing, postprocessing and surrounding applications behave together. System and acceptance testing examine the consequences for actual users and operational workflows. Passing one level does not imply all others are sound.

Test cases for non-deterministic behavior may use statistical properties, expected distributions, relationships between inputs and outputs, or ranges of acceptable behavior instead of fixed expected values. For example, a small change in harmless input formatting should not cause an unrelated large shift in a risk score. A metamorphic relationship might state that changing a transaction's irrelevant display label must not increase predicted fraud risk. Such techniques require domain understanding, careful definition and appropriate statistical confidence. Repeated runs can expose instability, but repetition alone does not prove the absence of systematic bias or data poisoning.

Adversarial and robustness testing should reflect realistic conditions. Input manipulation may exploit brittle correlations; malicious training data can alter learned behavior; distribution shift may occur without any attacker at all. Stress tests can evaluate missing fields, corrupted samples, rare cases or abrupt changes in user behavior. For language models, attacks may involve untrusted instructions embedded in retrieved documents or prompts designed to bypass business rules. The test objective is to discover consequential failure modes and validate defenses. An unusual input that produces a surprising answer is not automatically a security vulnerability; its significance depends on the harm it can cause.

Evaluate deployment behavior, monitoring and human oversight

AI testing does not end when a model passes a preproduction evaluation. Data distributions, user behavior, connected services and external requirements change. A fraud model trained on last year's transaction patterns may degrade when payment habits shift. Monitor data drift, performance against newly available ground truth, model errors, service availability, suspicious behavior and user complaints. Establish thresholds for investigation and rollback. These monitoring controls need identifiable owners and reliable data. Without them, a model can slowly become unsuitable while dashboards continue to report that its API is available.

Human involvement must be tested as part of the workflow. If staff review model recommendations, do they understand confidence and limitations? Can they challenge incorrect suggestions, and do they have enough time to do so? A human reviewer who approves thousands of outputs mechanically may offer little real control. Testing should include escalation and override paths, especially for high-impact decisions. Explainability tools can help reviewers investigate some behaviors, but visual explanations should not be mistaken for definitive causal proof. Good evaluation combines quantitative evidence with domain-specific judgment.

Security, safety and privacy need coordinated test plans. Check whether users can retrieve records outside their authorization, whether training information can leak through outputs and whether tool access is constrained independently of model responses. A generative assistant that can invoke payment or account-management APIs deserves testing of those transaction boundaries. Logs should permit investigation without retaining secrets unnecessarily. Supplier models and external APIs can change without notice; release and contract arrangements must account for those changes. The test team needs to know what can be examined directly and which assurance evidence must come from a provider.

Reporting should make limitations visible. A benchmark score achieved in a laboratory may not apply to a different country, user group or deployment environment. Distinguish functional conformance, predictive performance and business safety. State test datasets, sample sizes, known exclusions, versions and tolerances. When risks remain, document the decision owner and required monitoring. A clear adverse finding is often more valuable than a positive score lacking context. Testing quality means producing information that helps stakeholders decide whether the AI system is fit for its intended purpose.

Prepare for CT-AI v2.0 and distinguish the two ISTQB AI paths

ISTQB states that its CT-AI v2.0 syllabus includes AI concepts and quality characteristics; machine learning and metrics; testing AI-based systems; input data, model and machine-learning development testing; and testing generative AI and large language models. The version-2 exam has 40 questions, 44 total points, a 29-point passing score and 60 minutes under its current public guidance. The CTFL Foundation Level certificate is a prerequisite. The earlier CT-AI v1.0 syllabus remains temporarily available under published retirement dates; candidates must confirm the version and syllabus used by their chosen exam provider.

A practical preparation project is to test a customer-support classifier that routes complaints by urgency. Define meaningful quality characteristics, select training and evaluation data, calculate confusion-matrix metrics and study failures for rare but serious cases. Then introduce a shift in the incoming customer population and test the monitoring and escalation behavior. Extend the scenario with a generative assistant that drafts responses, including tests for fabricated claims and confidential-information exposure. This sequence demonstrates how AI quality, data and operational controls fit together.

CT-GenAI is not an alternate title for CT-AI. The GenAI specialty focuses on using generative AI tools to support the software testing process, whereas CT-AI v2.0 focuses on testing AI-based systems themselves. A tester can benefit from both, but the primary question differs: is the AI product trustworthy, or how should a testing team safely and effectively use AI assistance? This distinction helps candidates select the right syllabus and avoid studying outdated “AI for testing” material when preparing for the newer CT-AI scope.

CT-AI is most useful when it changes how a team asks questions about quality. Instead of treating a model as a mysterious function that passed one accuracy benchmark, the tester examines data, risk, deployment context and evidence of continuing fitness. AI systems can be valuable precisely because they learn complex patterns, but that feature makes their limitations harder to observe. The certification encourages testers to develop an explicit, repeatable and risk-informed way to discover those limitations before users suffer their consequences.