ISTQB CT-MBT study materials
ISTQB CT-MBT study resources

ISTQB CT-MBT: Modeling notations and languages used for test generation

ISTQB CT-MBT · Work through your exam, one topic at a time.

All guide sections

Modeling notations and languages used for test generation

Choosing a notation

The notation must match the behavior being modeled and the automation you need. Selection drivers include the dominant behavior type (sequence, data combinations, concurrency, timing, input syntax), the formal semantics available for automatic generation, tool support, reviewer readability and team skill. A notation with precise semantics lets a generator traverse or solve the model; a sketch on a whiteboard does not.

Notation families

  • Finite state machines (Mealy and Moore) model states and transitions; extended FSMs add variables, guards and actions.
  • UML state machines and statecharts add hierarchy and orthogonal regions, which limit state explosion but must be flattened or interpreted by the generator.
  • Decision tables and cause-effect graphs capture combinations of conditions and resulting actions, ideal for business rules.
  • Activity diagrams and BPMN describe process and workflow order.
  • Petri nets express concurrency and synchronization through tokens.
  • Grammars model input syntax; data models support equivalence partitioning and boundary values.
  • Markov chains add probabilities, supporting usage-based selection.

Worked example

A discount rule depends on two conditions: member (yes/no) and order value at least 100 (yes/no). A full decision table has four rules, one per combination, and each rule yields a test case: member with order below 100, member with order at least 100, non-member below 100, non-member at least 100. Two rules may share an action, but collapsing them is safe only when the condition genuinely cannot affect the outcome. If the rule for non-members is always "no discount", the two non-member rules can collapse; if the discount amount differs, they cannot.

Traps that cost marks

  • Leaving event handling undefined (ignore, error, log) so generated tests assert nothing meaningful.
  • Using a decision table for behavior that is fundamentally sequential.
  • Adding unconstrained data variables to a state machine and creating state explosion.
  • Assuming hierarchy in a statechart removes the need to define generation semantics.