Model Common Understanding
Model Common Understanding
Article summary
Did you find this summary helpful?
Thank you for your feedback
As we continue this Art of Modelling series, it's important to understand some of the basic functionality and how Modelling defines a process, but equally it builds a common understanding of what's occurring and allows you to scope and articulate the flow of a particular process. Be mindful of decision gates and the consequences of those decision gates, overlay logic to reduce repetition and get the most out of your testing.
3.1 Scope & Articulate Flow
Decision Gates get laid down on the Quality Modeller canvas to serve the nodes to Generate Tests. These tests are based on Coverage Profiles. In this example, Test Generation results in four possible flows, which terminate in being able to make a perfect cup of tea, or not.
You’ll meet Huw Price (Managing Director, Curiosity Software) as he navigates the need to throw down a rough process flow to help articulate a series of data states as decision groups ahead of starting to visually model. This approach favours seeing the bigger picture in which test steps can be agreed, modified and refined in the model amongst all stakeholders including testers, business users, SMEs, developers, SDETS, manual testers and likely end-users.
3.2 Be Mindful of Decision Gates
What we're doing is we're putting everything, so it is visual. The reason we're doing, this is because we need to put it all into a visual representation. So once you've finished with your preliminary Model, what you need to do then is to start thinking about creating some tests or user stories.
This features ahead of the subsequent clip, which shows the use of Rules as a way of limiting the amount of possible scenarios. But equally how a mixed approach using Rules with Logic Gates can be used to inform best practice modelling when executing test steps.
3.3 Overlay Logic to Reduce Repetition
Where the previous clip introduced a fully visual model, Logic Gates though had to be repeated, which may be tricky to maintain. So Boolean states are a more embedded solution and though less overtly visualized - you have to look at the Boolean logic itself - if you're only interested in the User Stories or Test Cases, that's the way to go.
Finally, what you may find is to use a mixed approach where you're balancing the visual elements to make the model more understandable while overlaying complexity through Boolean logic states. This shows you a different way to solve the same problem, where we're going to use constraints or Boolean logic to overlay onto the model.
And what we've done is add in a new endpoint called no tea. What you'll see is that we have a little hexagon here; we have some rules to find here. Associated with each block in the Assignment we've picked up, HaveTea Yes, HaveTea No, like so; and we've done that for each of the data states. You need to go in and define Rules; and we've created a very simple one here. So if any of these is not true, we cannot make a cup of tea.
