Part 2: The Story
This is a hypothetical story that we will use to understand the problem and to come up with a solution during the workshop.
Introduction
Our good friend Timothy is a very happy tester. He loves exploratory testing and finding information that is valuable to the stakeholders. He strives to do his best for the project.
Credits to Josh for drawing pictures of Timothy.
Timothy currently works on a project where the team is building a book information app to give users information about books. They are currently building the website and Android app.
The Book Information App has three main screens currently:
Home page - where users can search a book
Search results page
Book details page - where additional information about the books are present
The website link is here.
The Problem
Lately, Timothy is a little sad. There are many code changes and new features that the team adds to the app and Timothy spends a lot of time doing regression testing each week. He repeats the same checks over and over again each week to understand if some things that were working earlier behave differently now after the code changes.
Since he spends so much time repeating the checks, he hardly gets time to do variations. This also means that he is not able to spend time discovering new information that could be valuable to the stakeholders. He is also tired of repeating the same kind of checks over and over again before every release.
The Goals
Timothy is a person who takes efforts to make a change when things are not working well. He sets some goals.
Less time spent repeating tests
More time to explore the products and discover unknown risks and additional valuable information
Fast and continuous feedback about the known behaviours of existing features without much involvement
He talks about these goals with the team and the team collectively decides that building a culture of test automation might help meet these goals.
Culture of Test Automation & the Gaps
All the team members understand the concept of the Test Pyramid. They understand the value of tests. They understand that unit tests are faster to run and can give quick feedback. Unit tests also can help us pinpoint an issue in code more easily as compared to the tests higher up in the test pyramid.
The developers on the team already write a lot of unit and service tests.
They identify that they currently do not have end-to-end UI tests and that is one of the gaps in testing. That's the reason Timothy spends a lot of time repeating checks every week.
So the team decides that they need to start end-to-end UI test automation.
E2E UI tests
When the team talks about end-to-end UI tests, they mean tests that represent the scenarios that users would perform on the apps. For example, in this application, one of the user journeys could be "searching for a book, selecting a book from the search results and then viewing the details of the book".
For these user journey tests, the team wants to use the apps and services in a fully integrated prod-like environment.
They also want these tests to be repeatable and scalable.
With clear understanding of the problem, the goals in mind and the solution they want to work on, Timothy starts to consider the tool that they could use for these end-to-end UI tests.