Form, Cause and Change

Verify Your Business Logic

You cannot model everything in your target system and every single combination of user behaviour. Therefore, you must be selective with what you choose to model. Decide to focus on the areas of the system and user behaviours that are most impactful to the business, using a more risk-based approach.

In this video, we have an example of an e-commerce website, and to illustrate an approach, we can use the inventory check screen as an example. This can be considered crucial functionality, as you cannot sell an item if there is no stock available.

Within this Subflow, we see an example of a modelled decision table. In order for an item to show is available, there must be sufficient stock, and the user level must be high enough for the given stock level. What we've done is actually enforce these using a set of Rules.

So for example, if we check on our inventory available endpoint, the requirements here are for either the stock availability to be high, or if the stock availability is low, then the user level must be greater than or equal to three. This model produces a decision table, as shown.

Because we care about this part of the system, we spend some time modelling out all the possible user behaviours. On the other hand, if there's a part of the system that we care less about – for example, if we go back to our main model, we could pick up another one of these Subflows – if it's not that important, then we don't really need to model it in too much detail.

In addition, using Tags is a good way to define exactly how rigorously you want to test parts of your application. What we've done here is overlay an inventory check tag on our Subflow and in our Coverage Profile, we're actually defining that we want to exhaustively test our inventory checks Subflow. That allows you to take a much more risk -based approach to testing and verify exactly what business logic you need on your models.

Drive an Adaptable SDLC

Models that capture all the required business logic become multipurpose assets that help to drive better standards throughout the software development life cycle (SDLC). They become the central source of truth for sprint teams and a visual knowledge base for business logic, application behaviour, data rules, and the like.

As we've discussed previously in this series, Test Artifacts are generated automatically from the model. These artifacts not only include Test Cases for testers, but User Stories for developers and Test Data for SDETS. Because of this automated approach, the key to a successful software development lifecycle is to maintain that central source of truth.

Once a change occurs, map that change onto the model and regenerate the associated assets. This enables teams to react significantly faster to those changes than they could before, where previously the maintenance of test assets was often more of a manual process.

To support that process, Test Modeller has a wide range of Importers and Integrations with many tools used in software development. These range from model imports and exports of VISIO and BPMN diagrams to two-way integrations with Test Case management tools like qTest and Jira, to code repository connections with technologies like Git and Bitbucket.

All of these integrations allow Test Modeller to synchronize with your team's preferred tools and way of working to provide a platform to improve software standards and drive an adaptable software development lifecycle.

Watch More of The Art of Modelling Series