Test automation myths
I have actually expanded and refined my original ideas, so I have found it necessary to re-draft the following article to allow it to catch up to where my mind has wandered
There are quite a few myths of software test automation, here are just a small number along with a brief explanation.
Train the Test Analysts to become Test Automation Analysts! I think this line of thinking comes from a misunderstanding of the Test Analyst role. Most of work associated with this role is novel (it falls within my definition of eccentric work, rather than routine work). The main aspect of the role that is routine is test execution – a small part of the overall role. It is this routine work that is the target of automation. The Test Analyst does not need to be the person who automates tests. When I come across a traditional organisation who intend to introduce test automation, I recommend that they allow the Test Analysts to be involved earlier in the process and supply concrete examples to the programmers for automation as part of the development of the software.
Test automations as a role! I like to discourage test automation roles. The skill of test automation should be deeply embedded within a cross-functional team, just like the many other skills needed to deliver working software. The need for this skill should not be translated into a role, or a named individual, or a separate team. Each of this dysfunctions will lead to automation being performed at the wrong time and will increase the likelihood that the wrong kind of automation will be used.
100% Automation! The fundamental argument of 100% automation is a fallacy. It distracts people into discussing whether or not 100% automation is possible. The premise of any discussion on automation should actually be economics. Automation costs money. It is used because it expected to save money. If it costs too much or saves too little, why would you do it?
There is also a human perspective on the subject, which I have discussed in my Test Automation Philosophy, which is based on my even more general Automation Philosophy.