Form, Cause & Change

Welcome back to the Art of Modelling series. As part of this, we'll be talking about Test Artifacts. We want to discuss focusing on them, verifying business logic, driving better standards into our development life cycle. Myself (Ben Riley CIO) and George Blundell (Technical Analyst) are going talk about some of the different aspects that we need to consider here.  

So we're going to start talking about living documentation and the different decisions that affect different team members depending on the models that we build. So if we look at this from the team level, we've got different business analysts, testers, developers, that all need to work in harmony. They need to understand the requirement as to if you have a model, part of this model, we're going to be mapping out a particular User Journey, End-to-End process, a different Scenario based on whatever our team is developing. As part of that, we may have Subflows or subprocesses, which teams also need to understand, but not necessarily to the level of depth as maybe where it's come from.  

In this case, we'd refer to those Test Scenarios as Subflows, which means that we can have very complex logic tied into a much simpler, understandable flow. It gives us an End-to-End view of what needs to happen; but also when it comes to testing, we make sure that we don't miss out on those details Or we can show them if we need to, we can walk through them with different team members. But at the end of the day, we can  pull out all of the tests and Test Cases that we need at a click of a button so that we are confident in the quality that we're instilling across our model.  

As part of that, we then have Test Artifacts at a team level for different users. We've got different Test Scenarios that cover different paths, personas; different ideas that they might have to be able to test properly. So I'm going to hand it over to George who's going talk about this in much more detail, especially when it comes to verifying Business Logic. George, over to you.  

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. Choose to focus on the areas of the system and user behaviours that are most impactful to the business using a more risk-based approach.  

Here we have an example of an e-commerce website, and to illustrate a 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 shows.  

Because we care about this part of the system, we spend some time modelling out all of 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. 

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.