Pilot decision: turning an architecture state machine into a generatable test model

As it stands, no. The diagram is a system model: it records how the architects intend the shuttle to behave, at whatever precision suited the design review. A test model is an artefact from which test cases, test data and expected results can be derived mechanically, so it needs an unambiguous generation interface.

Gaps, and why each blocks generation:

• Missing triggers. A transition without an event cannot be turned into a stimulus; the generator silently drops it or invents one.
• Prose guards. Guards such as 'temperature is too high' cannot yield boundary values. They must become Boolean expressions over typed variables (measured temperature, door state, elapsed timer) so that boundary and equivalence analysis is possible.
• Implicit abort/timeout. If timeout and emergency-stop behaviour is not modelled as explicit transitions, generated sequences never reach the fault paths - exactly where the field escapes are.
• No expected outputs. Entry/exit actions and observable outputs must be attached, otherwise you get stimuli without an oracle and 'pass' means nothing.
• No element identifiers. Traceability and coverage reporting both need stable IDs.

Until those are closed, generation produces structurally valid happy-path sequences through named states and is blind to timing, data and fault handling.

Scope. Pilot on the motion-controller state machine plus the lift subsystem only; leave the dispatch activity diagram for a later cycle. Keeping scope narrow is what makes a two-week budget meaningful.

Baseline. Measure against the existing 1,420-case suite, not against zero. Adoption is a comparison, not an absolute.

Metrics.

• Effort in tester-days to reach a generatable model - the dominant cost and the one most often underestimated.
• Number of generated cases and the share that can be executed automatically.
• Coverage per tester-hour versus the manual baseline (state, transition, and whatever stronger criterion you target).
• Defects found per hour, split into 'manual suite would also have caught' and 'only the model-based run caught'. The second number is the whole business case.
• Maintenance effort after the first model change, measured over the pilot window.

Stop criteria, agreed up front. If remediation consumes more than 60% of the pilot budget without a generatable model, or if generated cases add no coverage and no new defects, recommend stopping and write down the evidence. Deciding this after seeing the result invites rationalisation.

The argument contains a real risk and a false conclusion.

Real risk: if the test model is a copy of the design model and the implementation was also generated or written from that same design, then a modelling error is invisible - model and code are wrong in the same way. Defects arising from a misread requirement will not be caught. This is why the model must be validated against the requirements and reviewed by someone other than its author, and why some exploratory or specification-independent testing must continue.

False conclusion: most defects are not 'design misunderstood' but 'design not implemented correctly' - wrong guard evaluation, missing state reset, a transition firing out of order, timing violations. A model-based suite that explores transition sequences systematically hits these far more densely than a hand-written suite that repeats familiar paths. The three cases where the model will not help are model omissions, model errors and requirement errors; those need review, not abandonment of MBT.

So: keep the model, add a validation step (requirements traceability plus independent review), and do not replace exploratory testing with generated tests.