February 9, 2017 // By Paul Grizzaffi
Technocracy can be loosely defined as the government or control of society or industry by an elite group of technical experts. When it comes to automation, I’ve seen technocracy in action many times in my career. It seldom ends well. I’ve even been part of the alleged technical experts: “ivory tower architects” making automation decisions based on the “best technology”. We all have to learn, eh?
What I’ve learned through this is that a technocratic approach is not a healthy way to engage in an automation initiative. Though technical expertise is important in choosing an automation technology, this expertise alone is insufficient when it comes to creating an automation initiative.
Technology is the part of an automation initiative that most of us start with…even though in most cases we really shouldn’t. I’ll grant you, it’s tempting. Technology is cool, it’s fun, it demos well to the boss. We must try to resist that sweet siren song.
So what’s the big deal? What’s the risk of starting with technology decisions? Premature decision-making. We run the risk of choosing a technology solution that limits us in some way and doesn’t meet our needs; this stems from the fact that we’ve not considered our full technological environment. Starting here also runs counter to our notion of needing business and testing goals for our automation initiative to support. Before fully engaging in an automation technology discussion, there is some information we need first.
With respect to the business goals, what is our product’s current technology stack and what is the road map for evolution? If we can answer these questions, we have a head start on our decisions. If we can’t answer them, as many organizations can’t, we need to try to future-proof our framework. This means choosing or building an automation technology that is extensible and capable of abstracting away the tooling specifics. Technologies with these capabilities allow us to add to or replace specific tools or interfaces with others that can meet our future needs.
Cross-Technology
Are we only automating web browser interaction? Are we only automating web services? Or do we need to inter-work between technologies such as these in the same test script? Perhaps it would be convenient or essential to interact with a piece of network equipment while running an automated script? Or interact with VOIP clients or mobile devices? Or…? If we need to inter-work between product interfaces, we need an automation technology that allows us to do this inter-working. Often, a single tool or technology stack doesn’t support all of the interfaces we need. In these cases, we need to consider how to provide a solution to these considerations; sometimes, using multiple tools may be the right answer…or maybe just the right answer right now.
The Ancillary Components
Automation tools and their associated scripts do not stand alone; there are other components of our corporate infrastructure with which the tools need to interact. When selecting a technology, we need to be aware of these components and how we plan to interface with them. Some of these components are:
- Results repository – the run results have to go somewhere, right?
- CI environment – if not immediately, we probably want to have automatic or scheduled runs of our automation at some point.
- License server – some vendor-supplied tools support a shared license model which usually requires a license server. Depending on where this server is located, it may limit where we can execute our automation.
At the risk of contradicting myself, forsaking all technology research until a comprehensive strategy is in place is not always the best approach. There can be benefit in sampling different technologies early in the progress. Perhaps we are not familiar with what is available in the market for automation. Maybe we’ve been locked in with a tool vendor and we need to look into what other vendors are providing or what is available via open source. Or vice versa: perhaps our open source technology is no longer appropriate for our business needs; we may need to evaluate vendor supplied solutions. Understanding the strengths and limitations of various tools, and automation in general, can help us create reasonable goals and limit unrealistic expectations.
Just beware of premature deciding and beware of being a technocrat.
Paul Grizzaffi is a Principal Consultant at Magenic. This post was republished from his personal blog and can be found here.