L'automatisation des tests peut échouer pour de nombreuses raisons. Aujourd'hui, nous allons nous pencher sur une cause récurrente de ces échecs : une automatisation trop coûteuse ou le fait de vouloir tout automatiser.
Un coût d'automatisation trop élevé conduit à l'échec de l'automatisation
La mise en place de tests automatisés est un investissement... Et comme tout investissement, on attend un retour. Ce retour sur investissement (dans le cas où vous automatisez pour gagner de l'argent) doit être réalisable !
Il est également bon de noter que ce principe s'applique également aux tests en général. En effet, dépenser 50 000 € en tests pour une application qui ne rapportera que 40 000 € est une grave erreur. À ce prix-là (si l'on ne tient compte que du prix), il vaut mieux ne pas diffuser l'application !
Revenons à l'automatisation des tests. Le coût de l'automatisation peut être simplifié avec cette équation : CA = I + n*X où :
- CA = Coût de l'automatisation
- I = Investissement (coûts des études préliminaires, des licences, de la formation, de la rédaction des tests, de la mise en place des environnements...)
- X = coût d'une campagne (exécution (souvent proche de 0), analyse, maintenance...)
- n = nombre de campagnes
De même, le coût des tests manuels peut être simplifié par une équation similaire : CM = I' + n*X' où :
- CM = Cos des tests manuels
- I' = Investissement et tests manuels (écriture, conception...)
- X' = coût d'une campagne (exécution, analyse, maintenance...)
- n = nombre de campagnes
Le coût d'investissement de l'automatisation est plus élevé que celui des tests manuels. Afin d'assurer un retour sur investissement positif, il est nécessaire, en plus d'avoir un investissement raisonnable, d'avoir un coût unitaire de la campagne de tests automatisés inférieur à celui des tests manuels (sinon les courbes ne se croiseront jamais) et également d'avoir un nombre "n" suffisamment grand pour que les courbes se croisent.
On voit ici qu'un projet d'automatisation des tests réussi implique de savoir et d'identifier jusqu'où on peut aller en termes d'investissement, mais aussi d'automatiser les tests qui seront réexécutés assez souvent pour devenir rentables. Vouloir automatiser tous les tests de l'interface graphique s'avérera dans la grande majorité des cas un investissement très coûteux qui ne sera pas rentable.
Comment réduire le coût de l'automatisation des tests ?
Afin d'éviter ce problème de coûts élevés, il est nécessaire de maintenir le coût d'investissement des tests automatisés à un niveau acceptable, mais aussi d'automatiser des tests qui seront rentables car suffisamment réexécutés. Pour assurer cette rentabilité, l'équipe peut mettre en place certaines bonnes pratiques telles que
Automatiser les tests qui sont destinés à être réexécutés
Le principal critère de rentabilité des tests automatisés est la possibilité de les ré-exécuter. En effet, le coût d'écriture d'un test automatisé est généralement beaucoup plus élevé que celui d'un test manuel. Afin de limiter le coût général des tests, il est également possible de limiter le coût des tests manuels qui ne seront pas réexécutés en ne les scénarisant pas et en faisant des tests exploratoires. On construit alors une stratégie de test où les tests de régression sont automatisés et les tests de validation des fonctionnalités supplémentaires sont faits en mode exploratoire. Cela permet de stabiliser les nouvelles fonctionnalités du logiciel et de se donner un peu plus de temps pour effectuer des tests automatisés sur ces nouvelles fonctionnalités. Pour les équipes Agile, il est possible d'envisager de réaliser des tests de non-régression automatisés uniquement lorsque tous les développements d'une épopée ont été obtenus, et non au niveau de la user-story, où la granularité est trop fine.
Architecturer les tests de manière à limiter maintenance
Comme nous l'avons vu dans la première partie, un aspect très important de la rentabilisation de vos tests est le coût de chaque campagne. Ce coût doit être le plus bas possible afin d'atteindre le seuil de rentabilité le plus rapidement possible et d'en tirer le maximum de profit. Une part importante du coût des campagnes de tests automatisés est le maintenance des cas de test. Afin de limiter ce maintenance, il est essentiel de bien réfléchir à l'architecture de l'automatisation, de factoriser au maximum les étapes communes à plusieurs tests afin de ne modifier qu'un seul script lorsqu'une modification affecte plusieurs tests. Agilitest a bien entendu pensé à ce problème, c'est pourquoi il propose des "sous-scripts" qui peuvent être appelés par chaque test mais aussi paramétrés. Par exemple, on peut penser à un test d'une page de formulaire avec 10 champs à remplir qui serait transformé en un seul sous-script avec autant de paramètres et qui serait réutilisé dans plus de 20 tests.
Automatiser les tests pour lesquels le coût d'automatisation est acceptable
Certains tests sont techniquement compliqués à automatiser. Cela peut être parce que l'outil peut difficilement ou pas du tout le faire (comme passer un captcha), parce qu'il est compliqué d'assurer un test stable et fiable, parce que le résultat est difficile à " quantifier " et qu'un œil humain est préférable, parce que le chemin est complexe (comme accéder à une machine sécurisée) ou pour toute autre raison. Dans ce cas, le coût d'investissement pour écrire le test peut être trop élevé pour être rentable et il est donc préférable (si possible) de ne pas l'automatiser. Il suffit alors de supposer un coût de "stabilisation" destiné à rejouer tous les tests manuels avant de permettre le déploiement de la version.
Limiter le coût d'analyse des tests automatisés
Ici encore, nous parlons du coût unitaire d'une campagne. Comme nous l'avons vu dans un précédent article, il est essentiel pour la réussite de l'automatisation d'analyser les résultats des tests. Cette analyse n'est pas gratuite et peut rapidement devenir très coûteuse si les bons outils ne sont pas mis en place. Un coût d'analyse trop élevé peut rendre le coût unitaire d'une campagne trop important pour espérer un retour sur investissement. Pour éviter cela, il faut être capable de comprendre rapidement et simplement pourquoi un test échoue et donc disposer des informations d'exécution pour analyser le problème le plus rapidement possible. L'équipe d'Agilitest est particulièrement consciente de ce problème, c'est pourquoi il est possible d'avoir des captures d'écran pour chaque étape et également des vidéos des tests exécutés. Voir ce qui s'est réellement passé lorsqu'un test a échoué est un réel apport pour analyser cet échec lorsque vous n'avez pas assisté à l'exécution, ce qui est généralement le cas avec les tests automatisés.
Conclusion
Avoir un projet de test rentable n'est pas toujours facile. Il faut faire attention à plusieurs paramètres et savoir s'arrêter au bon moment sur ce que l'on veut automatiser. Ce point d'arrêt dépend de nombreux paramètres et du contexte, c'est pourquoi il est généralement préférable de réaliser une étude sur le périmètre à automatiser, de développer une stratégie sur les tests à automatiser et également d'établir un suivi tout au long de la vie de ces tests.
Photo par Christopher Gower sur Unsplash
.png)
