At trivago, tech meetups are one of our favorite formats to learn and exchange knowledge. In April, we hosted the 2nd edition of the QA Meetup, which turned out to be a great success. The event attracted over 65 attendees from various roles and companies. The evening was filled with inspiring talks by several talented QA experts. Attendees were sharing insights, asking questions, and soaking up knowledge. To make things even more exciting, there was a competitive quiz that got everyone on their toes, and a magic show by one of our speakers that completely amazed the audience.

Why should you retry all tests on failure? Why not? This article will not go into details, listing pros and cons of each approach. There are already enough resources on the Web about the topic, listing valid points for both opposing views. As trivago Hotel Search frontend QA team over the last years we tried to stay away from a brute-force retry policy for failures and we rather tried to execute test retries only in selected cases. Recently, when we switched to a Continuous Deployment approach for our new frontend Web application (which empowers developers to merge and release some pull requests autonomously), we faced a greater need than before for understandable and stable test results. Due to that, showing as few “red flags” as possible for the automated checks on pull requests became even more important to ensure enough confidence in test results and to avoid slowing down the software development life cycle. The requirements and the balance between deterministic results and success ratio shifted, at least in some cases.

Meetups are one of our favourite events at trivago. They give us the opportunity to learn, share knowledge & experience, as well as network with fellow professionals and enthusiasts in the industry and community.

Over the last few years, we completely refactored what was described in our previous article about how we use the ELK stack for an overview of our test automation results, but some core concepts remain valid and applicable.

At trivago, we use a Cucumber based framework for end-to-end tests of our most important web applications. Cucumber stores test result as JSON files which can be turned into human-readable test reports.

At trivago, we are using an in-house developed Selenium framework based on cucumber-jvm to run automated browser tests. As the test suite increased (the time exceeded 45 minutes for a full run), we were looking for ways to move away from sequential towards parallel execution. For Cucumber, there are actually not that many options available: