ISTQB CT-MBT common mistakes
ISTQB CT-MBT · Understand the traps and how to avoid them.
Treating the model as a test oracle that automatically decides pass/fail, instead of explaining that the model supplies expected behaviour and the oracle must still be derived from it or from requirements.
Candidates conflate 'model produces test cases' with 'model decides correctness', so they answer that any execution differing from the model is a defect in the system, ignoring model defects and environment effects.
What to do instead
State explicitly that the model is an abstract expectation source; the verdict requires an oracle mapping model outputs to observables, and mismatches must be triaged as system defect, model defect, or test-harness issue.
Describing model-based testing as only 'drawing diagrams before testing' and omitting its placement across the lifecycle (requirements/design models reused for test generation, test models built independently, models maintained for regression).
Study material often shows one workflow, so candidates memorize a single phase and cannot answer questions about early test design, model reuse, or maintenance-driven regeneration.
What to do instead
Learn the distinction between design/analysis models and dedicated test models, and be able to place MBT activities in planning, analysis/design, implementation, execution, and maintenance, naming what artifact is produced at each.
Choosing a notation by familiarity alone (e.g., always state machines) without matching notation expressiveness to the system characteristics, such as data-heavy behaviour, concurrency, or continuous inputs.
Candidates learn each notation in isolation and never practise the selection decision, so they miss questions that require justifying a notation against abstraction level and system type.
What to do instead
Build a comparison table of notations (state machine, statechart, decision table, activity diagram, sequence diagram, BPMN, Markov chain, grammar) keyed on what they express well, what they cannot express, and typical test-selection use.
Confusing UML state machine semantics: treating composite states, entry/exit actions, history pseudostates, and orthogonal regions as decoration rather than behaviour that changes the generated tests.
Candidates skim statechart syntax and then mis-predict transitions, so coverage questions about hierarchical or concurrent models produce wrong answers.
What to do instead
Work through small statecharts by hand: enumerate the flattened transition set, mark which transitions entry/exit actions belong to, and derive tests for shallow versus deep history and for each orthogonal region.
Reporting a single coverage number without naming the criterion, the coverage item set, and the stopping rule, e.g., claiming '100% coverage' of an unspecified model element.
Coverage terminology overlaps across criteria (state, transition, transition-pair, decision, condition, MC/DC, data-flow), and candidates substitute the label they remember for the precise item definition.
What to do instead
For every criterion, state the coverage items (states, transitions, transition pairs, decisions, def-use paths), how the percentage is computed, and what residual risk remains at 100%, then practise computing each on a small model.
Assuming full transition coverage guarantees detection of interaction or data-dependent defects, instead of arguing for stronger criteria such as transition-pair (switch) coverage, path-based or data-flow criteria when the defect class demands it.
Candidates treat coverage criteria as interchangeable quality levels and miss questions that ask which criterion is adequate for a stated defect hypothesis.
What to do instead
Link each criterion to the defect classes it can and cannot reveal, and justify criterion choice from the risk analysis and the model's structure rather than from a generic 'higher is better' rule.
Ignoring model quality review: accepting a model as correct because it parses and generates tests, without checking completeness, consistency, determinism, and traceability to requirements.
Tool-generated output looks authoritative, so candidates skip the question of whether the model itself is defective and therefore whether generated tests are valid.
What to do instead
Apply explicit model review checks (unreachable states, deadlocks, nondeterministic transitions, missing transitions, contradictory guards, requirement traceability) and state that model defects propagate into every generated test.
Treating generated test cases as ready to run, skipping the adaptation layer that maps abstract model inputs/outputs to concrete test data and executable scripts.
Candidates overlook the abstraction gap between model level and code level, so they cannot answer questions about test adapters, data binding, or why generated suites need concretization.
What to do instead
Describe the mapping explicitly: abstract action to API call or UI step, parameter domains to concrete data selection, and model output to observable check, and note where manual effort remains.
Presenting MBT as a drop-in replacement with no cost discussion, failing to address tool evaluation, model build and maintenance effort, skills, and integration with existing test management and CI.
Candidates memorize benefits (repeatability, early defect detection) without the trade-offs, so they cannot answer adoption, piloting, or ROI questions.
What to do instead
Prepare a balanced argument: upfront modeling cost versus long-term regeneration benefit, criteria for pilot selection (stable, well-specified, high-regression systems), and concrete integration points such as version control of models and CI-triggered generation.
Confusing test selection and prioritization from models with random sampling, or failing to state the selection goal (coverage of a criterion, risk-based weighting, defect-history weighting) and how the chosen subset is justified.
Candidates learn generation algorithms superficially and cannot distinguish coverage-driven generation from random or search-based approaches, nor explain why a subset was chosen.
What to do instead
For each selection approach, state the objective function, the stopping condition, and the residual uncovered items; practise explaining why a coverage-driven subset differs from a random sample of the same size.