1. The “Bear Dress” Story – Why Mental Models Matter
Gunesh starts with a relatable, non-technical example:
His daughter says she wants a dress with bears on it for her birthday.
In her mind: something cute and toddler-appropriate.
In his mind (after seeing options at the store): a completely different style with bears on it.
Same phrase, “dress with bears”, completely different mental models.
Why this matters for testing:
Requirements like “user should be able to update profile,” “secure login,” or “simple checkout” are exactly like “dress with bears”:
Everyone thinks they understand it.
Everyone imagines something slightly different.
When devs, testers, BAs, and stakeholders all operate on different mental models, you get:
Misaligned expectations,
Gaps in coverage,
And “but that’s not what I meant” bugs.
Key idea:
A model-based mindset is about making those mental models explicit, shared, and testable.
2. What Is a Model? “Fair & Minimal Representation” in Practice
Gunesh defines a model as:
A fair and minimal representation of the system.
Fair: realistic enough to be useful, not oversimplified.
Minimal: not every detail; just enough to reason, communicate, and design tests.
He uses two strong analogies:
Metro Map (Bangalore Metro)
The map doesn’t show exact distances, elevation, or the real geography.
It does show:
Stations
Lines
Interchanges
Parking availability
It’s “wrong” geometrically, but perfectly useful for planning your trip.
Scale Model of a Car
You can’t drive it; it’s not functional.
But it gives a visual, tangible sense of shape, proportions, and design.
In software testing terms:
Your model might describe:
States (e.g., “Logged Out”, “Logged In”, “Cart with Items”),
Transitions (e.g., “Add to Cart”, “Login”, “Checkout”),
Conditions / branches (e.g., “is premium user?”, “has valid card?”).
It doesn’t need every implementation detail—but it must be:
Accurate enough to reflect reality,
Minimal enough to be understandable and maintainable.
Main takeaway:
Treat your flows and data paths like a metro map: it doesn’t show everything, but it clearly shows what matters for navigation and testing.
3. From Story to Model: Home → Airport Example
To show how a model-based mindset works in practice, he builds a simple, almost playful model:
Scenario: Getting from home to the airport.
He starts from one simple idea (“go to airport”) and then:
Adds branches:
Are you packed?
If not and flight is today → cancel and stay home.
Are you traveling with kids?
Do flight time and sleep time clash?
Is it raining?
Are you in Bangalore?
Do you really think you’ll make it in time?
Is your spouse traveling with you?
If yes → you’re taking a cab, like it or not.
If not → maybe take an auto / bus and “enjoy the ride.”
What to notice:
A simple real-life task explodes into multiple states and branches.
That’s exactly what happens in production systems:
Feature flags,
Edge cases,
Local logic (“if in Bangalore and raining…”),
Real-world constraints.
This example shows how thinking in models automatically pushes you to:
Ask “what if?” questions,
Uncover hidden conditions,
And reveal combinations you’d otherwise miss in ad-hoc test design.
4. TestOptimal Demo – Turning Models Into Test Cases & Code
Gunesh then moves from mindset to mechanics with a demo of TestOptimal (community edition):
Getting started
Download JAR & license (via email),
Run via
java -jar TestOptimal.jar,Log in via browser,
You get a modeling IDE with:
File / Model / Run menus,
Model editor,
Generators for test case creation,
Integration with Groovy for scripting.
Home → Airport model → 8 test cases
With his simple “home to airport” flow modeled as states & transitions, he:
Clicks Generate to create test cases.
Tool generates 8 unique test paths automatically.
Each path corresponds to a different story through the model, e.g.:
“Already packed, not traveling with kids, download a movie, take the bus.”
“Not packed, flight today → cancel trip & stay home.”
Longer paths that traverse multiple conditions.
Key benefit for you:
Once the model is accurate, tests fall out of it—you’re no longer guessing which paths to invent manually.
5. State Models + BDD + Selenium + REST – All via the Same MBT Approach
He then shows how the same modeling approach extends to different testing styles:
a) BDD-style vending machine model
State model for a vending machine:
Insert coins (25, 50, etc.),
Track balance (25, 50, 75, 100, 125),
Choose drink,
Dispense and return change.
Uses:
Triggers on transitions or states (e.g.
insertQuarter,insertHalfDollar)Step definitions written in Groovy mapped to those triggers.
Runs the model:
Model generates paths,
Scripting layer drives the UI (via Selenium),
Dashboard shows executions, pass/fail, and coverage.
What to note:
Behavior is driven by the model, not by writing individual BDD scenarios by hand.
You still get clear BDD-like steps, but they’re organized around states and transitions, not just Gherkin text.
b) REST API model (insurance premium)
More complex state/data model for an insurance premium API:
Variables like age, claims, fault penalty, etc.
Dataset with multiple rows representing different combinations.
Script:
Pulls data from dataset,
Calls the REST endpoint,
Compares expected premium vs actual.
Execution:
Runs all combinations quickly,
Reports a failure when expected premium (e.g. 595) vs actual (495) mismatches.
Key point:
Whether it’s UI (Selenium), BDD, or REST, the core driver can still be your state model plus data.
6. The Gear-Shift Idea: Shaping Your Test Design Mindset
While he only briefly names it (“gear-shift model of test design”), the pattern is clear from the talk:
You shift gears in your thinking:
From ad hoc test cases → to flows & states,
From individual scripts → to models + generators,
From “did I write enough tests?” → to “does my model represent reality fairly & minimally?”
In practice, this means:
Start with a simple flow (like home → airport).
Add realistic conditions and branches.
Let the tool generate combinations.
Use execution results to refine the model, not just patch individual tests.
7. The Human Side: Traits for a Model-Based Mindset
Gunesh closes by focusing on personal qualities you need to build and sustain this mindset:
Curiosity
Ask “what if?”
Explore alternate paths and weird combinations.
You’re not just following test scripts; you’re actively learning the system.
Seeking the Truth & Asking Hard Questions
Dig into requirements.
Challenge vague statements like “dress with bears” or “simple workflow”.
Aim for a single source of truth in your model, not “whoever shouts loudest.”
Ability to Unlearn
Let go of old assumptions and habits (“we’ve always tested it this way”).
Be willing to remodel flows when the system or understanding changes.
Faith in Yourself & Your Tooling
Confidence that:
You can model the system,
Your tooling (like TestOptimal) can help generate tests,
You can iterate and improve over time.
His Matrix-style line fits nicely here:
“I can show you the door… but you’re the one who has to walk through it.”
He’s giving you an intro to MBT and mindset—but the real value comes when you actually:
Pick a real flow in your system,
Build a model for it,
And let tools generate & execute tests from that model.