Modelling a UI

The Art of Modelling series - Modelling a UI
Go back to the index at any time to see more in the series.

2.1 Modelling an Existing UI

This introduces a simple customer login 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 and in the model you see how different (User) Journeys get tracked.

https://www.youtube.com/watch?v=NaCClnajb44&list=PLd_AqXM4vM-Bihc9Qx3Sl3pUCsC6S8XoV&index=4

Duration average: 2-3mins

A Curiosity Software series to boost foundation thinking around building out better Test Cases.

Note: No information is collected or saved. The quiz is anonymous.

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 - this] Modelling an existing UI. [2] Modelling a UI concept. [3] Modelling an evolving UI.

Back to top

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.

https://www.youtube.com/watch?v=-JFSpnla5dM&list=PLd_AqXM4vM-Bihc9Qx3Sl3pUCsC6S8XoV&index=5

Duration average: 2-3mins

A Curiosity Software series to boost foundation thinking around building out better Test Cases.

Note: No information is collected or saved. The quiz is anonymous.

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.

Back to top

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 Test 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.

https://www.youtube.com/watch?v=xOX-lK9_1KQ&list=PLd_AqXM4vM-Bihc9Qx3Sl3pUCsC6S8XoV&index=6

Duration average: 2-3mins

A Curiosity Software series to boost foundation thinking around building out better Test Cases.

Note: No information is collected or saved. The quiz is anonymous.

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.

Back to top

You’ve are following our Art of Modelling series.

Browse more Learning Portal content

Test Modeller 101 Tutorials

QuickStart Web Automation

QuickStart Mobile Automation

QuickStart Mainframe Automation