Writing better UI end-to-end tests

Customer focused UI tests with a TDD mindset.

150 minutes

Abstract

Our industry comes with a lot of tools to conduct UI testing from unit tests to manual end-to-end tests. However, when we inspect UI tests on projects we often find tedious and complex test code that quickly becomes unmaintainable, renders the tests unreliable, and results in more manual testing.

With this prepared exercise, attendees will practice some ideas I have taken from designing and writing code using TDD, especially around adopting customer collaboration as a way to create good UI end-to-end tests. I aim to convey a sense of value to writing UI test code following a TDD approach while keeping a focus on the customer.

I have provided software emulating a website that finds dogs that require dog-sitting. It will run on your laptop (Win, Linux or Mac). At the beginning of the session attendees will group into teams. This project will have some UI end-to-end tests, but they will be broken, so, initially, the teams won’t be able to assess the effect of their changes. There will be a set of prepared example scenarios describing what a customer should be able to do with the website. These scenarios will drive teams into fixing the UI end-to-end tests before being able to implement the customer features. The team's developer will be writing the UI test code following a TDD approach, each exercise will make it easier to implement the changes for the next exercise. Each team will go through the cycle: conversation with the customer, write BDD scenario, write code in a TDD fashion, run the UI end-to-end tests. During the exercise team members will take roles: customers, they define the features they want the website to do. Testers, they help defining scenarios with examples that describe what a customer can do. Should there be no tester in the team, then the customer takes both roles. Developers, they implement the UI test code and any code changes needed on the website.

I hope to inspire attendees to consider creating more automated tests and adhere to structured UI testing, and write test code in a way that makes it easy to change, grow and maintain, and that our test code takes the customer language into consideration. And for testers, product owners, managers and developers to collaborate more closely not only to foster individuals interaction but also to achieve working test code written in the language of the customer, regardless of the choice of framework.

Audience background

Everyone with experience working with development teams. Especially suitable for product owners, testers and developers.

Benefits of participating

I aim to convey a sense of value to writing UI test code following a TDD approach while keeping a focus on the customer by exercising customer collaboration as much as possible.

Materials provided

All exercises to follow during the session will be publicly available in GitHub. I will provide the link during the session.

Process

I have provided software emulating a website that finds dogs that require dog-sitting. It will run on your laptop (Win, Linux or Mac). At the beginning of the session attendees will group into teams. This project will have some UI end-to-end tests, but they will be broken, so, initially, the teams won’t be able to assess the effect of their changes. There will be a set of prepared example scenarios describing what a customer should be able to do with the website. These scenarios will drive teams into fixing the UI end-to-end tests before being able to implement the customer features. The team's developer will be writing the UI test code following a TDD approach, each exercise will make it easier to implement the changes for the next exercise. Each team will go through the cycle: conversation with the customer, write BDD scenario, write code in a TDD fashion, run the UI end-to-end tests. During the exercise team members will take roles: customers, they define the features they want the website to do. Testers, they help defining scenarios with examples that describe what a customer can do. Should there be no tester in the team, then the customer takes both roles. Developers, they implement the UI test code and any code changes needed on the website.

Detailed timetable

[00:00-00:10] Introduction to the first session, create teams.
[00:10-01:10] Session part 1.
[01:10-01:20] Introduction to exercice 2.
[01:20-02:20] Session part 2.
[02:20-02:30] Discussion, Feedback, Conclusions.

Outputs

I will make the exercise publicly available. There might be also a blog post based on the session and feedback I receive.

Presenters

  1. Raul Rodriguez
    Zuhlke Engineering