Functional test automation is supposed to make validation processes faster for companies, while improving application quality. However, automation is not foolproof and can fail for many reasons.
Saving time, reducing costs, reducing time to market, accelerating the move to production, better test coverage: there are a number of good reasons to embark on a functional test automation process. But if it is not well prepared upstream, automation can fail.
Automated testing can be more costly than it is worth to the business, take more time than it saves, or even fail to detect anomalies quickly enough. It all depends on the objectives you set for yourself, but if one of them is not being met, there is a problem somewhere. And we recommend that you look at these four reasons.
Poor targeting of tests to be automated?
You'll say that we're repeating ourselves, but a little reminder never hurts: it' s not necessary to automate all your tests and it would be counterproductive. Simply because some tests need to remain manual, allowing a human to spot things that a machine wouldn't see, especially regarding ergonomics, accessibility, etc.
To ensure the quality of web or mobile application development and obtain an optimal return on investment, it is therefore imperative to combine automated and manual testing. But you still need to choose the right tests to automate, because the wrong tests can make your automation strategy totally ineffective and make you lose more time and money than anything else.
At Mr Suricatewe recommend automating the most recurrent and repetitive tests, such as non-regression tests, as well as the most critical paths and functionalities, which have a direct impact on the company (business, legal, image).
.png?width=372&name=Infographie%20-%20Quels%20tests%20automatiser%20%20%20(3).png)
An unsuitable tool?
To meet the need for automation, many tools exist, but don't get confused. Not all tools are equal. Some may be too technical and require skills that are not adapted to those of your team. Others have high implementation and maintenance costs, which must be taken into account. And others do not allow you to test everything.
This requires a careful study of your needs, but also to take into account your development project (if it is an API, a fat client, a web interface, a mobile application, if it is multi-devices...), but also the skills of your team, the level of complexity of the functional tests you want to automate, as well as the cost you want to allocate to it.
A lack of maintenance?
In the long run, automation often fails because of a maintenance problem. Indeed, you must not forget to update your automated test scenarios as soon as there are changes, whether it be in the UI, the functionalities, the operating system, the browser, the data, etc. The risk, otherwise, is that anomalies will not be properly detected and development teams will lose time, whereas the very purpose of automation is to save them time.
A lack of analysis?
Automating functional testing can do a lot for your business, but there's no point in starting if you don't plan to analyze the results of the tests you run.
After all, what's the point of launching automated test campaigns if you decide to deliver to production without checking that anomalies have been detected? The risk is then to deploy a poor quality application, full of critical bugs and we are not talking about the negative impact that this can have on your users.
It is not enough to run automated tests by the dozen, hundred or thousand, you must also set up failure analysis systems and facilitate the reporting of these failures, by creating, for example, incident sheets automatically, in order to be able to take the necessary actions afterwards: re-run the test that has failed, update it or correct the anomaly detected.
