Why is test automation so bloody expensive


“We can’t automate everything. Test automation costs too much.” We hear this all the time.

In today’s day and age, when your SDLC has become agile, why do you still fear automating it all, across the life cycle and with every release?

You have read guides and key tips to make test automation a success. But, you sill wander in the dark to seek answer to the ultimate question- “why is test automation so bloody expensive?”.

So, we decided to surface reasons that still contribute to the cost of automation. These, reasons act as deterrents in implementing test automation across the entire testing life cycle. And believe me, they do!

Specialized skills don’t come that easy and definitely not cheap.

It does not matter whether you are a small or big team. Test automation requires scripting. Scripting cannot be avoided. It requires specialists who know the native language of the tool to make it work. It calls for programmers not testers. Often more than expected, good programmers come at a price. This increases the cost to automate. Don’t forget to include the costs of hiring and retaining these resources. And of course team burnout and attrition. Imagine what will walk out of your office! People, skills, domain knowledge, and what you have built till date.

Getting the maximum bang on your buck. Have you ever experienced it?

I know, this is something you can’t escape. Buying test automation tool licences. Every license will cost you an arm and a leg. But you can’t help it. However, what you can help, is optimize each license. Ideally you should be running the automation tool 24X7 to maximize tool productivity. But, then how would you write code to automate test scripts, when you know your test automation tool can do one thing at a time: either it can execute or it can build automated test suites. Users of open source tool like Selenium don’t have this complaint. But others do. Currently you have multiple licenses to suffice this need of yours. But you would agree with me that this is not an optimal return on your investment on them.

Time is money baby!

Test automation through test automation tools, requires scripting. To write scripts, test, and make them work requires time. We are talking considerable time here. And time means more cost, literally. Please take into consideration that how quickly you automate and how quickly you test will result in how quickly you can go to market.

Maintenance is the key issue in test automation.

Let’s talk about test script maintenance. With changes in every new release your test automation suite must also change. Will you go back to the drawing board and rewrite scripts? Remember the quicker you update your already automated test suites the faster you hit the market. These are all costs and opportunities you can’t condone. I am sure your CFO is keeping an eye on them. Sooner or later he will question you. As your test suite increases, you will face an excessive maintenance burden – which will lead to loss of more time and more money.

Time to build and break dependencies.

Currently you have a business analyst/SME, manual tester, and test automation expert as your stakeholders, each serving a critical need, in your testing life cycle. A business analyst is heavily dependent on test automation specialist to bring about new business rules and changes in them into automated test cases through scripting. This partnership, as we all know is not that smooth. It has its share of communication gaps, backlogs – resulting in more time to automate. And as we all know, more time means more money and lost opportunities.

You now know the core reasons that make test automation so damn costly. With this insight, you can change one or more than one parameters in the test automation equation to make it scalable and profitable. I am sure by now you know the answer. But, just to give you the hint, the answer lies in how quick and easy you can make test automation. How easy it is for your testing team to build test automation…

6 thoughts on “Why is test automation so bloody expensive

  • The article very well explains on the facts of automated testing. Believe developing properly structured scripts will help in improving test suite maintenance, cost and time too.


  • Test automation doesn’t have to be expensive. Cost of licensing the test tool can’t be gotten around, but that’s likely the largest expense to deal with.

    The key to good, affordable automation is simplicity. Don’t make it too complicated. Create a smart, modularized framework that can be adapted to fit the needs of the project. This way maintenance becomes negligible and writing new test cases doesn’t even have to require any scripting.

    A well designed, modularized framework is simple to do. I wasn’t a programmer when I started, but because of the simplicity of the design of the framework I was looking to build, I was able to write the code necessary with no prior experience. No developer necessary.

  • On Cost of the test tool … That doesn’t have to be expensive either. Most times what you’re paying for are the unnecessary bells and whistles that some tools offer like record/playback scripting or built-in keyword driven test tools. As long as the tool can interface with the running applications on a test machine, and has a scripting interface, that’s all you need. Further down the road you may want to incorporate a testing network where you have a server machine running tests on remote clients, so functionality that allows for that kind of future upscaling might incur cost, but that’s cost that’s worth it.

  • Cost of automation depend mainly on your ability to reuse. the calculation is very simple.
    but in order to reuse you must cooperate with others. this will be done using a artifacts repository (see RDTA approach). the answer to the simple question will I reinvent the wheel? or should we organize our test automation artifacts so it will be exposed to every body for reuse consideration, may determine the cost of test automation.

  • You might also want to consider the costs of instances/environments… The key is to reduce the maintenance effort and reduce the time required from expensive technical resources by having a sound framework.

  • You can’t get around needing an understanding software architecture to properly test software. If most of your testing and much of the activity to get the system in the proper state for the *narrowly defined* test assertion is done at the UI level, that’s a red flag. You need more code level integration testing and API testing and less UI testing.

Leave a Reply

Your email address will not be published.