Test Automation Camel, a metaphor that explains why most test automation attempts failed?
A metaphor provides a full picture that explains why most software projects failed test automation.
--
According to the IDT automated software testing survey in 2007, “although 72% stated that automation is useful and management agrees, they either had not implemented it at all or had had only limited success.” (see this article for the definition of success) The reasons given for the failure of Automated Software Testing were:
- Lack of time: 37%
- Lack of budget: 17%
- Tool incompatibility: 11%
- Lack of expertise: 20%
- Other (mix of the above, etc.): 15%
As more software companies have adopted agile methodologies (and even DevOps), I think it is safe to say, >90% of software teams would now agree test automation is useful or absolutely mandatory. However, most software projects still “either had not implemented it (E2E Test Automation) at all or had had only limited success”.
Table of Contents:· Why the 'top 4 reasons for not doing Test Automation' are wrong?
· Test Automation Camel
∘ 1. Out of Reach: Expensive
∘ 2. Learning Curve: Steep
∘ 3. First Hump: Hard to Maintain
∘ 4. Second Hump: Long Feedback
Why the ‘top 4 reasons for not doing Test Automation’ are wrong?
Let’s examine the top 4 reasons listed by the survey candidates who wanted but failed (or didn’t even start) the test automation. These reasons sound “about right”, however, they are wrong.
- Lack of time
WRONG! Automation saves time. Automated test execution is faster, typically, only 10%-30% of that if done manually. For example, on a recent project, the automated test I created shortened the execution of a typical manual test case from 1 hour to 6 minutes.
Given that regression testing needs to be performed frequently (at least once per sprint, many more if…
