“We don’t want your service tests. They’re too slow for our pipeline.”, said the developers. I was baffled. Just a few years earlier I had been on top of the test pyramid; then I was told “no more UI tests for you”; and now it turned out I had to go even further down the pyramid.
Designing UI tests in a waterfall project was my first encounter with test automation. At the time it was considered a progressive investment for the future. Then the Norwegian Labour and Welfare Administration did an agile pilot project. Flaky UI testing with an enterprise tool was a complete no-go. We moved on to an open source tool for API testing, and I started getting my fingers dirty writing tests. As the organisation continuously keeps improving its development practises, our need for speed increases. In my current project we are dependent on a rapid deploy capability, so we aim to minimise the time needed for regression testing by keeping the test automation at unit and component level.
In this talk I will share insights into how our test automation strategies have changed alongside our organisation. We have gone from outsourced waterfall projects to inhouse agile teams of different breeds, but the legacy remains. Some teams are fast and featherlight; others are celebrating the 40 years anniversary for their system – no one is alike. We have seen test automation tools and approaches come and go. We have seen pros and cons. But have we seen the one truth about test automation?