While in any ranked list, the core points may be listed with justification, a lot of subjective inputs from the author do tend to come into the picture. Similarly when we look at the top five tips to effective software test automation, what may rank up as top five here, may not necessarily be top five for someone else. And there is no magic with a number five. It could be top three, top ten – to enable a quick read and to keep it as objective as possible, I am limiting this to top five.
Automation is the way to go, moving forward, whether it is core engineering, quality engineering, support and release operations – whatever the discipline may be. From a quality engineering standpoint, automation testing has become mainstream over the last decade. More so in recent years, software test automation has enabled continuous testing, in the larger continuous development cycle, making it possible to release in short cycles yet not compromising on quality. Automation is only as smart as we design it to be just like a regular computer program – herein a test automation strategy that is robust is very important. What are the top five elements in making it robust? Here’s my take, based on our experience at QA InfoTech:
- Solid automation testing framework – A job well begun is half done. A framework and an overall approach that is defined well upfront, keeping long term use, flexibility, scalability, use across the development team, pieces that can be used by non-technical teams, is one that sets the right path forward. Teams that do not give due attention to a solid framework, start off with a weak foundation. Whereas a strong foundation once laid, even others such as manual testers, and developers can help with automating test cases, enabling everyone own quality. A framework for specific areas including UI, API, database therefore becomes the first core piece to work on.
- Combinatorial efforts – While we look for effective reusability in test automation, a lot can be done in reusing automation across test attributes too. Not many teams leverage this potential fully – for example, functional scripts from Selenium can be used for accessibility testing with the use of a few custom plugins and tools such as Axe. So is the case in areas such as security and performance testing. Such combinatorial efforts, go a long way in building effective test automation in the long run, with some quick short terms wins.
- Value from automated testing services – While a number of teams focus heavily on the immediate short term test automation wins including coverage, not many pay a lot of attention on the long term value. How effectively are the test suites being run, how frequently are they being used, what kind of defects are the tests surfacing, how automated outcomes are enabling the leadership team make effective decisions related to quality – these are questions to periodically look into, to understand the true value from software test automation.
- Eye for maintenance – This is not a new point. Most teams understand and take up automation maintenance regularly, as the product undergoes change. However, herein I am talking about not just upkeep to ensure the automation suite is up and running as the product changes, but also to ensure the overall framework and the test automation approach is looked at to ensure it is really the efficient way of doing things. With the latest in technology, especially with what AI has to offer, there are much better ways of implementing a framework, creating templates, defining test cases, integrating suites etc. Practices keep changing every now and then, for the better. It is our responsibility to have an eye for such upkeep and upgrade too, as part of the overall maintenance effort.
- When to automate – And finally, when to automate. A favourite question that the industry has answered for several years now. Especially in the Agile cycle, while teams would like to achieve inSprint automation, for a plethora of reasons, this may not always happen. Number of stories signed up for, dev-test ratios, backlog of stories, test debt etc. may all add to the test challenges in achieving test automation within a given Sprint. While the above points are all good tips to keep in mind to enable in Sprint automation, the challenges are also real and can be overwhelming. If the team finds itself in such a situation, it would be a good idea to pause, discuss with the entire team to see if one Sprint has to be introduced as a Quality Sprint, to play catch up, before we go back to the regular development cycle. It does not hurt to ask for explicit help – developers are today ready to help with test automation, once the core expertise has been brought in with an effective framework.
As experienced testers, we need to come in with a solid test automation strategy that is embracing of the entire team in collective ownership of quality.