Strategic Test Automation

Testing is a critical part of any successful software development life-cycle. With demand ever-increasing for new digital solutions and quicker release cycles needed. The migration of previous manual test cases to an automated process is being put into action by more and more development teams as time goes on. And with amazing tools now available, such as Cypress and TestProject. Making the switch and reaping the rewards that test automation unleashes is simpler than ever.

With many benefits such as increases in efficiency, cost reductions less human interaction. Companies have a lot to gain from adopting robust test automation strategies and if used right. They will gain a valuable addition to their testing arsenal.

Unfortunately, many teams either start off on the wrong footing. Or when they get a new tool and use it. They have failed to have done the essential groundwork needed to know what they will do with it.

The importance of a strategy

It’s crucial that before you even start evaluating tools and drawing up training plans for your staff is to consider the ‘why’ of test automation and establish a vision for it. Knowing that you need test automation is one thing. Introducing it and then being able to strengthen it with essential upgrades and required maintenance is another story altogether.

One of my favourite quotes that I always think of when faced with a problem is by the great Albert Einstein who said:

“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”


In the context of test automation. Think of your strategy as the answer to the questions that will address future concerns and enable its long-term success. Address the roles people will play, the reason, why you are using the technology you have chosen. And what a successful implementation will look like.

Who will use and maintain the tool?

This may seem obvious at first as the main users of any test automation solution will be your testers. But will other groups of users need to have access as well? For example, is it likely that developers will be asked to help with the writing of tests?

I always advocate that test automation should be a software development project for testers. And so testers should be the ones who own the framework and maintain it. But should it be the entire testing team? Does it make sense for everyone to run upgrades and change the framework?

What do you want to automate and why?

Just because you can automate something. Doesn’t always mean you should.

You really need to weigh up the benefits and take into account not only the time saving that automation will provide you. But also the effort needed to automate a specific test case.

For example, there is no point in automating a complex task that is only run once a month. Not only because of the lengthy setup for the test (things rarely work the first time after all). But as it runs infrequently, the time-saving against running it manually will be negligible.

What will the test environment look like?

Another critical question that you need to consider is where will the execution of your tests be from? Developing the tests on a local machine is OK, but it’s not really a long-term solution if you wish to scale the framework to include the running of hundreds of test cases.

So in that case, you will need to establish a test automation environment. Again, either locally or on a remote machine. I recommend using Docker for this purpose so you can create predictable test environments and receive intended and specific results back.

How will results be collected and who will they be fed back to?

I’m guessing you have expected the requirement for some kind of report to not only share the results with stakeholders and those involved in the development project. But also to enable you to measure the effectiveness of tests and see potential improvements.

As Peter Drucker says:

If You Can’t Measure It, You Can’t Improve It


Unfortunately, if you use Selenium as your test automation tool for example. The functionality to generate reports does not come ‘out of the box’ and additional customization with libraries like Extent reports is required.

Introducing something new is never as simple as choosing the ‘best’ solution, doing a bit of configuration and then seeing the positive results flow in. To get a targeted outcome specific to your required needs. You need to do the work that will enable for that to happen.

Or in short, you only get out what you put in.

I hope you found this article useful. Let me know your thoughts in the comments.

Posted by Kevin Tuck

Kevin Tuck is an ISTQB qualified software tester with nearly a decade of professional experience. Well versed in creating versatile and effective testing strategies. He offers a variety of collaborative software testing services. From managing your testing strategy, creating valuable automation assets, or serving as an additional resource.

3 Replies to “Strategic Test Automation”

  1. Recently I have started looking into a tool for network/app Monitoring called Pingdom by Solar Winds. One of the features this has transactions so you can run through a set of steps and time how long it takes to do (to checking for both the response times, and whether they can be successfully completed). However, my point is that this action of creating a script has a superb interface – to create a test to login to the site, search for items, add to basket etc take a few mins to set up. It just scrapes through the page looking for the various selectors and you can just build up the test really easily step by step – zero coding. I’d really like to get something like this as a potential for UI testing in the team because literally anyone could write the tests and therefore it becomes more accessible to everyone. If anyone has any recommendations for a reliable, flexible, codeless automation solution let me know – I will look at the ones you recommend above as well.



      Interesting. It’s on my list of things to check out 🙂

      As far as codeless tools go. TestCraft is quite nice and I’ve heard a lot of positive chatter.

      I’ve also reviewed a codeless tool called Reflect ( – It had a few issues when I tried it initially. But they were ironed out and I quite liked it!


      1. The way you make the scripts is literally “Go to URL xxx”, Click xxxx, Enter xxxx into Field xxxx etc. It is so basic – however, whether this could extend to a full test suite of UI tests I don’t know (it seems very rigid). But the concept of it and how easy it is to put the transactions together is a huge benefit. My automation experience is limited to a C# drive Se Framework (and a very limited use of Se IDE) but I really want something that is accessible to as many people as possible.


Leave a Reply