The Death of Automation Part 1 - Change

As an industry, we have a fairly low project success rate, but test automation projects are often treated as disposable. What causes those projects to fail?

Agile, Continuous Integration, DevOps, Craftsmanship, Continuous Deployment. All these industry practices agree that test automation is a crucial practices for software projects. It provides fast feedback to developers of problematic changes, and ideally signals feature completion. It provides product managers data on application status to make release decisions. It makes regular regression testing mathematically feasible. It is also completely abandoned with shocking regularity, despite being a fairly expensive effort.

There are many differences between an automation product and an application product, but this may be the most crucial. Change for a traditional product is largely driven by business needs. Agile processes are specifically designed to manage projects to embrace those change drivers. In addition, some change occurs based on the technologies that underlie the project, but that is generally a lesser proportion, described as “maintenance efforts” and viewed as a distraction.

An automation product also has to adapt its implementation to each of those same business needs to automate each of those requirements. However, the changes based on underlying technology are not distractions. They are at least as major as the business requirements, because the most crucial underlying technology is the application under test. That application is changing dramatically in ways that put great pressure on the structure of the automation. If asked to base their work on a library that changed 10 times a day, most application developers would balk. For automation, that is requirement 1.

During my career, I have seen so many automation projects fail based on this reality. I have seen simple changes to an application drive so much change in the automation, the automators trying to keep up were burned out and driven completely from the field. I have watched multiple automation efforts become such a drag on application development, it gets left behind by the application until the automation becomes irrelevant and is ultimately abandoned. There are other reasons automation dies by irrelevance, but that’s another post.

Originally, agile processes realized that the ability to adapt to constant change was not inherent in projects, but required great code structure and design, excellent technical practices, and an intense focus on outstanding code quality. That kind of focus varies on current projects, but very consistently, whatever emphasis it gets on the application, it is given dramatically less weight and investment when “it is just test code.” Considering the forces of change that automation faces, that is upside-down. Automation, to be successful, need to be more focused on clean, well structured code free of any technical debt.

Automation requires an organization’s “A” game in talent and technical practice to pay off the promises to your project and business. It can either make change smooth, safe, and easy, or it can drag your project to a crawl.

Rocky Mountain Programmers Guild is offering workshop sessions that specifically target automation and the skills to make it successful. See our expanded upcoming sessions here: www.rmprogrammers.com/automate-series