In-sprint Test Automation

Combo-Session: 30-minute Talk & 90-minute Workshop

Two-phase model-based testing makes in-sprint test automation possible

Timetable

2:45 p.m. – 4:45 p.m. Thursday 16th

Room

Room E2+E3 - Track 5: Test Automation Deep Dive

Audience

Testers, test automation engineers, test leads

Required

Laptop, Internet access, Node.js installed. Please see further instructions on the right!

Key-Learning

  • Traditional MBT methods are inapprpriate for efficient in-sprint test automation
  • Two-phase MBT can start at the beginning of each sprint
  • Attendees can use a better model-based testing after the workshop

Make Test Automation Fast and Comfortable

Traditional test automation requires coding and also requires the knowledge of the selectors. Thus it can be done when the feature for the given sprint is implemented. However, it’s too late for true in-sprint test automation. Model-based testing (MBT) seems to be a better alternative when a model can be created in parallel with the code.

In the practice, however, the model should be computer-readable and should contain everything for an application to transfer the model to executable code. Thus, the modeller should know the outputs, the selectors, when to click on a button or check a box, etc. This means that traditional modelling also requires the code to be ready, though most MBT vendors state the opposite. A sad consequence is that in-sprint test automation is rather a dream. To address this issue, we introduced two-phase modelling.

Phase I. is a high-level model that is simple, implementation-independent, and can start at the beginning of each sprint. This model consists of so-called action-state steps. Each step consists of an action, optionally one or more responses, and optionally a state. An example of this is as follows: add items at least for 15 euros => check that check out is possible STATE Going to check out is possible High-level test cases are generated from the model. These tests are human-readable, and thus can be executed by testers, business analysts, etc. but not by an application. You can see that there are no superfluous details such as clicking on a coke, etc. added.

Phase II. When the application is ready, the test cases can be executed. During the execution, a low-level model and from it the test code is generated. For example, the low-level model related to the action-state step above is as follows: add items at least for 15 euros: WHEN shopping menu item IS #selected WHEN add a coke IS #clicked WHEN add a salad IS #clicked check that checkout is possible: THEN the total price IS 15 THEN checkout button IS #active The two-phase modelling is a true shift-left solution that can be used for stateful and stateless cases. A significant part of the work is making the high-level model. When the necessary code is ready, the execution of the abstract tests is fast, that’s why the in-sprint solution is possible. The related code is 10-15 times larger than the model. It's also an efficient defect prevention solution as abstract tests are good and understandable examples.

Test automation is not only fast, but it's very comfortable as testers don't need to calculate the results in advance just check them which is much easier (similarly to exploratory testing). Finally, this method is for testers as it needs test design but doesn't need coding knowledge.

SESSION REQUIREMENTS:

To execute test cases our runner with Playwright will be used.

Operating System

  • Linux or
  • Windows 10 and above (64-bit only)

Application

  • Node.js 18.x

You can easily try test execution by reading the Quick Start guide

 

Related Sessions

8:30 a.m. – 4:30 p.m.
F-,E- & D-Rooms

Full-Day Tutorial (6 hours)

Virtual Pass session
11:45 a.m. – 12:30 p.m.
Room E2+E3 - Track 5: Test Automation Deep Dive

25-minute Talk

Virtual Pass session
10:45 a.m. – 11:30 a.m.
Room F1 - Track 1: Talks

25-minute Talk

Virtual Pass session
10:45 a.m. – 11:30 a.m.
Room E1 - Track 4: Vendor Talks

30-minute Vendor Talk