I know—it’s a pretty startling statement, especially coming from someone who’s worked in the test automation industry for nearly two decades now. But it’s the truth.
Sure, you can probably download (or sign up for) a test automation tool in less time than it takes to read this article, automate some happy paths through an API/web/mobile interface, and be “doing” test automation before the end of the day or the week. If you’re on a small team of like-minded individuals, you can probably get most or all of your team members on board, and showcase some test automation gains after a few weeks.
But then what?
Do you keep maintaining and extending test automation even once the novelty wears off, priorities shift, and team members come and go? Are all the other teams and divisions who are working on related application components aligned with what your team is doing—to the point where you can accurately assess how the latest changes impact the holistic user experience? If so, what’s keeping it all going? And if not, does your pocket of automation really help stakeholders answer the most important question for today’s highly accelerated and automated delivery processes: Does the release have an acceptable level of business risk?
RELATED CONTENT: Testing all the time
It’s becoming increasingly clear that the era of digital transformation is dramatically changing the expectations for testing. Today, speed is the new currency. Digital transformation is driving organizations to expect new functionality faster and faster—and, at the same time, customers with myriad options have grown increasingly intolerant of even the slightest glitch.
Stakeholders need near real-time insight into whether pushing each release into production will negatively impact the overall user experience and ultimately do more harm than good. Unless you have a highly advanced (dare I say “native”) microservices architecture, you cannot reliably assess the overall risk with isolated pockets of test automation. You can’t assess the overall risk without test automation tools either. With today’s ultra-compressed delivery cycles and highly complex, distributed applications, relying solely on manual testing is simply not an option.
Putting too much faith in test automation tools, though, can be just as bad as having only isolated pockets of test automation or no test automation at all. From what I’ve seen, organizations that are hyper-focused on adopting tools simply tread water longer. They don’t really progress from a process perspective. Organizations really need to tackle test automation (and the broader Continuous Testing, which is essential for Agile and DevOps) from a transformation perspective. They need to holistically make process changes to satisfy the business goals that they are being asked to achieve.
In survey after survey, you’ll find that organizations appear to be adopting test automation tools at an increasing rate. However, if you take a deep dive into their test automation success, you typically don’t see measurable process improvement or progress towards their objectives. There’s a huge difference between the idea of adopting a tool and committing to the idea of transforming a process.
Don’t get me wrong. Tools do matter. You will not succeed unless you have test automation tools that provide the specific functionality required to meet your goals. But it’s absolutely essential to realize that tools are just one piece of a large and highly complex puzzle that also involves people and processes. People need to be willing to change and they need to be comfortable with the change. But how do you prepare the people and adapt the process to enable you to get the most out of the tools you choose to adopt?
If you look at the organizations that have successfully transformed their testing processes, you will find that they have several things in common:
- The pain became so pointed that they recognized the value of changing
- A champion committed to providing the tools, access, and guidance required to get everyone—not just specific teams—to the place where they need to be
- Everyone understands exactly what’s changing and why—and what that means to them on a day-to-day basis
- They have clear, meaningful KPIs for measuring progress and celebrating success
- They collect and share internal success stories that prove change is feasible (and valuable) in the organization’s unique environment
Just like buying a new guitar isn’t going to catapult you into the same realm as your favorite musician in your favorite band, buying a new test automation tool isn’t a fast pass to a mature, sustainable Continuous Testing process. You also need commitment, alignment, training, guidance, collaboration and a framework for adapting to changing expectations and opportunities. It’s these often-overlooked elements that ultimately make all the difference between a tinkerer and a master.
