The output of most automated accessibility tests is a long list of violations. This format, while comprehensive, makes it difficult to distinguish new issues introduced in a feature branch from long-standing technical debt. It doesn’t clearly show if accessibility is improving, and it doesn't help prevent regressions.

About six years ago, our mobile automation setup was showing its age. It was a small, homegrown framework that had worked “well enough” for a long time, until we tried to upgrade Java and a few core dependencies. That’s when things started breaking in ways we couldn’t reasonably patch around. The framework simply wasn’t built to move forward.

When doing exploratory testing on a web application, the nature of activities involves discovering things and not repeating the same patterns. However, there might be aspects that could be improved by specific tools without trespassing into the realm of test automation. Can coding skills help testing activities, beyond the somewhat obvious case of automated tests? In the trivago QA team we asked ourselves this question, trying to find solutions to make some testing processes less cumbersome and save time while maximizing focus.

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.

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.

You do not run a successful, stable software project over several years without some amount of automated testing. If several dozens of developers are working on the same code base, the need for test automation becomes even greater. After all, their changes might have unintended effects on other people's code, or on certain edge cases that will not be noticed until the changes go live — and maybe not even then.

You know those bugs, like, those. Where the application state dances around you like a crazed Polynesian fire dancer. Where changing the sorting order of a search in London reverts the result list back to Paris.... Seriously? Unfortunately, a lot of us are specialists in dealing with this kind of bug.