Model-Based Testing Skill: Turn states and transitions into coverage you can explain

A state model is useful when the same button means different things before, during, and after a payment. It becomes dangerous when the model quietly replaces the product rules.

Why this Skill is needed

Model-Based Testing represents system states, events, guards, and transitions so teams can generate and review paths against explicit behavior.

What the Skill does

The Model-Based Testing Skill is useful when a team needs a structured review of state, event, guard, transition, action, path coverage, invalid transition, and model drift.

Awesome QA Skills organizes Skills by language and testing stage. The series overview explains the shared installation model; this guide stays with Model-Based Testing.

A practical standard for this Skill is simple: A good model keeps the business invariant visible at every transition. It explains why a refund is allowed, not just that the state machine can reach “refunded.”

Use it when the team needs a repeatable review of state, event, guard, transition, action, path coverage, invalid transition, and model drift—especially when several evidence sources disagree or a handoff must explain what remains unverified.

What it does not do

The Model-Based Testing Skill can organize material, evidence, and next actions for Model. It does not replace:

Confirmation of rules, scope, and risk by the accountable domain owner.
A real environment, account, dataset, log, or run record; static analysis does not become runtime evidence by itself.
Authorization for release, compliance, production actions, or residual-risk acceptance.
A Human decision when supplied sources conflict.

What it checks

The value of this Skill is not another keyword list. It connects each focus area to an observable input, a judgment, and a way to close the loop. Start with a small matrix based on the source Skill’s output contract:

Focus	Question before analysis	Handoff output
Model	States, events, guards, actions, and source	Versioned artifact
Coverage	Selected paths and unrepresented risk	Basis and limitation
Model gap	Missing state, invalid transition, or drift	Owner and update

If a row has only a conventional expectation and no source or validation method, keep it open instead of turning it into a pass.

Audit inputs before you start

Before analyzing Model, classify the input into six evidence states. A gap is not automatically a failure, but it must not disappear inside the conclusion.

State	Meaning	How this Skill should handle it
known	Directly supported by the supplied material	Keep the source, version, and time with the judgment
missing	Needed for this pass but not supplied	Name the smallest evidence action and limit the conclusion
conflicting	Sources disagree	Show both sources and route the conflict to an owner
stale	Present but outside the relevant version or time window	Mark freshness; old evidence is not current proof
out_of_scope	Related but excluded from this pass	Keep the boundary explicit
assumptions	Temporarily adopted to continue analysis	State how and when the assumption will be checked

Keep the input version, scope, environment, evidence locations, and accountable owner together. Without a run record, deliver analysis, design, or a validation plan—not an execution pass.

From problem to structured Finding

Connect the source, scope, evidence state, analysis, owner, action, close condition, and validation before writing the conclusion. The case below keeps this Skill’s identifier and domain context.

Keep the decision layers separate

For Model, do not compress four different kinds of language into “recommended to pass”:

Layer	How to write it	Application here
Fact	What the supplied material directly shows	Cite the source, version, input, or run record for the focus
Evidence-backed Inference	What several facts support together	Show the inference chain and retain uncertainty
Recommendation	The smallest next action	Name the evidence, review, execution, or regression path
Human Decision	What an accountable person must decide	Leave scope, risk acceptance, resources, and release meaning to the owner

A complete case

This case follows Input, Analysis, Finding, Decision, and Validation. When material is incomplete, keep missing, conflicting, or assumptions visible instead of turning them into a pass.

Input

Material	What to provide	What to do when it is missing
State source	Requirements, events, invariants, and terminal states	Separate observed from assumed transitions
Transition rules	Guards, actions, side effects, and invalid events	Name who owns ambiguous rules
Coverage goal	State, transition, pair, path, and risk coverage	Do not call all paths complete by count

Use a request like this:

Use the model-based-testing Skill.

Task: model an order lifecycle from draft through payment, fulfilment, cancellation, and refund
Inputs: [requirements, versions, links, logs, reports, or data paths]
Scope: [included and excluded objects]
Unknowns: [missing environment, accounts, data, or permissions]
Expected output: [risk-ordered findings, evidence status, and next actions]

Audit the inputs first. Separate facts, assumptions, and open questions. Do not claim execution without a run record.

Analysis

Start with a bounded pass—model an order lifecycle from draft through payment, fulfilment, cancellation, and refund. Model a paid order that can be cancelled before fulfilment, but not after shipment. Add a compensation transition for payment reversal and mark “refund requested twice” as an invalid event with an explicit oracle.

The handoff should preserve the input version, time window, evidence index, owner, and next validation action. The Skill can organize uncertainty; it cannot manufacture the missing artifact.

Finding

Example finding: turn one problem into a handoff

The field example below shows the recording pattern; it is not an execution result.

If the supplied material cannot prove that Model meets its contract, write the finding like this. It does not invent the missing rule or turn missing evidence into a failure.

Field	Example wording
Source and scope	Record the requirement, version, environment, and the concrete object for Model
Finding	The condition or result for Model is not yet traceable to evidence
Evidence state	missing / assumptions; use conflicting when sources disagree
Impact and priority	Name the affected user, journey, or delivery decision without inflating severity
Owner and Human decision	Ask the product, engineering, security, or test owner to confirm the rule and trade-off
Action and close condition	Add the smallest missing evidence; close only when source, judgment, and owner can be reviewed
Validation	Name one repeatable check, query, or run and retain the raw artifact

The point is to let the next person walk from the finding back to the source and run an action that can change the decision.

Decision

The accountable owner confirms the decision question and risk trade-off; the Skill does not make that choice.

Validation

Before closing the finding, run the stated validation and retain the raw artifact. Without an execution record, the status remains unverified.

How a Finding enters the next stage

Handoff output

Output field	Why it exists	Example status
Model	States, events, guards, actions, and source	Versioned artifact
Coverage	Selected paths and unrepresented risk	Basis and limitation
Model gap	Missing state, invalid transition, or drift	Owner and update

Do not write “passed” without a run record, query result, or source artifact. A good model keeps the business invariant visible at every transition. It explains why a refund is allowed, not just that the state machine can reach “refunded.”

Next-stage route

At minimum, hand off the source, evidence state, owner, close condition, and validation action; the next-stage conclusion remains bounded by the evidence state.

How to prepare better input

If the first request contains only a one-line goal, keep the output limited. Add the source version, affected objects, environment, known defects, and decision owner to move from a plausible checklist to a useful review.

A richer input changes the answer here because state, event, guard, transition, action, path coverage, invalid transition, and model drift must be tied to evidence rather than inferred from a familiar pattern.

Working with other Skills

State Transition Testing:focuses on state rules and events.
Decision Table Testing:models guards and combinations.
Requirements Analysis:anchors the model in source material.

Common traps

Treating the model as the source of truth without checking requirements.
Covering states but not guards and side effects.
Leaving invalid transitions out because they are inconvenient to generate.

Install and invoke

Install the individual Skill. The series overview carries the longer installation explanation.

npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/model-based-testing -g

After installation, invoke it with the model-based-testing Skill and attach the real project material.

FAQ

Does model-based testing require a formal tool?

No. A clear, versioned model and traceable paths are useful before tool automation.

What if the model is incomplete?

Keep the gap visible, generate only bounded paths, and assign the rule owner.

The example above is a design and review pattern, not an execution result. Keep static analysis, runtime evidence, human approval, and release acceptance separate.

References

Source Skill and execution contract

The complete execution contract lives in the Model-Based Testing prompt. Read it before invoking the Skill; the prompt defines the detailed workflow and output contract. The source directory contains the entry point and supporting assets where they exist.

The entry point centers state, event, guard, transition, action, path coverage, invalid transition, and model drift. Keep its decision boundary visible and do not turn a static design into an execution claim.

Reference links

Model-Based Testing prompt:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/model-based-testing/prompts/model-based-testing.md
Awesome QA Skills: Model-Based Testing source:https://github.com/naodeng/awesome-qa-skills/tree/main/skills/en/testing-types/model-based-testing
Awesome QA Skills GitHub:https://github.com/naodeng/awesome-qa-skills
Model-Based Testing details:https://inaodeng.com/en/qaskills/model-based-testing/