Model-Based Testing: Stop Writing Test Cases Manually

What Is Model-Based Testing?

Model-based testing (MBT) is a software testing approach where a formal model of the system's expected behavior is used to automatically generate test cases. Instead of writing tests manually, testers create a model such as a state machine, activity diagram, or decision table, and an MBT tool derives the test cases from it.

The model represents the system in a structured form by defining states, actions, transitions, and expected outcomes. Once validated against requirements, the MBT tool generates test cases based on selected coverage criteria.

Unlike traditional testing, where coverage depends on the tester's interpretation, MBT provides systematic, repeatable, and traceable test coverage through the model itself.

MBT is most effective for systems with state-dependent logic, such as booking flows, approval workflows, e-commerce checkouts, and banking transactions.

For simple CRUD interfaces, linear workflows, or exploratory testing, manual testing remains faster and sufficient. The upfront cost is model creation; the return is systematic coverage, direct requirement traceability, and lower maintenance when requirements change.

Benefits and Limitations of Model-Based Testing

MBT delivers automated, repeatable, and traceable test generation that excels at validating complex, state-dependent systems, but it demands upfront modeling effort and ongoing maintenance.

Model-based testing (MBT) offers systematic and automated test generation, making it highly effective for validating complex systems with state-dependent behavior. However, it also requires significant upfront modeling effort and careful maintenance to ensure accurate and reliable test coverage.

Benefits of MBT

MBT improves software quality by enabling automated, repeatable, and traceable testing based on system models and defined coverage criteria.

• Automated test case generation: MBT automatically generates test cases from the model, reducing manual effort and improving efficiency.
• Systematic bug detection: It helps identify software bugs that appear only after specific sequences of actions or state transitions.
• Requirement traceability: Tests are directly linked to requirements, making coverage easier to track and audit.
• Lower maintenance overhead: When requirements change, updating the model allows tests to be regenerated instead of manually rewritten.
• Improved software quality: MBT is one of the most effective software testing strategies for systems with complex state logic because coverage decisions are systematic and repeatable.

Limitations of MBT

Despite its benefits, MBT can be time-consuming to implement and may become difficult to manage for highly complex systems with large state spaces.

• High upfront effort: Creating and validating models requires significant initial time and expertise.
• Coding complexity: Guard conditions and advanced behaviors often require additional coding in many MBT approaches.
• Model dependency: If the model does not accurately represent the system, the generated tests will also fail to detect software bugs correctly.
• State space explosion: Large systems with too many states can make models difficult to manage and test efficiently.
• ROI varies by project size: MBT provides the best return for complex, long-lived systems, while simpler or short-lived features may not justify the modeling cost.

How Model-Based Testing Works: Step by Step

Model-based testing works by defining requirements, building a formal model, validating it, then automatically generating, annotating, executing, and maintaining test cases from that model.

MBT spans the full Software Development Life Cycle (SDLC); the model is created during requirements definition, validated before development begins, and maintained as a living artifact through every change cycle.

The seven steps below apply regardless of which MBT class you use.

• Define requirements: Gather the functional specification for the system or feature. This feeds the test plan and determines the scope of the model.
• Create the model: Build a state machine, activity diagram, or decision table that represents the system's expected behavior.
• Validate the model: Review it against requirements with domain experts before generating any tests. An unvalidated model produces wrong tests systematically.
• Generate test cases: Apply a selection criterion such as all-transitions or all-transition-pairs to produce a test case from the model.
• Add expected outputs: Annotate generated tests with assertions and expected values from the requirements.
• Execute and analyze: Run the generated test suite and compare the actual results with the expected behavior defined in the model and requirements. If a test fails, the model path helps identify the exact sequence of actions that caused the issue. For UI-based systems, visual regression testing can also detect layout or rendering changes that functional assertions may not capture.
• Maintain the model: Update the model when requirements change and regenerate tests. Changes flow from the model to tests, not directly to individual test cases.

The Three Classes of Model-Based Testing

The three classes of model-based testing are stateless, stateful, and action-state, each trading off coverage power, setup complexity, and reliability of state-dependent bug detection.

There are many MBT methods, and the choice between them is not obvious from the tool marketing alone. A practical classification based on efficiency and usability in test automation separates them into three distinct classes: stateless, stateful, and action-state (aggregate).

Each class makes different trade-offs between coverage power, setup complexity, and reliability of bug detection.

Stateless Model-Based Testing

Stateless MBT models business processes by describing the dynamic aspects of a system without representing its internal states. The models capture user actions, events, and system responses, but not the conditions the system is in when those actions happen.

Common modeling notations in this class include BPMN (Business Process Model and Notation), UML activity diagrams, and use case flows.

All have different visual syntax but represent similar information: what happens, in what order, with what branching conditions.

Most commercial MBT tools, including CA Agile Requirements Designer (now offered by Broadcom) and Curiosity, apply this technique.

How the Stateless MBT Generates Tests

Any stateless model can be transformed into a directed graph where edges represent user actions and nodes represent system responses.

A test generation algorithm traverses this graph according to a selection criterion, typically edge coverage or all-transition-pairs, and produces test sequences from the paths it finds.

The approach is straightforward and broadly applicable. For systems where internal state does not affect the correct output, stateless MBT is efficient and practical.

Limitations of the Stateless Approach

Two significant issues arise when stateless MBT is applied to systems with complex internal logic.

• Infeasible paths: Stateless models can generate invalid test paths that are not possible in real workflows. Preventing these paths often requires guard conditions and additional coding.
• Missed state-dependent bugs: Stateless MBT cannot effectively detect bugs that only appear after specific sequences of actions because it does not track the system's internal state.

Worked Example: A Vehicle Rental System

To make these trade-offs concrete, consider the following requirement specification for a rental company that loans cars for EUR 300 per week and bikes for EUR 100 per week.

The following requirements are labeled as R1, R2, R3, and so on, where each label represents a specific functional requirement in the system specification.

• R1 – The customer can add cars or bikes one by one to the rental order.
• R2 – The customer can remove cars or bikes one by one from the rental order.
• R3 – If the customer rents vehicles for EUR 700 or more, they can rent one bike for free. Specifically:
  • R3a – If the customer has already selected bikes, one of them becomes free.
  • R3b – If the customer has no bikes selected, one free bike is added automatically.
  • R3c – When the discount is withdrawn and given again with no new bikes added, the customer gets the previous discount back.
  • R3d – When the discount is withdrawn and new bikes are added, the next discount makes one of them free.
• R4 – If the customer removes vehicles such that the total drops below EUR 700, the free bike is withdrawn.

The stateless model represents user actions as transitions (edges) and system responses as nodes. From the initial node, the customer can either add a car or add a bike, and the model branches further when the discount threshold is reached.

At first glance, the model appears complete because every valid add/remove sequence can be traversed in the graph. However, the stateless approach contains a critical limitation: it cannot accurately represent the system's internal state.

The infeasible path problem: The graph permits a path of add car, then deleting two cars. This is invalid because you cannot delete cars that do not exist, yet no node in a stateless model represents "how many cars are currently in the cart." Without guard conditions like number_of_cars >= 1 applied to delete transitions, the model generates invalid tests.

Adding these guard conditions requires code:

number_of_cars >= 1    // guard for "delete car" transition
number_of_bikes >= 1   // guard for "delete bike" transition

And the state variables must be maintained:

number_of_cars++   // on "add car"
number_of_cars--   // on "delete car"

The missed bug: Even with guard conditions applied and the all-transition-pairs criterion selected (which requires covering all adjacent edge pairs), the stateless model still fails to detect a real bug. The correct test sequence is:

• Add vehicles until the discount threshold is reached (EUR 700 or more).
• Remove vehicles until the discount is withdrawn.
• Add vehicles again to confirm the discount returns correctly.

This sequence requires the system to be in a specific internal state (discount previously granted, then withdrawn).

The stateless model's all-transition-pairs criterion does not mandate this sequence because it has no concept of the internal state that makes step 3 different from step 1.

Even strengthening the criterion to all-transition-triples does not reliably detect this bug, because the relevant pair is buried within a longer sequence that the criterion does not prioritize.

Conclusion for stateless MBT: It is broadly applicable and the most widely used approach. For systems where internal state does not affect correctness, it works well. For systems with discount logic, approval workflows, cart management, or any feature where the correct output depends on what happened earlier in the session, it will consistently miss a class of important bugs.

Stateful Model-Based Testing

Stateful MBT solves the core limitation of the stateless approach by explicitly representing the internal states the system can be in.

Rather than modeling only what happens, stateful MBT models what conditions the system is in at each point, which makes state-dependent bugs detectable by construction.

The challenge of stateful MBT is state space reduction. A real software system has an enormous number of possible states: every combination of every variable's value is technically a distinct program state.

Modeling all of them produces thousands of nodes and millions of test cases. The practical solution is to model only the inner states, or test states: the distinct conditions that actually affect the correctness of the outputs you care about.

Tools implementing stateful MBT include Opkey and Conformiq, which support state transition modeling with automated test case generation.

Identifying Inner States

Inner states are the conditions that change what the correct output is. For the rental system specification, there are five meaningful inner states:

• No discount, no bike: The customer has not yet reached EUR 700 and has not added any bikes.
• No discount, bike included: The customer has not reached EUR 700, but has bikes in the order.
• Discount, bike added: The customer has reached EUR 700, and a free bike was added automatically (R3b).
• Discount, bike converted: The customer has reached EUR 700, and one of their existing bikes became free (R3a).
• Stop: Terminal state.

These five states represent the complete set of conditions that determine what the system should do next. Every other variation, such as exactly how many cars or the total price, is handled through guard conditions rather than additional states.

The Stateful Model in Action

The state transition graph places these five states as nodes and the user actions (add car, add bike, delete car, delete bike) as labeled edges between them. The minimum test coverage requirement, that each state is visited at least once, guarantees the discount is tested, because reaching "Discount, bike added" or "Discount, bike converted" requires traversing the discount threshold.

More importantly, using the all-transition-pairs criterion generates the exact test sequence that the stateless model missed:

Add vehicles to reach the discount.
Remove vehicles until the discount is withdrawn.
Add vehicles again to confirm the discount returns.

This sequence appears naturally in the stateful model because the transition from "Discount, bike added" back to "No discount, no bike" (via delete actions), followed by a return to "Discount, bike added" (via add actions), is a pair that must be covered. The criterion forces it.

Why Does Stateful MBT Still Require Coding?

The improvement in bug detection comes at a cost. Guard conditions in stateful MBT are more complex than in the stateless approach because the graph must distinguish valid transitions between specific states.

For example, the guard condition for the "add car" transition that returns from "No discount, no bike" back to itself (rather than moving to a discount state) is:

total_price + 300 < 700

This requires computing the total price, which is itself a function of the current cart contents. The model must encode business logic that is also being tested. A mistake in the guard condition produces a test that validates incorrect behavior.

This is the primary practical risk of stateful MBT. The more complex the system, the harder it is to write guard conditions correctly.

For systems with no meaningful inner states, such as simple CRUD interfaces and linear workflows with no conditional logic, stateful MBT adds complexity without adding value. The stateless approach is the better choice for those systems.

Conclusion for stateful MBT: It reliably detects state-dependent bugs that stateless MBT misses. It is the correct choice for systems with meaningful internal states: booking systems, e-commerce checkouts, approval processes, and any workflow where the correct response depends on what the user has done previously.

The trade-offs are higher model creation effort, the need to encode expected outputs in guard conditions, and the risk of errors in those conditions.

Action-State Testing: The Third MBT Class

Both stateless and stateful MBT have complementary strengths and weaknesses. Stateless MBT is broadly applicable but misses state-dependent bugs. Stateful MBT detects those bugs reliably but requires significant modeling effort and guard condition coding that is itself error-prone.

Action-state testing, also referred to as aggregate MBT or two-phase MBT, addresses both sets of limitations through a two-phase modeling approach. It is the most effective of the three classes for complex systems and the approach this guide recommends as the starting point for any team building a new MBT practice.

How Does Action-State Testing Work?

Action-state testing works by combining action-based workflow modeling with explicit state tracking to improve test coverage for complex, state-dependent systems.

• Phase one – action modeling: Business processes are modeled as action sequences, similar to stateless MBT. This phase captures user actions, events, and branching logic without requiring internal state identification upfront. The action model is simple to create and validate against requirements.
• Phase two – state attachment: Internal states are identified and attached to the action model created in phase one. Unlike traditional stateful MBT, which builds the entire model around state transitions, action-state testing adds state awareness to an existing action model. This keeps the state space bounded by the action model structure and helps avoid state space explosion in large systems.

Why Action-State Testing Resolves Both Weaknesses

Action-state testing combines action-based modeling with explicit state awareness, allowing it to detect complex behavioral issues while avoiding the scalability problems of fully stateful models.

• It detects state-dependent bugs: Because internal states are explicitly represented in phase two, the test generation algorithm can create sequences that cover each meaningful state and its transitions. In the rental system example, the "discount granted" state is modeled directly, allowing the free bike bug to be reliably detected.
• It avoids guard condition complexity: Since the state model is attached to an existing action model rather than replacing it entirely, fewer and simpler guard conditions are needed. The action model constrains valid sequences, while the state model focuses on verifying behavior at each stage.
• It works for systems without clear internal states: For simpler systems where internal states are difficult to define, the action model from phase one can be used independently without completing phase two. This makes action-state testing flexible across both simple and highly complex systems.

Comparison of All Three MBT Classes

The three main classes of model-based testing differ in modeling complexity, state awareness, scalability, and suitability for different types of systems.

Recommendation: For most QA teams building a new MBT practice, action-state testing is the correct starting point. It delivers the bug detection power of stateful MBT without the guard condition complexity that makes pure stateful MBT error-prone and time-consuming to maintain.

Model-Based Testing Tools

Popular model-based testing tools include GraphWalker, Conformiq, Opkey, CA Agile Requirements Designer, Curiosity Software, and AI-native KaneAI by TestMu AI.

Choosing the right tool determines how much of your MBT practice is codeless, how well it integrates with your existing automation stack, and how much maintenance effort the model requires over time.

1. GraphWalker

GraphWalker is an open-source, Java-based MBT tool that reads models in the form of directed graphs and generates test paths from them. It is the most widely used open-source MBT tool and has active academic and industrial adoption, including work presented at the 2025 IEEE International Conference on Software Testing, Verification and Validation Workshops.

• Model format: Directed graphs (nodes as states, edges as actions) created in yEd or GraphWalker Studio.
• Test path generation: Supports multiple stop conditions, including edge coverage, state coverage, and time-based limits.
• Integration: Connects to Selenium, Appium, JUnit, and REST-based test runners.
• MBT class: Primarily stateless, with support for stateful models through vertex and edge scripting.
• Best for: Teams with Java/JVM automation stacks who want open-source MBT with active community support.

2. Conformiq

Conformiq is an enterprise-grade MBT tool supporting multiple modeling notations, including finite state machines, statecharts, and decision tables. It provides automated test script generation in multiple output formats.

• Model format: UML statecharts, finite state machines, decision tables.
• Test generation: Automated, with coverage criteria configuration.
• Output formats: Java, C#, Python, and proprietary script formats.
• MBT class: Stateful, with strong support for complex state logic.
• Best for: Enterprise teams in regulated industries (automotive, healthcare, banking) that need formal model validation and multi-notation support.

3. Opkey

Opkey is a low-code MBT and test automation platform with particular strength in ERP and enterprise application testing, including Salesforce, SAP, and Oracle. It implements stateful MBT through a visual model builder that non-engineers can use.

• Model format: Visual flow builder, low-code interface.
• Test generation: Automated from visual model, supports stateful logic.
• Integration: Native connectors for Salesforce, SAP, Oracle, ServiceNow.
• MBT class: Stateful, low-code.
• Best for: Enterprise QA teams testing ERP and CRM applications who want MBT without requiring automation engineering expertise.

4. CA Agile Requirements Designer (Broadcom)

CA Agile Requirements Designer is a stateless MBT tool based on BPMN process modeling. It generates test cases from business process models and integrates with ALM and test management platforms.

• Model format: BPMN activity diagrams.
• Test generation: Automated from process flows, with constraint support.
• Integration: HP ALM, JIRA, and major test management software platforms.
• MBT class: Stateless.
• Best for: Teams already using BPMN for process documentation who want to derive test cases from existing models.

5. Curiosity Software

Curiosity combines model-based test design with test data automation. It uses decision tables and stateless flow modeling to generate tests and pairs them with synthetic test data generation.

• Model format: Decision tables, visual flow models.
• Test generation: Stateless, with strong test data generation capabilities.
• Integration: Connects to major CI/CD and test management tools.
• MBT class: Stateless.
• Best for: Teams where test data complexity is as significant a challenge as test case design.

6. KaneAI by TestMu AI (Formerly LambdaTest)

KaneAI by TestMu AI (formerly LambdaTest) is a GenAI-native testing agent that applies model-based testing (MBT) principles through natural language-driven test generation and intelligent workflow analysis. Instead of requiring teams to manually create and maintain explicit models, KaneAI derives workflows, state transitions, and coverage paths from plain-language requirements to enable AI test automation for modern quality engineering teams.

• Model format: Natural language requirements with AI-generated workflow and state-aware test flows.
• Test generation: AI-powered automated test creation with intelligent coverage analysis.
• MBT approach: Applies action-state testing principles through AI-guided path and state transition generation.
• Enterprise workflow automation: Supports AI end-to-end testing for enterprise platforms such as Salesforce, Oracle, SAP, ServiceNow, and Workday by validating complex workflows, approvals, permissions, and state-dependent business logic.
• MBT class: Applies action-state testing principles through AI-guided workflow and state-transition generation.
• Best for: Teams looking for the coverage benefits of model-based testing without the overhead of manual model creation and maintenance.

Model-Based Testing in CI/CD and Agile Workflows

Model-based testing integrates directly into Agile and CI/CD workflows when the model is treated as a living artifact updated alongside requirements in each sprint.

The most effective pattern updates the model during sprint planning, regenerates tests before development begins, and version-controls the model alongside the codebase.

On the CI side, MBT-generated tests are standard test cases that plug into any automation testing platform your team already uses.

When a pull request touches a feature covered by the model, the updated model regenerates the affected tests automatically, and results feed into your test management software with each failure traceable to the specific model path that triggered it.

For scale, connecting MBT-generated tests to a test automation cloud provides parallel execution across environments without infrastructure management.

This connects MBT directly to shift-left testing principles: Quality Assurance (QA) validation starts at the model level during requirements definition, not after development completes.

AI and Model-Based Testing in 2026

The most significant development in MBT practice in 2026 is the convergence of large language models with model-based test generation.

This convergence is reducing the primary cost of MBT, specifically model creation, while expanding its applicability to teams without formal modeling expertise.

AI-assisted Model Creation

Creating an accurate, validated model has historically been the skill bottleneck in MBT adoption. Translating natural language requirements into a formal state machine or activity diagram requires expertise in both the domain and the modeling notation.

Large language models are now capable of generating initial MBT models directly from requirement documents. Given a set of user stories or functional specifications, an LLM can produce a draft state transition graph, identify candidate inner states, and suggest guard conditions for the identified transitions.

The result is not a production-ready model. Domain expert review and validation remain essential, but it reduces the time to first draft from days to hours and makes MBT accessible to teams without a dedicated model-based testing specialist.

AI-generated Guard Conditions

Guard conditions, the programmatic checks that prevent invalid paths in both stateless and stateful MBT, have been the main source of model maintenance burden. When requirements change, guard conditions must be updated manually and carefully, as errors in them produce tests that validate wrong behavior.

AI assistance in guard condition generation analyses the requirement specification and the existing model structure to suggest updated conditions when requirements change. This does not eliminate the need for human review but significantly reduces the time required and the cognitive load on the tester maintaining the model.

AI-native Test Generation as Applied to MBT

AI-native automation testing platforms like KaneAI by TestMu AI apply MBT principles without requiring explicit model creation. The system analyses the application under test, identifies state transitions through intelligent exploration, and generates tests that cover the state space systematically.

Self-healing locators adapt the generated tests when the application changes, reducing the maintenance overhead that makes traditional MBT suites brittle over time.

For teams evaluating AI for QA testing, this represents the practical convergence of MBT's coverage principles with the accessibility of AI-powered test authoring: the benefits of systematic state space coverage without the upfront model creation cost.

Agentic AI and MBT

An emerging application of MBT principles in 2026 is the use of agentic AI tools to explore application state spaces autonomously.

Enterprise AI agents embedded in CRM, banking, or service applications are increasingly automating multi-step business workflows, the same state-driven flows that MBT was designed to validate.

Agentic AI systems that navigate an application, identify distinct states, and generate test sequences covering state transitions are applying MBT logic without a human-authored model.

This is an active research and product development area with early commercial implementations already available in AI for software testing platforms.

Best Practices for Model-Based Testing

Effective model-based testing depends on choosing the right modeling approach, maintaining accurate models, and aligning test generation closely with business requirements.

• Start with the simplest class that covers your risk: Stateless MBT is sufficient for systems with no meaningful internal states. Add stateful or action-state modeling only when state-dependent bugs become a realistic concern.
• Treat the model as a first-class artifact: Store models in version control alongside the codebase and review model changes with the same discipline applied to code changes.
• Identify internal states from requirements, not code: States should represent business conditions that affect system behavior, not implementation details. Deriving states from code often creates unnecessary complexity and overly large models.
• Validate the model before generating tests: An incorrect model produces systematically incorrect tests, making issues harder to detect than ordinary test failures.

Conclusion

Model-based testing is the most systematic approach to test case design available to QA teams in 2026. It replaces subjective manual test writing with a formal model that generates coverage automatically, detects state-dependent bugs reliably, and reduces maintenance overhead when requirements evolve.

For teams starting with MBT, action-state testing is the right entry point: it delivers the bug detection power of stateful modeling without the complexity that makes pure stateful MBT difficult to sustain.

For teams running generated tests at scale, connecting MBT output to an automation testing platform with real device execution and test management integration closes the loop from model to production validation. Start testing your workflows with KaneAI and get systematic coverage without the upfront model creation cost.

Citations

• IEEE ICSTW 2025: Improving Automated Testing with GraphWalker
• (PDF) Model-Based Testing
• Model-based testing: where does it stand?