Les raisons de l’échec de l’automatisation des tests: le manque d’analyse après l’exécution

par Marc Hage Chahine | 22 février 2021

Agilitest fait équipe avec Marc Hage Chahine du blog La Taverne du Testeur pour explorer les raisons de l’échec de l’automatisation des tests: quelles sont-elles ? Comment les éviter? Et comment Agilitest peut vous permettre de surmonter ces obstacles et d’assurer une automatisation réussie? Bonne lecture!



L’automatisation des tests peut échouer pour de nombreuses raisons. Nous allons aujourd’hui nous pencher sur une cause récurrente de ces échecs, l’absence d’analyse des tests après leur exécution.

L’absence d’analyse des tests automatisés après leur exécution aboutit à l’échec de l’automatisation

L’implémentation des tests automatisés permet de diminuer fortement le coût d’exécution et la mise d’une très bonne pratique du test, qui est d’ailleurs un des principes du test : « Tester tôt ».

Tester plus fréquemment est d’ailleurs une des raisons pour lesquelles il est conseillé d’automatiser ses tests. Néanmoins, la multiplication des campagnes de test ne sert à rien si le résultat de ces campagnes et plus spécifiquement des tests exécutés lors de ces campagnes ne sont pas analysés. Dans les faits, ne pas analyser ses campagnes de test c’est même pire que ne pas en exécuter du tout car l’exécution seule donne l’illusion que la qualité est assurée alors qu’en fait il n’en est rien.

A terme on peut avoir des campagnes de tests exécutées plusieurs fois par jour mais jamais analysées car le temps d’analyse de chaque campagne peut nécessiter plusieurs heures. On arrive alors dans un cercle vicieux où les tests automatisés n’assurent plus rien car leur résultat n’est plus regardé et les livraisons se font dans tous les cas. Cela conduit au déploiement de version contenant des anomalies critiques qui auraient dû être détectées et donc à l’échec de l’automatisation.

Cette dérive est rarement volontaire et vient de l’idée reçue qu’avec l’automatisation des tests les campagnes de test sont gratuites. Ce n’est malheureusement pas le cas. Seule l’exécution des tests est quasiment gratuite avec l’automatisation, l’exécution en elle-même n’est qu’une partie de la campagne de test comme on peut le voir avec cet exemple :

Comparatif de la charge de travail tests manuels VS tests automatisés

2: Image prise sur le blog de la taverne du testeur

Multiplier les exécutions revient à multiplier les analyses et le coût de l’analyse des tests en échecs est loin d’être gratuit. Cette analyse peut d’ailleurs être plus coûteuse avec une campagne d’automatisation qu’avec une campagne manuelle pour la simple et bonne raison qu’il n’y a pas d’œil humain derrière l’exécution.

Afin d’éviter ce problème il est possible de mettre en place quelques bonnes pratiques.

Comment éviter le problème de non analyse des campagnes de tests automatisés ?

Pour éviter ce problème il faut évidemment analyser chaque campagne exécutée, savoir pourquoi chaque test en échec est en échec et prendre les actions nécessaires suite à cet échec comme la création d’une fiche d’anomalie, le rejeu du test ou la mise à jour du test. C’est facile à dire, plus compliqué à faire c’est pour cela que l’équipe peut mettre en place plusieurs bonnes pratiques :

Limiter le nombre de test dans les campagnes

Le coût d’analyse d’une campagne de test doit être maintenu à un coût supportable par l’équipe. Plus il y a de test plus l’analyse coûte cher. Il est donc parfois nécessaire d’exécuter moins de tests. Cela peut se faire de plusieurs manières comme créer plusieurs campagnes, adapter les tests à exécuter en fonction des campagnes ou encore maintenir moins de test.

Limiter le nombre d’exécution des campagnes

Une analyse doit être faite après chaque campagne. Il est préférable de faire 1 campagne par jour et de l’analyser plutôt que 3 campagnes sans l’analyser.

Mettre en place des systèmes pour faciliter l’analyse des tests en échec

C’est un point particulièrement important avec l’automatisation des tests. Les tests doivent pouvoir fournir des preuves de ce qui s’est passé et pas seulement un statut. Lorsque le testeur analyse le test il doit être capable de savoir ce qui s’est passé et comment pour reproduire et comprendre la raison de cet échec.

Agilitest propose justement des outils proposant cette facilitation avec des vidéos ou des impressions d’écrans possibles à chaque étape ou échec. Vous pourrez trouver un rapport complet de campagne de tests, incluant les rapports vidéo, html et pdf de chaque test.

L’ensemble des rapports qui sont produits par Agilitest sont customisables en modifiant des feuilles de style, et il est également possible d’avoir un rapport qui regroupe les échecs par différents critères afin de faciliter l’analyse.

Proposer des rejeux automatique de certains tests

Ce n’est pas une solution idéale mais il n’est pas rare d’avoir des instabilités liées à d’environnement ou avec des partenaires sur les plateformes de test. Dans ce cas les tests sont en échec pour de mauvaises raisons et doivent être rejoués. Il est donc préférable de les rejouer automatiquement dans ce cas.

Cela peut être notamment utile si vous avez eu des défaillances matérielles, et cela vous rassurera sur l’état de la qualité de votre logiciel. Il faut savoir qu’Agilitest est une solution robuste qui s’assure qu’il y a bien un cas d’échec du test avant de produire une erreur. Cela permet de réduire les faux-négatifs, tests qu’il est inutile d’analyser (flaky tests).

Ajouter les tests à l’intégration continue et les rendre bloquant

Cette pratique permet d’assurer l’efficacité des campagnes de régression. Si un test considéré comme bloquant est en échec le déploiement ne peut se faire ce qui force une analyse. Il faut alors faire attention aux flaky tests !

Dans l’absolu, si la campagne de tests n’a pas vocation a aboutir à un déploiement automatique, nous préconisons de rejouer l’ensemble des tests et ne pas s’arrêter au premier échec, de façon à avoir une vision plus complète de la qualité du logiciel.

L’outil Agilitest répond parfaitement à cette problématique en s’interfaçant très facilement avec des outils comme Jenkins, par le biais du standard TestNG.