Model Common Understanding

Model common understanding - Clip 1 of 3. With Huw Price (Managing Director, Curiosity Software). Decision gates laid down on the Test Modeller canvas serve to generate tests. These tests are based on coverage types. 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.

Intro narration from Ben Riley, CIO at Curiosity Software:

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. We're now joined by Huw Price who's going to take you through some of the basic concepts and ideas.

You’ll meet Huw Price (Managing Director, Curiosity Software) introducing techniques that you can use to test every scenario along various paths of a mode.

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.

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 a rule; and we've created a very simple one here. So if any of these is not true, we cannot make a cup of tea.