Automated UI tests give you confidence that whole areas of your system are playing nicely together. But they also come at a price, and it's not just that they're slower than other types of tests. Worse than that, they can also be unreliable - I'm talking about "that test," which occasionally falls over when nothing is wrong.
This flakey behaviour is by no means unique to UI tests, but they are much more susceptible to it. By definition, they are covering many areas of your system at once, meaning there's a bigger set of moving parts in which something can go wrong. Mis-fired requests, elements stealing focus at the wrong moment, variable loading times - it can be a minefield. And when a test does start acting up, diagnosing and fixing it can be even more awkward.
So what do we do? The first important step is to acknowledge that these flakes are inevitable, just as bugs in production are. By embracing failure and investing in observability, we can ensure they are as easy to diagnose and quick to fix as possible. In this talk, I will demonstrate some strategies for achieving this, as well as outline why it is crucial to do so for your team's productivity.
This Masterclass was kindly sponsored by TestRail. TestRail is a test case management platform that helps engineering teams plan, organize, execute, track their testing more efficiently. More than 10,000 teams at organizations like NASA, Atlassian, Apple, Microsoft, and AutoDesk use TestRail to manage their testing and QA at scale. Our platform is well-loved by testers and developers alike because it is fast, flexible, and easy to use. With TestRail, you can integrate with Jira (or 20+ other tools), track both manual and automated test results, and get real-time visibility into the progress of your testing. Try TestRail for free.
Comments