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.