--- title: "Form, Cause and Change" slug: "form-cause-and-change" description: "Test Scenarios as Subflows, which means that we can have very complex logic tied into a much simpler, understandable flow. " tags: ["Art of Modelling", "Learning Portal", "Get Started", "Test Modeller"] updated: 2024-09-27T15:06:21Z published: 2024-09-27T15:06:21Z --- > ## Documentation Index > Fetch the complete documentation index at: https://knowledge.curiositysoftware.ie/llms.txt > Use this file to discover all available pages before exploring further. # Form, Cause and Change ## 5.1 Focus Your Test Artifacts 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. [Embedded content](https://www.youtube.com/embed/g3dMlMf7dB8?&wmode=opaque&rel=0) 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 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. --- ## 5.2 Verify Your Business Logic Here 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. [Embedded content](https://www.youtube.com/embed/tlJMhADj5S0?&wmode=opaque&rel=0) 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. Within this Subflow, we see an example of a modelled decision table. In order for an item to show as 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 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. If there's a part of the system that we care less about – for example, if we go back to our main mode - 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. --- ## 5.3 Drive an Adaptable SDLC 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. [Embedded content](https://www.youtube.com/embed/3tsHxwzWpxA?&wmode=opaque&rel=0) 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, Quality 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 Quality 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. Subflows are used to quickly embed and re-use models within a master model. Subflows hide detailed or complex modelling and make the master Flow more readable. They enable scalability by building out the complexity from smaller, more step-focussed Models, rather than building giant, complex, inflexible Flows. A Model is a canvas and the Flow that is built onto it. There are several types of Model, some of which display different tabs and tools on the toolbar in Quality Modeller. Rules are conditions placed on Model Nodes of a Non-Linear Model that control whether the processing of a Flow passes through that branch. The Rules tool can be found on the Test Generation tab. When a Rule has been applied, a Rules logo appears in the Node were the rule was applied, and when that Node is selected, number appears next to the Rules button to show how many Rules have been applied on that Node. Tags are used in Models and are attached to blocks. They can be used for a range of reasons, but are most frequently used to define paths for test generation. For example, you can use Tags to define which blocks in your model are positive paths, and which are negative. Then you can use these Tags to customise the Coverage Profile for test generation for your model. Tags can be used to create a range of different Coverage Profiles and there is no limit to how many Tags a model can have. Coverage Profiles are a wrapper for Coverage settings and options. Any number of Coverage Profiles can be created as required, each with its own Coverage settings. The Coverage button is on the Test Generation tab of a Model. Quality Modeller Models come with Default Profile, User Stories and Test Cases Profiles built in. Quality Modeller is Curiosity's flow-driven model-based tool which provides a range of accelerators and connectors for building flowcharts rapidly. Align all stakeholders to quality outcomes and create critical assets early, delivering superior software at speed. Business Process Model and Notation (BPMN) is a flow-chart diagramming standard, normally used to depict end-to-end business activities. These diagrams are mostly used to show how business processes function. ## Related - [The Art of Modelling](/the-art-of-modelling.md) - [Test Case Vocabulary](/test-case-vocabulary.md) - [Modelling UIs](/modelling-uis.md) - [Model Common Understanding](/model-common-understanding.md) - [Coverage in Test Case Design](/coverage-in-test-case-design.md) - [The Art of Modelling Test Approaches](/the-art-of-modelling-test-approaches.md)