Exploring Six Types of Decisions Orgs Make When Working with Test Automation Frameworks That Often Lead to Trouble

At the same time tooling supporting test automation is tasked with discharging some unique responsibilities, the principles that set the stage for success with testing tooling closely resemble those that are equally as beneficial to first-class software solutions.

In particular, test automation frameworks carry a lot of weight when it comes to supporting/ providing access to define- and execute tests, to produce reliable test result data, and to provide scaffolding for extension and adaptation to improve coverage and reach. And as AI becomes more closely intertwined with how we deliver software, it will become increasingly important not just to be able to release with confidence, but also to be able to analyze-, evaluate-, and interact with work product with confidence.

Despite this, organizations for some reason seem to encounter very similar sorts of dysfunction when working with test automation frameworks. Ultimately it is the sort of dysfunction that presents unwelcome trade-offs related to sunken cost. This dysfunction seems to follow six types of decisions with distinct characteristics and trade-offs. If those in charge of execution and decision-making potentially understood what these decisions looked like and how they incur risk of dysfunction, perhaps they could anticipate the trouble and make decisions that better managed that risk better.

I’ve been brought in by a couple different organizations interested in resolving dysfunction in existing test automation frameworks and to build new tooling that stand a chance of circumnavigating it. I’m hosting this session to share what I see — in terms of who seems to be involved in/ affected by the dysfunction, where the dysfunction happens, and what/ how/ why organizations seem to (do to) perennially open themselves to risk.

Format: 30-ish minutes of presentation, 8-10 minutes of Q&A.

• Intermediate
• Development
• Other