CT-AI: Testing AI Systems for Reliable Behavior

An AI-powered service can pass every conventional interface test and still make harmful, unreliable decisions. A loan-screening model may behave consistently at the API boundary while producing different outcomes for comparable applicants. A language model may format a response correctly yet invent a source, disclose instructions, or change its answer when a harmless phrase is added. These failures require testing strategies that examine data, model behavior, uncertainty, and changes over time. The ISTQB Certified Tester AI Testing (CT-AI) qualification addresses this distinctive quality-engineering problem: how to evaluate systems whose outputs arise partly from learned behavior rather than explicit rules.

As of October 2026, CT-AI version 2.0 is the current ISTQB syllabus. It replaces version 1.0, whose English examinations are scheduled to end on April 21, 2027, followed by non-English versions on October 21, 2027. ISTQB lists the Certified Tester Foundation Level as a prerequisite. Its v2.0 examination has 40 questions worth 44 total points, a passing score of 29 points, and a 60-minute standard duration, with additional time provided under the applicable non-native-language rule. These details should be confirmed with the chosen exam provider when registering. The focus here is testing an AI-based system. Using an LLM to help write test cases is a related but different professional activity covered by CT-GenAI.

Define AI quality before choosing a test technique

For deterministic software, a requirement may specify that an invalid postal code must return a particular error. A probabilistic classifier cannot usually be assessed solely by matching one exact answer for every possible input. Teams must first define what level of performance is acceptable for the intended application and the people affected. For an image-classification model that flags defective manufactured parts, the cost of missing a dangerous defect may be much greater than the cost of sending a harmless part for manual inspection. Test objectives should reflect that asymmetry rather than maximize a convenient single metric.

The CT-AI syllabus discusses quality characteristics of AI-based systems, including concepts associated with ISO/IEC 25059. Functional suitability remains important, but it needs to be considered alongside robustness, reliability, explainability, fairness, human oversight, safety, and security where relevant to the use case. Explainability is not always a matter of displaying the model's internal computation. A useful operational explanation might identify which evidence influenced a recommendation, the level of uncertainty, and the escalation path for a human reviewer. A system can be accurate on average and still be unsuitable for deployment if its failures cannot be detected or safely corrected.

Translate those characteristics into observable acceptance criteria. For a medical triage assistant, criteria may include clinician review for specified high-risk cases, minimum recall on validated emergency examples, performance across appropriate population segments, clear statements of uncertainty, and documented escalation when inputs are incomplete. Accuracy thresholds and test populations must be approved by qualified stakeholders; they are not universal values supplied by a certification. Acceptance criteria should also identify which behaviors are prohibited, such as citing nonexistent medical references or asserting a diagnosis beyond the system's intended purpose.

The central difficulty is the test oracle: the basis for deciding whether an output is correct. Many AI tasks have no single universally correct output. Teams can use expert-labeled cases, properties that should remain invariant, reference implementations, paired comparisons, and graded quality rubrics. Each oracle has its own limitations. Expert labels may disagree, and benchmark datasets may be unrepresentative. Testers should make those limitations explicit before treating a score as definitive evidence of quality.

Examine data quality, splits, and representation

Machine-learning quality depends fundamentally on input and training data. A model can appear sophisticated while learning an accidental relationship, such as hospital identifiers correlating with a target label. Testers therefore need to understand the difference between training, validation, and test datasets and why independent evaluation data matters. Using the same patients, devices, or near-duplicate documents across training and evaluation partitions can make performance look higher than it would be in the field. Random splitting alone is not always enough when observations are correlated over time or by customer.

Input-data testing considers format, range, missing values, outliers, duplicate records, label consistency, provenance, and whether the distributions match real deployment conditions. A sensor-monitoring model trained entirely on well-maintained devices may perform poorly when older equipment produces intermittent readings. Data pipelines should validate schema and units, preserve meaningful metadata, record transformations, and expose failed data-quality rules before corrupt examples silently enter training or inference. When labels come from human annotators, review ambiguity and inter-annotator disagreement rather than assume each label is ground truth.

Representativeness is not simply achieving equal counts for every group. Some conditions are rare but safety-critical; others are common only in particular environments. Design samples that cover operational conditions, plausible edge cases, underrepresented populations, and expected seasonal or geographical change. Determine which sensitive characteristics may lawfully and ethically be processed for fairness evaluation. If a team cannot measure a potential disparity directly, that uncertainty should appear in its risk assessment rather than disappear from the test report. The discussion of responsible AI and governance provides additional context for turning these concerns into operational controls.

Version control should extend beyond application code to data definitions, feature extraction, labeling rules, test partitions, model artifacts, and evaluation scripts. Reproducing a reported result requires knowing which combination was used. A model that passes a regression suite with one preprocessing library version might change under another. Data lineage is therefore a practical testing capability, not merely documentation for a data science team.

Interpret model metrics in relation to the decision

CT-AI expects candidates to reason about machine-learning performance, particularly classification. A confusion matrix separates true positives, false positives, true negatives, and false negatives. From these counts, precision answers how often a positive prediction is correct; recall answers how many actual positives are detected. Specificity measures the proportion of actual negatives correctly rejected. The F1 score balances precision and recall through their harmonic mean, but it does not represent all costs or use cases. Class imbalance can make aggregate accuracy misleading: a model that predicts the majority class for every record may score highly while identifying none of the rare events that matter.

Threshold selection changes these metrics. A fraud detector might produce a risk score rather than a categorical decision. Lowering the alert threshold can improve recall but may create more false positives and analyst workload. Testers must ask who receives alerts, how false alarms affect customers, and whether a manual review process can handle the volume. Receiver operating characteristic and precision-recall analyses help compare thresholds, but the decision remains grounded in operational consequences and expected prevalence. There is no inherently correct threshold divorced from the product's purpose.

Averages can conceal localized failure. Evaluate by meaningful scenario, device family, language, environment, and affected user segment when these are relevant and permitted. Use confidence intervals or repeated sampling where statistical uncertainty matters. Scores on a small set should not be stated with unjustified precision. Also distinguish predictive validity from causal explanation: a feature may correlate with the outcome in historical data without being an appropriate basis for a consequential decision. The tester's task is to expose those limitations, not to convert an impressive-looking metric into an unsupported business guarantee.

Neural-network architectures and learning processes introduce further issues. A model can overfit training examples, underfit complex patterns, become unstable when its inputs shift, or rely on unanticipated shortcuts. Overfitting is not always resolved by collecting more random data; the data may need to cover neglected conditions or correct labeling errors. When a system contains multiple learned components, trace the provenance and version of each, because local component metrics do not necessarily predict end-to-end performance.

Test input, models, and the development lifecycle

ISTQB's v2.0 syllabus identifies input-data testing, model testing, and machine-learning development testing as distinct areas. At the input level, test parsers, transformations, completeness, schema changes, and invalid or unexpected records. At the model level, examine performance and robustness against carefully designed cases and relevant distribution shifts. During ML development, test repeatability, experiment controls, deployment packaging, approval gates, and the transition from offline evaluation to production monitoring. These activities interact but they catch different kinds of errors.

Conventional boundary-value analysis remains useful when fields have defined limits, but AI systems also benefit from transformations whose expected effect can be reasoned about. Metamorphic testing checks relationships between outputs when inputs are changed in controlled ways. If an image classifier should be insensitive to small changes in lighting, a set of images with realistic exposure changes should produce acceptably stable classifications. The expected relation must be justified, however: rotation may change the meaning of a handwritten digit, and a clinically meaningful symptom change must not be treated as irrelevant noise.

Adversarial robustness requires caution. A crafted image perturbation, poisoned training record, or malicious instruction might intentionally exploit the learned system. Construct authorized tests that assess whether security boundaries hold, sensitive data remains protected, and failure modes are contained. Human reviewers should not confuse a model's plausible language with permission to execute an action. Prompt injection and instruction hierarchy are especially important when language models can retrieve external content or call tools. A relevant approved article on prompt injection and LLM application security examines why untrusted input can become a security problem.

AI testing also changes the significance of regression testing. Retraining a model may improve global performance while harming a small but important cohort. Compare accepted baseline behavior with the new version, preserve high-value regression cases, and investigate meaningful regressions even if the overall score rises. Monitoring after deployment should track feature distributions, output quality where ground truth becomes available, error reports, resource performance, and signs of data or concept drift. Not every shift is harmful; testing establishes whether it affects the system's approved purpose.

Evaluate generative AI and language-model systems

Generative systems complicate the oracle problem further. A summarizer can produce several acceptable summaries, yet a single invented date can make an output unusable. Design task-specific evaluation rubrics that separate factual grounding, relevance, completeness, safety, formatting, and instruction adherence. Test with authoritative source material and check whether generated claims are actually supported by it. Automated judges can accelerate assessment but can themselves be biased or unreliable, so calibrate them against reviewed human judgments and inspect disagreements.

Non-determinism should be designed into the test methodology. Repeated runs over the same request may differ because of sampling, retrieval results, model versions, or changing tools. Instead of declaring every wording difference a defect, identify stable properties that matter. A customer-service assistant might need to preserve refund eligibility rules while allowing stylistic variation. Repeated sampling helps expose the rate of unsupported claims, policy violations, or incomplete responses; the required sample size depends on the risk and how rare the failures may be.

Retrieval-augmented generation creates a multi-stage system to test. The retrieval step must find authorized, relevant documents; the model must ground its answer in those documents; and access-control boundaries must remain effective. A correct-looking answer based on inaccessible customer records is a severe defect. Test missing sources, conflicting passages, misleading instructions embedded in documents, and failures of citations or source attribution. A good result is not simply a fluent paragraph; it is a useful answer that follows the application's trust and evidence boundaries.

When language models use tools or behave as agents, test side effects as well as text. An assistant that answers a billing question correctly but executes a duplicate refund has failed. Include authorization checks, transaction limits, human approvals, rollback behavior, and clear audit logs. Testing should cover failure during an intermediate tool call, stale external data, and ambiguous user intentions. The approved analysis of evaluating AI agents before production extends this system-level perspective.

Prepare for CT-AI through realistic test-design decisions

Consider a fictional insurance-claims classifier that flags potentially fraudulent submissions. It scores well in its original region but starts flagging an unusually high proportion of claims from a newly introduced market. A useful test investigation would check input schemas, population shift, language and document-format differences, training representation, feature leakage, and classification thresholds. It would also compare false positive and false negative consequences and verify that claim specialists can challenge recommendations. Simply increasing the training dataset or announcing that accuracy remains above a target would be an inadequate response.

Map each learning objective to a test artifact. For data testing, create a dataset risk register and examples of broken transformations. For classification, calculate confusion-matrix metrics by hand and explain their consequences. For model testing, describe meaningful invariants, edge cases, and threat scenarios. For ML development testing, show how versioned artifacts, regression gates, and monitoring combine into a release decision. For generative AI, practice writing acceptance criteria that tolerate legitimate variation but reject harmful or fabricated output. The official syllabus and sample questions should guide priority, not generic software-testing flashcards.

A professional considering CT-AI should already understand core test-design principles from ISTQB Foundation Level. Knowledge of ML workflows, such as those encountered by a Professional Machine Learning Engineer, can also help interpret what a model team actually changes during training and deployment. Yet CT-AI remains a testing qualification, not a requirement to become a data scientist or train production neural networks independently. The important capability is making justified, measurable quality decisions amid uncertainty, changing data, and probabilistic outputs.