Test automation can be the solution to releasing new features and functionality with reduced time to market. Automation is one of the tools for QA resources to use but at Digivante we firmly believe full automation isn’t the ultimate end goal. You might be thinking, “but automating any test is going to save me time in the long run.” This isn’t necessarily the case. We take a pragmatic approach to test automation and believe you should be clinical with where you automate your testing, basing your decisions on where it will save you time and money. When inappropriate tests are automated, it costs you.
When does it make sense to automate?
Regression testing is often a prime candidate for automation. Let’s face it, the repeatable nature of regression testing hardly sets a tester’s world alight. Internal or offshore testers repeating the same regression tests will inevitably cut corners when under pressure, and the quality and consistency of results degrade over time. Automation is a route to eliminate that risk.
But automating a regression pack is expensive and time consuming. Let’s say you have a regression pack with one hundred test cases. The path to automating all of those, and ensuring that the automation works as expected, is long and sometimes arduous.
Another area that’s prime for automation is integration testing. You’ve got your main site or app created but you might be integrating with payment systems like PayPal, or stock management systems or content management systems or potentially dozens of other integrations that give your users the experience you want for them. Using test automation, developers can take a “shift left” approach to integration testing using a REST (Representational State Transfer) tool and API (Application Programming Interface) to test integrations early in the SDLC (without target integrations systems being in place). The API requests can be automated to run as part of the deployment of code or in CICD which is quicker than testing via the UI.
Our approach to automation
We take a practical approach to automation. Let’s go back to the regression pack with one hundred test cases.
We start with running every one of the 100 tests manually first to ensure the test case works and we record all of the actions to build the skeleton of the code. By running the test cases manually first we find out which test cases pass and which fail.
Let’s say 90 passed but 10 failed; those 10 are now off the list to automate.
For the 90 that passed, we’ll assess which would make sense to automate. If you run your regression pack regularly, say weekly, it becomes cost effective to automate as much of it as possible.
So next is the process of scripting the tests for automation. We focus on automating stable entities that have repeatable actions and don’t change regularly, otherwise maintenance costs and automation coverage will be impacted.
Keep testing whilst building out your automation
Once you’ve decided what to automate, you need to ensure you have test coverage in the meantime, whilst your automation is being coded. Working with a company like Digivante, you gain access to the crowd testing community that gives you broad testing coverage whilst building your test automation programme .
Even if you have an existing automation pack, or are already in the process of creating one, you might have an area that fails its automated tests. Our recommendation is to then pass the same tests to crowd testers. If the crowd passes the test, then you know there’s an error in your script. But if the crowd fails the test too – you know your automation fail is a real fail too. Instead of just getting an error message, you’ll be able to see – in lots of detail – where the issue is and where your developers need to focus to fix it, allowing for prioritisation of issues.
The Digivante automation process
If starting automation from scratch