ISTQB CT-MBT flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Model-based testing definition

A testing approach in which test cases, test data, and expected results are generated automatically from an abstract model of the system under test rather than written by hand.

Test oracle in MBT

The mechanism that determines pass or fail. In MBT the model itself supplies expected outputs, so generated tests carry verdicts rather than only inputs.

Abstract test case

A test derived directly from the model, expressed in model vocabulary without concrete data or interface details. It must be concretized before it can be executed against the real system.

Concretization

The step that transforms an abstract test case into an executable test by supplying concrete input data, interface calls, and expected concrete outputs, usually via an adapter.

Model validation versus verification

Verification checks the model is syntactically and structurally sound; validation checks the model faithfully represents the intended requirements. Both precede test generation.

Shift-left effect of modeling

Because building and reviewing a model exposes requirement ambiguities early, defects are found before test execution, reducing the cost of fixing them.

Traceability in MBT

Links connecting requirements to model elements and model elements to generated tests, enabling impact analysis and coverage justification for audits.

Finite state machine model

A notation of states, transitions, events, and guards suited to control-dominated systems; tests are paths through the machine starting from an initial state.

Statechart hierarchy and regions

Statecharts add nested states, orthogonal regions, and history pseudostates to flat state machines, limiting state explosion while remaining traversable for test generation.

Decision table as test model

A table of condition combinations and resulting actions; each column is a rule and serves as a test-relevant case, with coverage counted over rules.

Classification tree method

An input-modeling notation that partitions each input into classes and combines them into test cases, often with pairwise or n-wise selection to control combinatorial growth.

Cause-effect graphing

A notation linking causes (input conditions) to effects (outputs) through logical constraints, from which decision-table-like test cases are derived.

UML state machine diagram

A widely used behavioral UML notation for MBT; transitions carry triggers, guards, and effects, and OCL constraints can specify data conditions precisely.

Petri net for testing

A formal notation of places, transitions, and tokens with precise concurrency semantics, used to model and generate tests for concurrent or workflow systems.

Markov chain usage model

A state model whose transitions carry probabilities reflecting operational usage, enabling statistically representative test selection and reliability estimation.

BPMN as test model

A business process notation with gateways and events that can be traversed to generate end-to-end process tests, especially for workflow-intensive applications.

Keyword-driven notation limits

Readable action-word or Gherkin-style steps lack formal semantics, so generation quality depends on how the tool interprets each step definition.

Notation choice by failure profile

Select notation from expected fault types: data faults favor decision tables and classification trees; state and sequence faults favor state machines and sequence diagrams.

All states coverage

A weak criterion requiring every state in the model to be visited at least once; it can be satisfied without exercising many transitions.

All transitions coverage

A criterion requiring every transition in the model to be traversed at least once by the generated test suite; the most common baseline for state models.

Transition-pair coverage

Also called switch or 1-switch coverage: every feasible pair of adjacent transitions must be exercised, exposing interaction faults between consecutive events.

N-switch coverage

A generalization requiring every feasible sequence of N+1 consecutive transitions to be exercised; higher N detects deeper interaction faults at greater cost.

Infeasible path handling

Paths whose guards contradict cannot be executed; they must be identified and removed from the coverage denominator rather than reported as uncovered gaps.

Guard condition coverage

Coverage of the boolean conditions inside transition guards, measured with decision, condition, or MC/DC criteria over model variables.

Model coverage versus code coverage

Model coverage measures exercised model elements; code coverage measures executed source statements. Neither implies the other because abstraction hides code paths.

Risk-based test selection

Prioritizing generated tests that traverse model elements associated with high failure impact or likelihood, so limited execution time targets the riskiest behavior.

Dead and unreachable model elements

Transitions or states that no valid path can reach indicate modeling defects; they inflate coverage targets and must be fixed or excluded explicitly.

Test adapter role

The component mapping abstract model operations to concrete system interfaces and data; it usually dominates MBT maintenance effort and must be versioned with the model.

Model versioning with requirements

Models must be configuration-managed alongside requirements; a stale model silently generates plausible but wrong tests, so change impact analysis is required.

Generated suite minimization

Reducing a large generated suite to a smaller set preserving the chosen coverage criterion, controlling execution time while keeping the coverage guarantee.

MBT pilot adoption pattern

Introduce MBT on one high-risk, regression-heavy feature, measure defect detection and cycle time, then scale incrementally rather than replacing the process at once.

MBT adoption metrics

Measures such as model coverage achieved, generated-to-manual test ratio, defects found per model element, and generation-to-execution cycle time indicate whether MBT pays off.