Modelling UIs

2.1 Modelling an Existing UI

This video introduces a simple customer logic screen where emails and password fields and different elements of the application get picked up from a URL, to eventually clicking on the sign-in button. Then in the Model you will see how different (user) journeys get tracked. 

UI Interfaces will at some point need testing, some will be a future concept while others evolve as requirements change. The segments consist of [1] Modelling an Existing UI. [2] Modelling a UI Concept. [3] Modelling an Evolving UI. 

2.2 Modelling a UI Concept

Modelling upfront is a key part of Test or Behaviour-driven development, from which User Stories are Generated. At which point, developers can action the User Stories to write an Application or at least produce initial Test Scenarios to test it against, or as soon as the Application is ready and available to be tested.

You'll see that much of the same logic exists as in segment 1 [Modelling an existing UI] with automation [Waypoints] used as simple placeholders now waiting for the application to be built. Also waiting for automation that can then overlaid on top of the model.

Despite the application not actually existing, at the start we lay out three blocks to explain the high level goal or high level use case of this page. In this segment [2 of 3] it considers some key differences involved in modelling a UI when the application doesn't already exist, rather than an existing one.

2.3 Modelling an Evolving UI

As a UI evolves according to requirements, a Model gives a focus for different stakeholders to collaborate within the Quality Modeller canvas. From coming in and explaining some of the most basic functionality or (User) Journeys on your App through to where a model has its different nodes Rules applied, the outcome is to embed Data ready for Automation.

The example considers the credentials as seen in segment 2 [modelling a UI concept] in which different combinations of credentials are mapped out simply as either invalid or valid. However, as this model evolves to reflect the UI’s requirements, its scope is increased. 

This includes not only the email, but also the passwords decision trees. Additionally, rule-based generation [Rules] are used on Task Blocks, essentially saying that for any instance given the logic as invalid data, will be forced down the invalid credentials route to inform Test Cases. 

The invalid password gets pushed through into a negative scenario, where we end up with a necessary error state.