Is Automation Testing working for you?

When organizations acquire automated testing tools, the tendency I have seen is for the organization to dive in with both feet. This is very understandable and natural. Upper management is looking for immediate results because they made a capital investment. Middle management and leadership want quick relief from the burden of more test cases to run than time and resources allow. The technician or engineer is excited to have new technology, and management is looking to the technical layer to deliver on the “promise” of automation to help solve all of the problems.

All these dreams can become a reality but to do too much too soon without clear direction can be a path to failure.  However with a clear path many groups have been able to realize greater success, delivering quality product to market that wouldn’t have been possible without test automation.

There is also the potential of spending more time, more effort and more capital than maintaining a manual testing processes. The difference, in my opinion, resides in the automation framework employed and the processes supporting automation. Proper automation tooling must align with the technology being tested and feature-level functionality required for a specific working environment. Proper framework adoption addresses a complimentary business aspect, the need to fit the automation tooling to the people, the organization and the business processes.

What is an automation framework? 

There may be a variety of responses to this question. I have seen highly technical responses that express that a framework is the sum of the functions and  routines that facilitate automation script development and execution. I have heard that frameworks are an abstraction layer that structures automation design and implementation. I have been guided to see frameworks as a series of processes and practices which control the creation and running of automation assets. Which definition is right, all of them or none of them? I welcome feedback from the testing community at large…..

I suspect that the appropriate definition is subject to our personal context. In some contexts, such as leveraging JUnit as a testing framework, a technical definition is more accurate. In a more conceptual environment like the use of Cucumber as an automation framework, defining the term framework more as an abstraction layer makes more sense. When off-the-shelf packages are employed, basic or initial approaches with the tooling leveraging best practices and standards for use may serve as a process centric framework with the more technical aspects being obscured or provided intrinsically by the tooling itself.

Please argue with me. Or, please agree with me. That is the intent of this blog. Test automation is evolutionary. Your participation contributes to how this aspect of our field grows.

In upcoming blogs I hope to keep this conversation going and expand this discussion to cover topics such as what elements are considered when designing a framework for automation, types of frameworks and how automation frameworks may be applied across business roles.