L’automatisation est naturelle. C’est quelque chose que l’on fait instinctivement depuis notre enfance. Il parait donc normal que le test soit impacté par l’automatisation. Néanmoins ce n’est pas parce que c’est « naturel » que l’automatisation est forcément une réussite. Ce constat touche évidemment l’automatisation des tests!
Mais, un échec de l’automatisation des tests, ça veut dire quoi ?
Quels sont les échecs de l’automatisation?
L’automatisation de l’exécution des tests est un échec! C’est un constat facile à dire mais un peu plus compliqué à faire. En effet, à partir de quand peut-on dire de manière objective que l’automatisation est un échec ?
Pour cela il faut revenir aux raisons pour lesquelles on a lancé le projet d’automatisation, ces raisons peuvent par exemple être:
- Gagner de l’argent sur l’exécution des campagnes de test
- Gagner du temps sur l’exécution des campagnes de test
- Implémenter les tests dans une chaîne d’intégration continue
- Diminuer les coûts de correction en détectant les anomalies plus tôt
- Améliorer la qualité de l’application en ne déployant plus d’anomalies majeures ou critiques
- Assurer une bonne couverture de test…
Comme vous pouvez le constater les raisons pour lesquelles on fait de l’automatisation de l’exécution des tests sont nombreuses et variées. D’ailleurs on automatise rarement pour une unique raison!
D’un point de vue personnel je considère que le projet d’automatisation est en échec (ou un échec) dès lors où l’un des objectifs que l’on s’était fixé n’est pas atteint.
En clair, les échecs d’automatisation peuvent être, d’après la liste précédente:
- Une perte d’argent liée à l’automatisation des tests. Les tests ont coûté plus cher que ce qu’ils n’ont rapportés
- Des tests automatisés plus chronophage que les tests manuels
- L’échec de l’ajout des tests dans la chaine d’intégration continue
- Une détection tout aussi tardive des anomalies
- Le déploiement d’autant d’anomalies majeures ou critiques en production
- Une couverture de test défaillante
Quelles sont les Causes de ces échecs ?
Les causes de ces échecs peuvent être nombreuses. Une raison qui revient souvent est une étude de la pertinence de l’automatisation pas assez poussée.
Concrètement, pour les raisons définies préalablement on peut penser à:
- Gagner de l’argent sur l’exécution des campagnes de test: un investissement initial trop coûteux, une maintenance trop coûteuse.
Pour éviter cela il faut bien cibler les tests à automatiser et bien architecturer son automate pour limiter les coûts de maintenance. - Gagner du temps sur l’exécution des campagnes de test: les tests automatisés peuvent avoir des performances assez faible et être long à exécuter, des tests pas assez fiables forcent des rejeux ou des analyses inutiles, de même l’analyse des tests automatisés peut également être coûteuse.
Pour éviter cela il faut bien choisir son outil de test, écrire des tests fiables! - Implémenter les tests dans une chaîne d’intégration continue: les tests automatisés n’ont pas pu être intégré à la chaine d’intégration continue ou ne sont pas bloquants. De même cela peut être parce que le temps d’exécution est trop long
Pour éviter cela il faut s’assurer de la présence des compétences techniques pour réaliser cette tâche, bien sélectionner ses tests mais aussi écrire des tests assez fiables et stables pour ne pas bloquer la chaine d’intégration continue - Diminuer les coûts de correction en détectant les anomalies plus tôt: le résultat des tests n’est vraiment étudié qu’avant le déploiement. Cela peut être dû au fait qu’ils sont trop souvent exécutés et donc ignorés ou alors qu’ils ne le sont qu’au dernier moment.
Pour éviter cela il faut mettre en place un processus proposant une charge d’analyse des tests soutenable qui soit réellement suivi par l’équipe - Améliorer la qualité de l’application en ne déployant plus d’anomalies majeures ou critiques: les tests automatisés n’ont pas détectés l’anomalie car ils n’étaient pas à jour ou qu’ils n’étaient pas assez bien conçus.
Pour éviter cela il faut maintenir régulièrement ses tests et bien sûr faire évoluer sa campagne de test automatisé. - Assurer une bonne couverture de test: cela est souvent dû à des tests non maintenus (ce qui crée des trous dans la couverture) ou bien un outil qui ne peut pas effectuer certaines actions indispensables à certains tests.
Pour éviter cela il faut bien maintenir ses tests mais aussi bien sélectionner son outil dès le départ.
Conclusion
L’automatisation des tests c’est compliqué et comme toute chose compliqué il est difficile de la réussir du premier coup. Néanmoins, une bonne préparation et une discipline importante permet d’éviter certains problèmes réguliers.
Enfin, ce n’est pas parce qu’un projet est en échec à un instant t qu’il le sera 6 mois plus tard. L’amélioration continue est là pour nous aider et nous permettre de devenir meilleur.
Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
N’hésitez pas à faire vos propres retours d’expérience en commentaire.
Une réponse
Bonjour,
Il existe aujourd’hui une solution robotisé et automatisée conçue et fabriquée en France, qui permet de tester de façon non intrusive les IHM: le robot eTASQ Motion.
Il répond aux points que vous évoquez dans votre article:
– il permet une écriture simple des scripts de test donc un gain de temps en préparation
– il a une capacité à tester équivalente à celle d’un opérateur (notamment en termes d’actions possibles), avec un rapport global mais aussi plus détaillé pour chaque run, permettant à l’opérateur ou au développeur d’intervenir précisément sur l’origine du bug.
Si vous le souhaitez, vous pouvez trouver tout le détail de cette solution sur https://etasqmotion.com/