La taverne du testeur

L’automatisation des tests échoue ?

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:

  1. Gagner de l’argent sur l’exécution des campagnes de test
  2. Gagner du temps sur l’exécution des campagnes de test
  3. Implémenter les tests dans une chaîne d’intégration continue
  4. Diminuer les coûts de correction en détectant les anomalies plus tôt
  5. Améliorer la qualité de l’application en ne déployant plus d’anomalies majeures ou critiques
  6. 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:

  1. 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
  2. Des tests automatisés plus chronophage que les tests manuels
  3. L’échec de l’ajout des tests dans la chaine d’intégration continue
  4. Une détection tout aussi tardive des anomalies
  5. Le déploiement d’autant d’anomalies majeures ou critiques en production
  6. 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 à:

  1. 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.
  2. 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!
  3. 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
  4. 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
  5. 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é.
  6. 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

  1. 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/

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Keryon Lean Testing
Agilité

Pourquoi faire du « Lean » pour les tests de logiciels

Article publié initialement sur keryon.consulting Lorsqu’il s’agit de faire des tests, il faut, souvent, de nouvelles approches et techniques. Actuellement je pense à : savoir explorer des datasets pour trouver les bonnes données, concevoir des stratégies de test pour des applications qui intègrent du Machine Learning, intégrer et piloter les tests

Lire la suite »
Bug

Coup de Gueule: arrêtez de me parler de 0 Bug!

Introduction Si vous êtes dans le test depuis quelques années vous n’avez pas pu échapper au « 0 bug ». Cette notion se voit régulièrement à travers: La promesse d’outil de test comme des outils d’automatisation ou de modélisation Les attentes de managers ou les annonces de certains bilans de test Des

Lire la suite »
Outils

Outil de test: gérer ses tests avec Testlink

Testlink en Bref Testlink est un outil de gestion des tests (ALM) open source et totalement gratuit. Testlink permet, comme d’autres ALM, de gérer ses exigences, tests et campagnes de test tout en les liant entre elles. Testlink ne propose par contre pas de gestion de module de gestion des

Lire la suite »