8 Steps For Model-Based Testing

If you want to build quality applications faster, it’s time to take a close look at model-based testing. This testing approach is 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. You need models that offer clear visibility of requirements and traceability when managing the impact of changes. This is key to enabling real-time decision making and capacity planning within development teams. In this 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.

Establishing Smarter Model-Based Testing

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 and 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 with 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, the shipping options for product orders, or what happens when a user enters a valid or invalid entry.   

2. Assigning a Block Type

While having a 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 action. Examples of a data action can be a system reading from or writing to disk, or making database transactions or queries.
• Code action. An action or decision not observable in the front-end nor exposed in the software.
• Infrastructure event. This can include a system running out of disk space, a network going down, CPU being idle, or machine 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.

3. 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 that suits your needs, you should be able to easily create your own custom field, allowing even more flexibility.

4. 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.

5. Copying, Duplicating, and Cloning

To save time while modeling, it’s important to re-use as much information as possible. With copying, duplicating, and cloning, you have enough flexibility to re-use blocks to suit your needs.

• Copying. 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 are 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.

6. 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 a complex series of events that 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. 

7. Using Subflows

You should be able to make use of subflows to “componentize” large flows, which can help 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 you to achieve re-usable assets and maintain consistency across your model.

8. 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. It’s important to have 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.