In my recent BrowserStack webinar "Finding the balance - trivago's end-to-end test strategy", I talked about the introduction of a separated test automation team at trivago. In this post, I will explain how we overcame the challenges that this setup brought with it.

The Setup

When I joined trivago as a Test Automation Engineer in 2016, I was part of the just formed test automation team. This was formed to establish and promote test automation across the company. This was a great idea that was already backed by management. So with a lot of confidence, we got to work.

In detail, we were supposed to

• Develop the test framework and pipelines
• Remove repetitive work from QA
• Support all teams using our platforms
• Improve stability and reliability of our products

This is what the team setup looked like:

So essentially, the test automation team was a newly introduced entity that sort of hovered between development and QA.

This allowed us to make some decisions which are still valid today:

• QA should write and own all end-to-end tests
• Test code should be located in the same repository as the application under test
• Test runs should be integral parts of our CI pipelines

Additionally, we hosted workshops and learning sessions for QA so they could define, write and implement all test cases and stick to our test and coding guidelines.

The Problem

The Test Automation team consisted of sofware developers only so, naturally, we were rather technology driven. First of all this is of course no problem. However, things are very different if only technological progress is considered and people and established relationships and processes are disregarded.

Since we were so focussed on providing solutions without really talking to the affected teams, soon enough we had this situation:

The development team and QA team had existed a long time before the Test Automation team and those two were used to working together. Also, the inter-team communication worked pretty well there.

However, our new team was rather detached from the established setup and felt more like the proverbial fifth wheel.

Forgetting the why

The major issue was that we never thoroughly discussed the goal of the automation project with the QA or dev deams. So it felt like the new team was sitting in its ivory tower and enforced automation on everyone.

This lead to a lot of bias on all three sides.

• QA thought the automation team wanted to turn them into developers
• Developers felt they were not being taken seriously
• The automation team thought nobody else wanted automation to happen

This is what I like to call The Triangle of Doom.

The Solution

When we realized that the whole project had almost failed, we started to talk more with the other teams. Through presentations and workshops at eye level, we were able to better communicate that test automation can have enormous advantages for all parties involved.

However, the real breakthrough came when test automation was integrated into QA in 2018.

This might seem like a straightforward thing to do but it took a lot of time to realize the potential.

• Everyone has a good understanding of the pros and cons of automation and why it is a good idea.
• As a test automation engineer I am now able to provide much more user friendly solutions that help QA instead of hinder them.
• There is a lot of mutual learning in terms of software development, exploratory testing and - last but not least - the application under test itself.

Through this new team setup we eliminated the source of bias and were able to work much closer together.

Here you can watch the whole webinar: "Finding the balance - trivago's end-to-end test strategy"