I have been in the software industry since 1992 – after a brief stint actually USING my mechanical engineering degree for a couple of years. My initial focus was mostly on transactional database design and software development. I then narrowed the focus to the data side and Kimball-style datawarehousing. That opened the door to an onslaught of cool technology for data integration, data visualization…and even the more boring (but absolutely foundational) data governance. I believe in “all of the above”, and I’ve seen companies better leverage their data for both cost savings and to identify opportunities.

I knew my own company did test automation projects, but it wasn’t until I saw a recent ProKarma client case study that I remarked: Test Automation is Like a License to Print Money!

You see, with software development and datawarehousing, you sometimes build it with the HOPES that the users will come and adopt/embrace your solution. I’ll give you two examples that will drive perfectionist developers nuts, and we all have similar stories:

  1. You build the perfect report, and the users say “yeeaah, could you just export that to a CSV file for me? That’d be greaaat.”
  2. You build an elegant user interface with a stellar user experience, and the users say “yeeeah, could you just take this Excel file and upload it to the database? That’d be greaaat.” [No, I’m not bitter at all…]

Executive sponsors for the two examples above will look at you and say “why did I waste the time and money on this project when everybody is more interested in circumventing the final solution?” And end users are typically HIGHLY resistant to change and the adoption of new processes. I have seen examples where the necessary solution, for the company to advance in efficiency and productivity, was held hostage by a select few influential power-users who just refused to adopt it (but that is a separate blog post on how to drive consensus, collaboration, and joint success between the business and IT).

So why do I say Test Automation is like a license to print money? I’ll give you three reasons:

1. IT controls all of the players

Once you cross organizational boundaries in any company, you introduce a lot more politics, personalities, and fiefdoms. Each has their own back channels to decision makers higher up in the food chain who are capable of shutting down a project’s budget before it ever gets off the ground. Others are simply valuable knowledge assets in the company, and they use that status to block any changes to “we’ve always done it this way” processes.

The most damaging phrase in the language is “We’ve always done it this way!” ~ Rear Admiral Grace Murray Hopper

In the case of Test Automation, IT typically manages both the developers and the testers. Back in the day, there was a natural Us-vs-Them friction between these two organizations – I used to say that I had a Love/Hate relationship with my best testers. Present day agile and lean IT organizations “shift left” and blur the lines between developers and testers. In fact, Software Development Engineers in Test (SDETs) now focus on the bigger picture of system interaction vs the smaller picture of “feature happy path”. These SDETs frequently think about how they would break a feature before they even create it…and then write the unit tests first!

2. Test Automation pays for itself in a matter of months

Would you approve an IT project where you were assured that the project could pay for itself in a matter of months? And then those cost savings were “yours to keep” going forward – to perhaps fund other crucial projects for your company’s success in a highly competitive, cost-conscious world! Look at the example below that is based upon a recent ProKarma success story with a Financial Services company.Test Automation, DevOps, Continuous Integration, QA

  • The project starts out with (12) manual testers that take (4) weeks to make it through a regression cycle – at a cost of $80,000/month.
  • Automation gets introduced in May (Month 5) , and there are (3) months where we see a temporary headcount and cost increase as automation engineers work to create the automation framework and absorb (9) sprints worth of manual test cases (technical debt) into the library.
  • By September (Month 9), we already see a reduction – from the original headcount – to just (8) testers. With a reduction to just 1-week regression cycles, the project now effectively has “in sprint” automation.
  • By December (Month 12), the responsibility for execution and maintenance of existing automation is transitioned to the developers on the team. We have reached “Automation Sustenance” that only requires a headcount of (2) automation engineers for new test creation. And we are saving over $60,000 each month! The cost savings is 26.1% in just the first year, and that cost savings can continue for the life of the project. Nothing counterfeit here – that’s real dollars as if we had a license to print money!

3. There is a notable increase in efficiency and quality

Besides the tangible savings, projects with test automation also have notable increases in both efficiency and quality. The above example shows a reduced headcount from (12) manual testers to (2) automation engineers and a 3-week reduction in regression cycle. That is a much tighter feedback loop that results in higher quality code in a shorter amount of time. And when you have SDETs proactively thinking about how they would break their own code, before they even write it, you can imagine the higher quality before even executing the first test case!

Has your organization considered test automation? ProKarma has several test automation evangelists, and they can draw upon ProKarma success stories to demonstrate how a delivery automation effort (including test automation) could truly help your organization. In fact, they can work with you to identify the right-sized proof of concept – within your environment – for convincing leadership to further invest in test automation.

If test automation is like a license to print money, choosing to NOT implement test automation – and keeping manual testers with longer regression cycles – may be more like “throwing good money after bad.”