Why is it that so often I visit customers where test automation is in the hands of a few technical individuals, while the greater majority of the testing teams are bound in manual processes? While the greater majority of the users are pounding away at processing functional and regression tests, a small minority (or even an individual) is assigned to running an automated replay engine. On the surface, this seems to be counter-productive. The potential is that the individual with the automation tooling is actually exercising the vast majority of the tests using scalable solutions and running operations 24 x7, and the remaining individuals are addressing the outlying test cases. However, this is not what I have witnessed visiting companies in different markets, and with different levels of testing sophistication. I repeatedly see that the automation tools are used by specific individuals in a specialized, or niche, application within the organization.
If we, the testing team, have so many tests required (a nearly infinite number of potential test cases), why is the implementation of automation practices limited to the minority? Shouldn’t the majority of the testing team be building and maintaining automation scripts so that the efforts of each individual may be multiplied by the number of scripts that can be executed by hardware? Instead, we bind our processes so that each individuals efforts are additive to covering all test cases in a cycle manually, rather than multiplicative with automation tooling.
What is holding organizations back from more effective implementation of test automation practices? From what I witness across many organizations, the primary limitation to automation reside in vision and perspective. If we perceive a problem to be hard, we try to avoid it. But, what if this is a perception and not reality? What if we have notions that something is hard or daunting, but it turns out that our conceptualization is wrong? Test automation is fraught with these perspectives.
Here are some myths that I encounter when I visit organizations:
- Test automation practices must require a highly advanced skill set.
- A very specialized type of person must be needed to implement test automation.
- Test automation must consume an excessive amount of time to build and maintain, so only a few people can be afforded to be removed from manual testing efforts to get the automation built.
- Test automation must need highly advanced hardware.
- Test automation must be expensive.
- Applications must be so dynamic that they can’t be automated in any practical way.
In upcoming articles, I will be addressing these myths and perceptions. I would also like to add to this list. Please let me know what challenges you face when trying to apply automation to your efforts. What is holding your organization back from adopting automation strategies or approaches? Why aren’t more of your teams supplementing manual efforts with tooling?
