Building a product model from docs and code

How it works

Testers build mental models of a product before they can test it well: what states an order can be in, who can move it between them, what data passes where. The model is given the material that describes those things — API definitions, database schemas, route files, state enums, user documentation — and asked to draft the model explicitly, as a state diagram, a role-permission table or a data-flow list. The useful output is not the diagram itself but the places where sources disagree: a state the code allows that the docs never mention, a transition the UI offers that the API refuses, a role that appears in one place only. Each disagreement is a test idea.

When to use it

When joining a product or team and needing a map faster than reading allows; on legacy systems where the documentation and the code have drifted apart; before designing state-based or permission tests; and when a feature touches several services and nobody holds the whole picture.

Limitations

The model sees what was handed to it; a state that lives in configuration, a feature flag or a third-party service won't appear. Large codebases don't fit in context, so the model works from a sample, and the map will look complete while silently missing whatever wasn't sampled. Drafted diagrams are persuasive — a clean state machine invites trust it hasn't earned — and the model will sometimes smooth over a contradiction instead of reporting it.

What you still own

Checking the model against the running product, and treating every claimed state or transition as a hypothesis until you've seen it.

Cite this