AGILE REQUIREMENTS DESIGNER8 Steps For Building Model-Based Tests

If you want to build quality applications faster, it’s time to take a close look at model-based testing.
Josh Taylor Josh TaylorJune 12, 20198 min

If you want to build quality applications faster, it’s time to take a close look at model-based testing. It’s a great way to eliminate the complex, manual effort involved in verifying whether your system behaves as expected. More importantly, tests cases and code are generated automatically based on actual requirements, using visual models that represent all or part of your system under test.

To get maximum value out of model-based testing, though, you need the right tool. One that delivers proven, modeling capabilities in-sprint that can overcome the many bottlenecks encountered with manual test design. Visual models offering clarity in requirements visibility and traceability when managing impact changes, for real time decision making and capacity planning within development teams. In today’s blog, we’ll explore the basics of modeling that such a tool will need to first address when building tests, and share a few best practices that will help you realize a wide range of important new benefits. Read on.

Building smarter model based tests

One of the first questions many people ask about model-based testing is, “Who creates the model?” There is no single answer. QA might take on model development. A high-level model might be created by a business analyst, with the development or QA team diving in to provide further process details. A cross-functional team might be convened to develop the model collaboratively and to establish a functional flow they all agree to and understand. The reality is, most anyone can take the lead which is why modeling for tests needs to be made simple.

In truth, we are creating models already, whether they are in our head, on a white board or on a computer screen. The challenge is to formalize the modeling process and use what you design to transform your testing program. Your choice of a model-based test tool must address certain key functionalities when building model-based tests and automating for test case development:

  1. Easy to understand blocks

Blocks are fundamental to model building. You need the ability to drag and drop them into place and to edit them as you create a visual model of the business logic you want to represent. There are three primary block types that your tool must support:

  • Start & End Blocks. As you open a new blank canvas to create your model, you begin with a start block and an end block. If you have multiple entry and exit points in your process flow, you set each up a start and end block.


  • Process Blocks. Process blocks are placed between your start and end points to define tasks. It might be something like “create an account,” “generate a label” or “update a record.” Though process blocks can have multiple inputs, they have just one output.


  • Decision Blocks. Decision blocks account for the various decision points in your process, whether they are central to your process requirements or at the edge of your model. A decision might be the smallest or largest bank deposit allowed, to the shipping options for product orders, or what happens when a user enters a valid or invalid entry.  
  1. Assigning a block type

While having simple set of blocks is great to help everyone understand what the model represents, there are times more information is better. This is why we need to create an attribute to define each block. An example of a decision block could be representative of a user deciding which item to add to their online shopping cart. Here, we define decision blocks as a type of ‘user interaction’. By default, your tool must to be able to change the block, to match the block type to user actions. Where you can pick out user interaction steps from the code action steps easily and at a glance.

  • User Interaction. The user presses a button or enters text in the UI.
  • Data. A data action. Examples: The system reads from or writes to disk, or makes database transactions or queries.
  • Code Action. An action or decision not observable in the front-end nor exposed in the software.
  • Infrastructure. An infrastructure event. Examples: The system is running out of disk space, network is down, CPU is idle, machine is restarting.
  • Error. The system displays or logs an error message.
  • Assert. A step that verifies whether the stated result was accomplished.
  • Service Call. The system executes a REST method, or starts or stops a service.
  1. Adding Even More Details to Blocks

There are even more opportunities to enrich your models with additional information. For example, under process blocks, you would be able to open a “process details” menu and add any number of expected results items to each block.

Here, you should be able to attach test data, automation and other useful pieces of supporting data. Your tool must allow you to go through a similar intuitive process for each decision block in capturing the decision output and expected results, such as valid or invalid, approved or rejected. If there is not an attribute which suits your needs, you should easily create your own custom field allowing even more flexibility.

  1. Making editing easy

Editing blocks must be made easy in your tool of choice. Simply double-click or right-click to change any or all the block properties, including the description, type, expected results – and more. For example, you might edit a decision block to change the output from true/false to red/yellow/blue. If you have a large model and lots of edits to make, you can select a “grid edit” and change multiple block properties from a single, tabular view. This is about editing made easy.

  1. Copy, Duplicating and Cloning

To save time whilst modelling, it’s important to re-use as much information as possible. With copy, duplicate and cloning, you have enough flexibility to re-use blocks to suit your needs.

  • Copy. A copied block starts out with the same attributes as its original. No later edits are propagated between original and copy, they are independent of one another. This is a fast way of duplicating data.


  • Duplicating. When you edit the original block, a dialog box prompts you to choose which changes you want to propagate, to its duplicates. You can edit duplicated blocks separately, but changes propagated from the original override edits made to the duplicate. This is a fast way of duplicating data, with the option to make lots of updates later.


  • Cloning. Cloning a block links the cloned block to the original block, that means, they always have the same values, except for Block Name and Expected Results. You cannot edit attributes of cloned blocks, except for Block Name and Expected Results. Changes made to the original block affect all cloned blocks. This is useful if you need to make sure these blocks are consistent.
  1. Constraints

Sometimes modelling particular events is difficult or can result in very large models. Constraints are a way to help control the flow of logic. You are able to specify complex series of events which must always be satisfied. For example, if a user logs out, they a must be re-directed to the log in page. The downside is that constraints aren’t actually seen in your model. In general, you should use them only when the same logic cannot be achieved easily by flow logic alone.

  1. Using Subflows

You should be able to make use of subflows to “componentize” large flows to reduce complexity. For example, you might establish a subflow with the appropriate set of rules for logging in or for registering a new user. This allows us to achieve re-usable assets and maintain consistency across your model.

  1. Storing Models

Lastly, your tool needs to offer a storage hub for your models so any authorized team member can check components in and out to support your Agile workflow. A file storage mechanism that’s purpose built to help development teams create and manage multiple projects across dedicated workspaces. Distributed teams must be able to rely on the tool for such a central repository to maintain, share and reuse different versions of test assets modeled from one sprint to the next.

Unlock Value of Model-Based Testing with Agile Requirements Designer

Manage for the basics in model-based testing and more with Agile Requirements Designer (ARD) – a powerful tool that development teams are using today to automatically measure and optimize test coverage. Unlike other model based testing tools that make use of a simple script-less approach that record-create tests based on code already developed, ARD addresses development teams for their in-sprint test automation needs. Start by modeling for tests based on actual requirement for visibility and traceability, where ARD manages impact changes by just simply modifying  the models built. Tests cases are maintained and updated automatically in a central repository that’s then shared across distributed teams.

With ARD, technical and nontechnical users collaborate seamlessly across the business, for a clearer, shared understanding of the truth. For more information about how to unlock new value for your organization with ARD, watch our two-part, on-demand webinar. You’ll get details and demos that show you how to create a requirements model and generate an optimal set of test cases automatically.

Take the next steps

When you’re ready, request for a trial and experience how you can use modeling to fast track your Agile testing program. You will be able to map the logical flow of your system under test and then automatically generate tests that can be used by anyone on your team. It couldn’t be simpler. Learn more at  


Josh Taylor

Josh Taylor

Related Posts