When to Say No to Automation - Jack Taylor
I work for a large Fin Tech company in which the higher ups base their lives on scorecards and eye grabbing headlines. "The Travel Team now have 100% Automation and have completed their implementation of DevOps!" or "We are currently at 75% automation but we hope to have 100% across all applications by the end of Q2!" are typical phrases you'll hear, but is this culture counter productive when it comes to testing?
We all know that automation is a massive part of what we do and for the most part it greatly enhances our test coverage, reduces workload and risk and increases confidence in our software. However, there are times when automation isn't required to achieve the greatest test efficiency and we find ourselves implementing it simply because we've been told to.
For example, your director wants to tell his boss that he has 100% automation coverage on all applications, but what is the point in spending 2 weeks creating a regression suite for an application that is updated twice a year on average? Perhaps rather than creating a large Selenium script base a different approach might actually be more effective, such as Exploratory testing?
This talk will look at the scenarios in which Automation might not be your best option and how you can win over a leadership group typically focused on metrics and milestones.
- How to assess if automation is the best answer to your test problems
- How to fight back on leadership when they are obssessed with buzzwords and undesirable metrics
- Different approaches to the standard regression methods