ISTQB CT-AI common mistakes
ISTQB CT-AI · Understand the traps and how to avoid them.
Treating "AI" and "machine learning" as exact synonyms - for example labelling a rule-based expert system or a purely symbolic planner as "not AI", or assuming every AI-based system contains a trained model.
Most public discussion of AI is really about ML, so candidates absorb a vocabulary in which the two are merged and never learn the wider taxonomy (AI as the broad discipline containing ML, which contains deep learning, alongside non-learning techniques).
What to do instead
Memorise the hierarchy AI ⊃ ML ⊃ DL and the distinguishing traits of AI-based systems (autonomy, adaptivity, self-learning, probabilistic behaviour). Practise classifying systems - rule engine, recommender, computer-vision classifier, chatbot - as ML-based or not, and note that an AI-based system also contains non-AI components.
Mixing up "testing AI-based systems" with "AI-assisted testing" - answering a question about how to test a model by describing test-generation or defect-prediction tools, or vice versa.
Both phrases contain the words AI and testing and appear in the same introductory chapter, and candidates skim the distinction as a wording detail rather than as two different subject areas.
What to do instead
Anchor the two directions explicitly: the AI system is the test object versus AI is part of the test toolchain. For each exam question, decide first which direction is meant, then answer only within that direction (e.g. oracle-problem and data-quality concerns versus coverage-selection and result-analysis concerns).
Applying quality characteristics only to the trained model and ignoring the data and the non-AI components, or treating the AI quality model as identical to the general software quality model with nothing added.
Candidates learn accuracy, precision and recall first and default to model metrics, whereas the AI quality model is defined at the level of the complete AI-based system and introduces AI-specific characteristics and refinements (for example functional adaptability, and statistical rather than binary interpretations of correctness and robustness).
What to do instead
Work through the AI quality model characteristic by characteristic and for each one ask: does this apply to the data, the model, the surrounding non-AI components, or all three? Learn the AI-specific additions and the sub-characteristics that are reinterpreted for AI, and practise writing a quality-requirement statement for each characteristic.
Describing a workflow in which the test set is used to compare model variants, tune hyperparameters, or select features - or in which the same data is used to both normalise features and evaluate the model.
Iterative experimentation blurs the stages in practice, and candidates describe what they have seen in tutorials rather than the correct separation of roles; the resulting leakage is invisible in the final accuracy figure.
What to do instead
Fix the three roles in memory: the training set fits parameters, the validation set selects hyperparameters and model variants, and the test set is held out and used once for the final, unbiased estimate. Then check any workflow description for leakage - preprocessing statistics, target information or duplicate records crossing the split boundary - and state explicitly which stage is being iterated.
Using "data drift" and "concept drift" interchangeably, or stating that a drop in production accuracy is automatically a defect rather than a signal to investigate the input distribution and the input-to-output relationship.
Both appear as "the model got worse", and the underlying distinction - a change in the distribution of inputs versus a change in the relationship between inputs and the correct output - is abstract and easy to memorise as a slogan without applying it.
What to do instead
Test yourself with concrete scenarios: same inputs, changed labelling rule = concept drift; changed input mix, stable relationship = data drift. Attach each drift type to the monitoring signal that detects it and to the resulting action (retrain, relabel, re-specify the requirement), and describe the retraining trigger rather than only the metric.
Accepting a dataset as adequate because it is large - concluding that a million records make a training or test set fit for purpose without checking representativeness, label quality, duplicates, missing values or balance across the sub-populations the system will meet.
Volume is the most visible property of a dataset and the easiest to report; bias, labelling error and coverage gaps are invisible until specifically searched for, and many candidates have never been asked to justify a dataset beyond its size.
What to do instead
Adopt a checklist for every dataset: completeness, accuracy, consistency, duplication, balance and representativeness against the intended operational population. Practise naming a specific check and its consequence - e.g. under-representation of a subgroup in the test set means the reported accuracy hides subgroup failures.
Insisting that model testing needs a single exact expected output for each input, and therefore concluding that a model cannot be tested, or writing test cases with one predetermined "correct" answer for a probabilistic system.
The expected-result pattern from conventional functional testing is the default mental model, and the oracle problem - the absence of a cheap, reliable way to know the correct output - is the hardest conceptual shift in the syllabus.
What to do instead
Learn the alternative oracle strategies and when each applies: statistical acceptance criteria on aggregated results, metamorphic relations (invariance and expected-direction properties), cross-reference oracles, human evaluation, and A/B comparison against an incumbent. For any test case you write, name which oracle you are using.
Judging a classifier on overall accuracy alone, so a model that predicts the majority class for every record is declared good on an imbalanced dataset, or a data-science metric (precision, recall, F1) is reported without tying it to the required behaviour.
Accuracy is the single number most often quoted, and candidates reproduce it without checking class balance or the relative cost of false positives and false negatives.
What to do instead
Always inspect the confusion matrix first, then justify the chosen metric from the failure cost: recall when missing a positive is costly, precision when false alarms are costly, and per-class or subgroup metrics when balance is poor. State the threshold and the acceptable trade-off explicitly rather than quoting one aggregate figure.
Assuming ML testing means only model-level tests, and assuming two runs of the same training script will produce identical weights and identical predictions.
Candidates import the idea that testing happens at the model, and they overlook that data-validation code, feature-engineering code, the training pipeline and the serving path are all testable software; non-determinism from random initialisation, shuffling, sampling and hardware parallelism is a property they have not had to reason about.
What to do instead
Enumerate the test levels for ML development - data validation, feature transformation, training code, pipeline integration, and the model - and assign at least one test type to each. For reproducibility, name the controls: fixed seeds, pinned library and hardware versions, versioned data and code, logging of hyperparameters, and tolerance-based comparison for results that cannot be bit-identical.
Evaluating generative output by exact-string match against a single reference answer, treating a hallucination as an ordinary defect to be fixed by a bug report, or proposing a few manual spot checks as a sufficient test strategy for an LLM-based feature.
Deterministic assertion is the habit carried over from classical testing, while the properties that matter for generative systems - fluency, factual grounding, safety, resistance to prompt injection - have no exact expected result and vary between runs even for a fixed prompt.
What to do instead
Use rubric-based evaluation and semantic similarity rather than exact match, with an LLM acting as judge only after the judge itself has been validated against human-labelled samples. Build a risk-based suite covering hallucination and grounding checks, prompt injection and jailbreak attempts, out-of-distribution and adversarial prompts, and regression tests on a versioned prompt set, with repetition to handle non-determinism. Keep the distinction between retrieval-augmented generation and fine-tuning clear, since the mitigation and its tests differ.