ISTQB CT-AI: Testing Machine Learning and AI-Based Systems

Software that contains an artificial-intelligence model introduces testing problems that ordinary deterministic applications do not always have. Results may depend on learned patterns, variable input distributions, probabilistic behavior, model updates, and data whose quality is difficult to measure. A test that succeeds on a fixed sample can fail when real-world conditions shift. A model can also be accurate on average while producing unacceptable outcomes for particular users or scenarios. The ISTQB Certified Tester AI Testing (CT-AI) qualification addresses how testers investigate and manage those characteristics.

The latest ISTQB CT-AI v2.0 syllabus replaces v1.0 and shifts the emphasis toward testing AI-based systems across the machine-learning lifecycle. It includes testing generative AI and large language models, but the separate CT-GenAI specialization is the qualification focused on using generative AI to help perform software testing. ISTQB states that the English v1.0 CT-AI exam remains available during a transition until April 21, 2027, with a later transition for non-English versions. Exam version must therefore be tied to the candidate's chosen provider and language rather than assumed from the short ct-ai URL.

Define quality requirements for probabilistic products

Testing an AI-enabled service begins with the business purpose and the harm that errors could cause. A model predicting inventory demand, prioritizing medical appointments, screening fraudulent transactions, or answering employee questions creates different expectations. A useful test strategy defines measurable acceptance criteria, identifies constraints on false positives or false negatives, and explains whose outcomes matter. Generic claims such as 'the model is accurate' are insufficient because they hide data distributions, business costs, and uncertainty.

AI quality includes conventional properties such as reliability, security, usability, and performance, as well as characteristics especially relevant to learned behavior. Robustness asks how results change when inputs are perturbed or conditions differ from training; transparency and explainability concern the information needed to understand behavior; fairness asks whether outcomes create unjustified disadvantages across relevant groups; and resilience includes the ability to detect and respond to degradation. The applicable quality standard and regulatory environment should guide the tests without turning every project into the same checklist.

Acceptance criteria need explicit trade-offs. A fraud detection model with very high recall may generate so many false alarms that customers or investigators are overwhelmed. A low false-positive rate may appear attractive while allowing important fraud to pass undetected. The test team should report the consequences of these trade-offs and ensure stakeholders agree on suitable thresholds for the actual use case. Where human reviewers are part of the workflow, their decisions and workload may also determine system quality.

Responsible AI and governance can provide useful context, but CT-AI's particular contribution is technical test design and evidence. Governance goals become test objectives only after the team identifies measurable criteria, representative data, procedures, and limitations. A statement that a system should be 'fair and safe' needs operational definitions before it can be meaningfully tested.

Test the input data before blaming the model

Model behavior reflects input data and the workflow that prepares it. Data can contain missing values, inconsistent units, duplicates, label errors, biased sampling, outdated records, or leakage from data that would not exist when the model is used. Testers must examine source quality, transformations, feature creation, partitioning, access controls, and the business meaning of the variables. A defect in a data pipeline may create a model failure that retraining alone cannot solve.

Training, validation, and test partitions serve different purposes. Training data informs parameter selection, validation data supports model development and selection, and a held-out test set provides evidence about performance on unseen examples. Reusing test examples repeatedly to tune a model contaminates the assessment; the evaluation data no longer functions as an independent check. Splitting randomly may also be misleading for time-series or user-based data when records from the same period or entity appear across partitions.

Data representativeness should be reviewed deliberately. A model trained mostly on large enterprise customers might perform poorly for small organizations; an image classifier tested only in ideal lighting may fail at night; a language system evaluated in one dialect may be less effective elsewhere. Testers should identify important operational slices and measure where performance changes. Aggregate performance can conceal harms within smaller but critical populations.

Data quality, validation, and profiling offers a general supporting concept: evaluate completeness, consistency, validity, timeliness, and provenance. CT-AI adds the model-specific question of how those characteristics affect prediction quality. Useful tests include schema constraints, checks for extreme values, target leakage, distribution shift, anomalous labeling patterns, and validation that the same transformations are consistently applied during training and inference.

Evaluate models with meaningful measures and comparisons

Model testing requires metrics appropriate to the task. For classification, a confusion matrix relates correct and incorrect predictions across classes. Precision measures how many predicted positives are genuinely positive, while recall measures how many actual positives are identified. Accuracy can be deceptive when classes are highly imbalanced. A model predicting that every transaction is legitimate may achieve an impressive accuracy percentage while detecting no fraud at all.

Regression problems need different measures, such as absolute and squared error, and may require analysis of error at important operating ranges. A small average error can conceal occasional extreme predictions with serious consequences. Testers should combine quantitative evaluation with business thresholds, outlier analysis, and comparison against a baseline. Evaluation should distinguish a statistically meaningful improvement from random variation and avoid claiming that a metric alone establishes fitness for use.

Overfitting occurs when a model learns peculiarities of training examples rather than generalizable patterns. Underfitting occurs when it cannot capture sufficiently important structure. The test team should look for gaps between training, validation, and held-out performance and consider the impact of data volume, model complexity, feature quality, and training procedure. A larger model is not automatically a better model, and an improvement on a benchmark may not persist under real-world conditions.

Foundation model evaluation before deployment illustrates similar concerns for generative systems, although its product context is not identical to every CT-AI project. In all cases, evaluation should specify which model version, dataset, prompt or configuration, threshold, and environment produced the result. Reproducibility is limited when inference is nondeterministic or services are updated without complete version visibility; the test report should state those limits.

Test at data, model, integration, and system levels

AI testing is most effective when performed across the lifecycle rather than only after deployment. Input data tests assess source and transformations; model tests evaluate the learned behavior; integration tests establish that preprocessing, inference services, authorization, and downstream applications work together; and system tests evaluate business workflows and user consequences. A technically correct model can still produce an unsafe product if the application presents confidence poorly or users are encouraged to act without appropriate checks.

Metamorphic testing is valuable when a single definitive expected output is difficult to specify. Instead of asking only whether a prediction equals one fixed number, the test defines an expected relationship under controlled transformation. For example, a harmless formatting change to a text input should not change a classification decision if formatting is irrelevant to the task. That relationship must be justified by domain knowledge; some transformations legitimately alter meaning or prediction.

Other approaches include pairwise combinations of relevant inputs, adversarial and boundary testing, back-to-back comparisons between implementations, and experience-based exploration. A test strategy should explain why each approach is appropriate and which defects it may reveal. Generating thousands of superficial samples without clear assertions can create activity without assurance. The important question is whether the tests challenge realistic failure mechanisms.

Testing machine-learning development includes the pipeline itself. Monitor data versioning, feature transformations, experiment records, training reproducibility, dependency integrity, and model release approval. A model artifact should have identifiable provenance and a controlled route to production. Independent evaluation is undermined if the training process silently overwrites its own test data or if deployment uses different preprocessing than the environment where quality was measured.

Address generative AI, large language models, and safety risks

Generative AI systems produce sequences of outputs rather than selecting from a fixed small set of labels. Exact-match expectations are often unsuitable for open-ended responses. Testers should evaluate factual grounding, task completion, instruction adherence, harmful or prohibited behavior, robustness to confusing input, and appropriate uncertainty. Some tasks can use reference-based metrics; others need domain-specific rubrics, controlled comparisons, or qualified human evaluation.

A large language model's output can vary across runs, versions, and prompting conditions. Good test design controls what it can—input, configuration, retrieval sources, available tools, and evaluation procedure—while reporting the remaining variability. A strong answer to one benchmark prompt does not establish reliability across users. Assessment should cover ordinary cases, edge cases, conflicting instructions, multilingual conditions where relevant, and scenarios in which the model should decline to speculate or request clarification.

Security tests should consider prompt injection, training or retrieval data poisoning, unauthorized tool access, leakage of sensitive information, and excessive confidence in generated content. Prompt injection and LLM application security are important when the AI system reads untrusted documents or can act on external services. An instruction embedded in a retrieved file should be treated as data, not as a trusted system directive. Testers should verify the application boundary around the model, not merely the wording of its safety prompt.

AI-based products may require red-teaming, exploratory testing, and monitoring after launch because deployment conditions change. However, evaluation should be authorized, proportionate, and carefully scoped. A risky experiment against real users is not justified simply because it may reveal a defect. Safe test environments and non-sensitive synthetic data may reduce harm, though the team should also assess whether synthetic examples represent production conditions adequately.

Monitor deployed models and manage change

Deployment is not the end of model testing. Model input drift can arise as user behavior, markets, devices, or data sources change. Labels may arrive late, making real-world accuracy hard to establish quickly. A monitoring plan should therefore include data distributions, error signals, quality proxies, user reports, operational reliability, and triggers for investigation. Not every change in distribution proves performance degradation, but important changes should be understood before the organization relies on the model unchanged.

Model updates need release governance. Compare candidate and existing models against common evaluation sets, important risk slices, and operating criteria. Consider shadow deployments or controlled rollouts when appropriate, and preserve a rollback route that respects the data and service dependencies involved. Version identifiers, evaluation results, and decision authority should be recorded so that performance changes can be attributed to particular releases or data shifts.

A useful quality report combines model metrics with human consequences. It might state where false positives increased, which users experienced degraded performance, and whether the new model reduces the business harm it was intended to address. Responsible monitoring also considers privacy and security: collecting excessive user input solely to evaluate a model can create additional exposure.

The relationship with CT-GenAI should remain explicit. CT-AI v2.0 examines the testing of AI systems, including generative models. CT-GenAI examines using generative models as aids to the testing process. A team developing a chatbot may need both competencies, but they answer different questions and should not be treated as two labels for the same syllabus.

Prepare for CT-AI version 2.0 through lifecycle exercises

ISTQB's current CT-AI v2.0 published exam structure includes 40 questions, a 60-minute standard duration, and a passing score of 29 points out of a 44-point total. Provider and language arrangements should be rechecked at registration because ISTQB maintains a defined transition from v1.0. The older syllabus placed more explicit emphasis on using AI in testing; v2.0 focuses on testing AI-based systems, and old v1.0 practice questions may be misaligned with the newer learning objectives.

Build an example model lifecycle and examine each stage. Choose a fraud classifier: define costs of false alarms and missed fraud, inspect how training labels were obtained, partition the data without leakage, evaluate precision and recall on meaningful slices, design metamorphic relations, test system authorization, and specify monitoring for changing transaction patterns. Then compare that process with a generative-answering system where outputs are less deterministic and grading requires task-specific rubrics.

Do not reduce preparation to remembering metric formulas. Explain when each measure is useful, what data can invalidate it, why a result may not generalize, and how application integration changes the risk. CT-AI knowledge is most valuable when it helps a team state exactly what its model-testing evidence supports—and which important behaviors remain uncertain.