ISTQB CT-MBT cheat sheet

Model-based testing (MBT) derives test cases, test data, and expected results from an abstract model of the system under test rather than from hand-written scripts; the model is the primary test basis.

Core MBT workflow: build the model, choose coverage criteria, generate abstract tests, concretize them into executable tests, execute, and analyze results against the model's verdicts.

Model abstraction level determines test granularity: a state machine over business states yields scenario tests; a model over internal data yields fine-grained data tests.

The model must be an independent oracle: it must predict expected outputs so generated tests carry pass/fail verdicts, not just inputs.

MBT shifts effort left: modeling defects are found during model validation, before any test executes, so cost per defect is lower than post-release discovery.

MBT complements, not replaces, experience-based testing; exploratory testing covers areas the model intentionally abstracts away.

Key MBT roles: modeler (domain expert plus tester), test generator/tool operator, and test analyst who reviews generated tests for realism.

Traceability is bidirectional: each generated test links to a model element (transition, decision, state), and each requirement links to model elements covering it.

Finite state machines (FSM) suit control-dominated systems; tests are paths from an initial state, and coverage is measured over states and transitions.

Statecharts add hierarchy, orthogonal regions, and history pseudostates, controlling state explosion while remaining directly traversable for test generation.

Decision tables model combinations of conditions and actions; each column is a test-relevant rule, and coverage counts rules exercised.

Cause-effect graphing and classification trees support combinatorial input modeling; pairwise or n-wise selection reduces the input space.

UML/SysML behavioral diagrams (activity, sequence, state machine) and MARTE timing annotations are common industrial MBT sources; OCL constraints supply data guards.

Domain-specific and formal notations (B-method, Z, Petri nets, Markov chains, BPMN) are used where precise semantics or probabilistic usage models are needed.

Action-word and keyword-driven notations (e.g., Gherkin-style scenarios) trade formal semantics for readability, so generation relies on tool interpretation of steps.

Notation choice is driven by the failure profile: data faults favor decision tables and classification trees, sequence/state faults favor state machines and sequence diagrams.

Model quality criteria: syntactic correctness, semantic correctness against requirements, appropriate abstraction level, determinism where required, and freedom from unreachable or dead elements.

Coverage criteria hierarchy for state models: all states, all transitions, all transition pairs (switch coverage), and N-switch coverage; higher N finds more interaction faults at higher cost.

Transition-based criteria include transition coverage and transition-pair coverage; path-based criteria include all paths (often infeasible) and all definition-use or all-uses paths.

Data-oriented criteria: decision/condition coverage over guards, MC/DC, and equivalence-partition or boundary coverage over model variables.

Usage-based selection: operational profiles or Markov-chain transition probabilities rank tests by expected failure intensity for reliability estimation.

Test selection strategies: coverage-minimal set, random selection from feasible paths, and risk-weighted selection where high-risk transitions get priority.

Infeasible paths arise from contradictory guards; they must be identified and excluded from the coverage denominator, not counted as gaps.

Coverage is measured on the model, not the code: 100% transition coverage does not imply code coverage, and code coverage does not imply model coverage.

Adoption patterns: pilot on one high-risk feature, then scale; incremental model slices integrated into an existing test process outperform big-bang replacement.

MBT fits regression-heavy, long-lived, or safety-related products; it fits poorly where requirements are unstable or the interface is purely exploratory.

Tool chain components: model editor, model validator, generator (with coverage and stop criteria), adapter to the test execution harness, and coverage/report analyzer.

The adapter or test harness maps abstract model operations to concrete system interfaces; it is the most common source of MBT maintenance cost.

Model maintenance must be versioned with requirements; stale models generate confidently wrong tests, so change impact analysis on the model is mandatory.

Generated test suites are often large; selection, prioritization, and minimization are needed before execution to control runtime.

Metrics for MBT adoption: model coverage achieved, generated-vs-manual test ratio, defect detection rate per model element, and generation/execution cycle time.

Standards context: MBT supports ISO 29119 test design techniques and safety standards requiring traceable, repeatable test derivation from specifications.