ISTQB CT-MBT key terms

A testing approach in which explicit models of expected system behaviour are used to automatically derive test cases, test data, or test oracles, rather than writing all tests by hand.

An abstract, purpose-built description of selected aspects of the system under test, created specifically to support test design and evaluation, not necessarily a complete specification.

The actual software or system being tested, whose real behaviour is compared against behaviour predicted by the model.

The degree of detail a model retains or omits relative to the real system; choosing it controls which defects are visible and how many tests are generated.

How finely a model divides behaviour into states, transitions, or steps; fine granularity yields more, smaller tests while coarse granularity yields fewer, longer ones.

The automated or manual process of deriving concrete test cases, including inputs, expected results, and sequences of steps, from a test model.

A rule that decides which tests to derive or keep from a model, often expressed as a coverage target, to balance thoroughness against effort.

A measurable property of a model or code that a test suite must satisfy, such as visiting every state or traversing every transition, used to judge test completeness.

A coverage criterion requiring that every reachable state in the model is visited by at least one generated test case.

A coverage criterion requiring that every transition, that is every modelled change from one state to another, is exercised at least once by the test suite.

A coverage criterion requiring that every feasible sequence of transitions through the model, from a start condition to an end condition, is executed by some test.

A coverage criterion requiring that every decision point in a model or program evaluates both to true and to false in at least one test.

A coverage criterion requiring that each individual boolean condition inside a compound decision takes both true and false values during testing.

A graphical model showing states as nodes and transitions as directed edges labelled with triggering events, guards, and actions, commonly used to generate behavioural tests.

A model of behaviour consisting of a finite set of states, transitions between them, and the events that trigger those transitions, often extended with variables and guards.

A state machine enriched with variables, guards, and update operations, allowing compact modelling of data-dependent behaviour that a plain finite state machine cannot express.

A model with a fixed, finite set of states and transitions, where the next state depends only on the current state and the incoming input or event.

A boolean expression attached to a transition that must evaluate true for the transition to fire, enabling data-dependent branching in the model.

A tabular model listing conditions and the actions to take for each combination of condition values, useful for deriving tests for complex business rules.

A description of an interaction between an actor and the system that delivers a goal, often used as a starting model from which scenarios and test cases are derived.

A specific sequence of steps through a use case or model, typically one main flow plus alternative flows, used as a basis for test cases.

A UML behaviour diagram modelling workflows as actions, decisions, forks, and joins, from which control-flow-oriented test paths can be derived.

The Unified Modeling Language, a standard family of graphical notations including state machines, activity diagrams, and sequence diagrams that can serve as test models.

A UML interaction diagram showing message exchange between objects over time, from which tests for message ordering and interface interactions can be derived.

Business Process Model and Notation, a standard graphical language for business processes whose gateways and events can be analysed to derive process-level test cases.

A technique that models logical relationships between input conditions (causes) and output effects as a graph, then converts the graph into a decision table for test design.

A source of expected results, such as the model itself, a specification, or a reference implementation, used to decide whether observed behaviour is correct.

The relationship in which the observed behaviour of the system under test matches the behaviour predicted by the model for the same inputs and events.

Testing that checks whether an implementation behaves as specified by a reference model or standard, often by systematically comparing traces against model predictions.

A test described in terms of model-level events and states, independent of concrete implementation details, which must be refined before it can be executed.

An executable test with actual input values, steps, and expected results, produced by mapping an abstract test case onto the real interface of the system under test.

A component that translates abstract model-level events into real calls, inputs, or messages on the system under test, and maps observations back to the model level.

The supporting infrastructure of stubs, drivers, and scripts that lets generated tests run against the system under test and capture results.

Software that stores a test model, generates test cases from it according to chosen criteria, and often executes and evaluates them against the system under test.

Checking that a model faithfully represents the intended behaviour of the system, for example by review or simulation, before it is trusted as a test basis.

Checking that a model is internally consistent and well formed, for example free of deadlocks, unreachable states, or contradictory guards, independent of the real system.

An error in the test model itself, such as a wrong transition or missing state, which can produce misleading tests or mask real faults in the system.

A state in the model that no sequence of valid transitions can reach from the initial state, usually signalling a modelling error or dead specification.

A modelled situation in which the system can reach a state where no transition is enabled and no termination is intended, indicating a design or model flaw.

A sequence of transitions in a model that cannot actually be executed with any real input data, so it cannot be covered by any concrete test.

A recorded sequence of events, inputs, and resulting states or outputs produced during a test run, which can be compared against model-predicted behaviour.