Room
Room F1+F2+F3 - Plenary
Audience
Everyone
Key-Learnings
- Sometimes creating longer workflow tests makes more sense than creating smaller independent scripts (single task).
- You can’t always clean up after yourself (unique identifiers, database resets can be painful/impossible OR you can end up relying on them)
- Standalone scripts are not always possible. Making dependencies robust and easy to debug is essential.
For some, Test Automation is a ticket to salvation: greater efficiency, more checking performed, less time ‘lost’ on testing. For others, it is the road to despair: maintenance hell, flakiness everywhere and a continuous struggle with the business to get ‘time’ for automating things. Those that were successful captured their success in strategies, principles and guidelines to guide others to the same success, or at the very least help stay away from some common pitfalls.
You’ve seen them, from the automation pyramid to page object models, the abolishment of chaintesting to the implementation of TDD and its derivatives. And while definitely useful as a perspective, there are people who have started calling some of them ‘best practices’. And that’s when both Paul and Vincent had to deal with severely raised eyebrows.
When Paul was working at Alcatel-Lucent, their “daily” automation took 47 hours to execute. The scripts had to be run across three systems to finish execution within one day. By blatantly violating a few commonly accepted automation principles, the execution time was reduced to 2.5 hours and the test coverage increased dramatically. But they were testing an entire chain, through the UI, and 2,5 hours is massive compared to how fast many of Vincent’s test suites were running! How could this be a good idea? What about the automation principles!?!
Join us at our keynote to unravel the principles of Test Automation. Discover how breaking the rules can sometimes lead to breakthroughs in efficiency and coverage, and why the context might just be king in the realm of automation.
