Is Test Automation Still in High Demand? You Bet!
Share my thoughts after reading the latest MarketsAndMarkets report.
A repost of my past article on Medium.
According to the latest MarketsAndMarkets report, “The global Automation testing market size is expected to grow USD 20.7 billion in 2021 to USD 49.9 billion by 2026, at a Compound Annual Growth Rate (CAGR) of 19.2% during the forecast period.”
A compound annual growth rate of 19.2%! It must be among the top, if not the top, in the software industry.
Also, a forecast by Polaris Market Research (published in March 2022):
Why Test Automation will be in such huge demand?
The explanation from MarketsAndMarkets is too vague: “The Automation testing market is growing due to the rapid adoption of advanced technologies.”
I want to clarify that test automation here is “Automated End-to-End (via) UI Testing”.
In my view, the reasons are simple:
“Release Early, Release Often”
Every CIO loves this slogan for many obvious reasons. Automated Testing is the enabler of that.
The natural outcome of frequent releases is a lot more testing effort. The only solution is to do that using automated test scripts.Test Automation is the core of Continuous Testing, therefore, DevOps
Cost-Saving
the labour cost of IT engineers has grown fast in recent years.
Take my own development as an example, 70% of the whole SDLC effort and cost are spent on Test Automation and Continuous Testing. In return, I gained very high productivity. Check out Reflections of Software I Created over the Last 14 Years in My Spare Time.
But I rarely see real test automation in Software Projects?!
That’s because most software teams lack the capability in real test automation.
If Automated Testing (in particular Automated End-to-End Testing via UI, the top tier of the Testing Pyramid) is pure hard, then we probably will see more successful test automation attempts. As some ambitious software engineers will endeavour and successful ones grasp the glory.
However, it is not the case. Test automation is very easy to get started, such as creating a couple of tests using recorders in Quick Test Pro 20 years ago. That approach was proven wrong, as the most effort in test automation is maintenance. However, the maintenance effort is often under-appreciated.
“In my experience, great developers do not always make great testers, but great testers (who also have strong design skills) can make great developers. It’s a mindset and a passion. … They are gold”.
- Google VP Patrick Copeland, in an interview (2010)“95% of the time, 95% of test engineers will write bad GUI automation just because it’s a very difficult thing to do correctly”.
- this interview from Microsoft Test Guru Alan Page (2015)“Testing is harder than developing. If you want to have good testing you need to put your best people in testing.”
- Gerald Weinberg, in a podcast (2018)
In reality, software testing, despite its growing importance, test automation engineers are still not respected as software engineers (I know some top IT firms are different, but still rare).
Naturally, software engineers will rather stay on the programming side, easier work and high respect, and often more pay as well. So, why bother with test automation? After all, real test automation skills are hard to learn from. Few universities offer a course on that, and real test automation engineers are extremely rare. Even LinkedIn (in Silicon Valley) had to ‘lure’ someone from Google to implement this.
“Much of LinkedIn’s success can be traced to changes made by Kevin Scott, the senior vice president of engineering and longtime Google veteran lured to LinkedIn in Feb. 2011” — Wired’s article “The Software Revolution Behind LinkedIn’s Gushing Profits”, 2013
It seems not many Job Ads for Test Automation Engineers though, why is that?
Yes, this is because there have been many failed test automation attempts, for many different reasons, such as wrong automation framework (e.g. Protractor, Cypress), wrong language (Java, C#, JavaScript), wrong test syntax framework (Gherkin), …, etc. Furthermore, fake automated testers (many of them) made test automation a bad reputation. A few managers/executives told me that they had already lost hope after repeated failures, throwing more money did not help at all, until seeing my work. It turned out that test automation can be implemented with results in a matter of days, using free and open frameworks or tools.
Despite the huge demand for test automation, education on test automation and Continuous Testing is severely lacking. Sadly, many didn’t even know that or did not know what to do.
Still, the high demand is always there, even more so in the foreseeable future.
Why did not the software companies ask for help?
This is quite subtle. It took me years of consulting to figure that out.
As software testing has long been considered a low-priority task, when the idea of test automation came up, IT executives would ask the software architect or principal software engineers. However, these people did not understand test automation or continuous testing. A common mistake was confusing it with Unit Testing.
Some senior engineers would dive further, and try some automation frameworks or tools. The demo might look promising, and IT executives gave the green light to go ahead. Not long, a big mess, because they could not maintain the test scripts. Now it is not the vendor’s problem, rather it is an embarrassment for Software Architects or IT Executives. As you can see, this now moves out of technical judgements, the situation gets complex.
Few software architects would acknowledge they did not know test automation and continuous testing. They think: “If I admit that, others will look down on me”. Test automation capability is far beyond an ordinary software architect/principal software engineer (read the comments by Google VP Patrick Copeland, who is in charge of some of the best engineers in this world). It is like a kid felt sorry: “I did not make Olympic’s 100m sprint semi-final”.
I have been dealing with a number of software architects/principal software engineers, who were confused and worried when someone mentioned ‘Automated Testing’. For them, ‘Automated Testing’ means failure and embarrassment. I felt sorry for them, if they acknowledged it, they could learn.
Some senior engineers even turned evil and sabotaged my test automation efforts. This did not just happen to me, my daughter met one in her first intern role, check out this article: An IT Graduate’s frustration with a Fake ‘Senior Test Automation Engineer’.
What is the right approach then?
Simple. Think of this situation (inspired by the movie: King Richard): if your kid likes tennis and is out of your capability to teach, what will you do? Find a professional coach. It is, in my opinion, the most cost-effective software consulting. Why? take web app testing for example, to real test automation engineers, all websites are the same, based on W3C technologies (HTML, CSS, JS, …). Under good (must hands-on) coaching, your team’s test automation will grow at a visible pace, and it won’t take long (a few weeks will do).
Another way to discover internal talents openly, I call “Test Automation and Continuous Testing Competition Week”. Remember, existing software architects/principal software engineers involved with failed test automation might be roadblocks. So, I suggest the CIO be directly involved with this. Otherwise, a software architect can easily shoot down brilliant ideas. It is their benefit to prevent real test automation.
Related reading:
My eBooks:
- “Practical Web Test Automation with Selenium WebDriver”
- “Practical Continuous Testing: make Agile/DevOps real”Benefits of Real E2E Test Automation and Continuous Testing series: Executives, Managers, Business Analysts, Developers, Testers and Customers.