I85PREP
⌘ K
ISTQB CT-MBT study materials
ISTQB CT-MBT study resources

ISTQB CT-MBT: Model-Based Testing fundamentals and the role of models in the test process

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

All guide sections

Model-Based Testing fundamentals and the role of models in the test process

What MBT actually is

Model-based testing (MBT) derives test cases, test data and/or expected results (oracles) from a model that describes selected aspects of the system under test's expected behavior. The model is an abstraction built for testing, not the requirements document and not the source code. It can capture control flow (states and transitions), data rules (conditions and actions), or both.

Where models sit in the test process

  • Test analysis: the model is built from requirements, specifications and domain knowledge. Reviewing it with domain experts finds ambiguity and missing behavior before code exists.
  • Test design: a test selection criterion decides which tests are generated; generation is automated.
  • Test implementation and execution: offline generation produces a suite in advance; online generation selects the next step while the test runs against the SUT.
  • Reporting: coverage is measured on the model, and results are traced back to model elements.

Worked example

A bank terminal has states Idle, CardInserted, PINEntry, Authorized and Blocked. Suppose the model has eight transitions, including CardInserted to Blocked after three wrong PINs. A single chained path Idle, CardInserted, PINEntry, Authorized, Idle, CardInserted, PINEntry, Blocked, Idle visits every state and executes all eight transitions, so one test achieves 100% state and transition coverage. That does not mean the suite is strong: no test exercises a correct PIN after a failed attempt, and no transition-pair coverage is claimed. The reasoning is that coverage criteria are precise statements about model elements; satisfying one says nothing about another.

Traps that cost marks

  • Treating model coverage as code coverage. The abstraction can omit code paths entirely.
  • Building a model of valid behavior only, then expecting it to produce negative tests.
  • Forgetting that expected outputs must also come from the model, or be supplied separately.
  • Confusing the model with the specification: a valid model can still encode the wrong requirement.