L'automatisation des tests peut échouer pour de nombreuses raisons. Aujourd'hui, nous allons nous intéresser à une cause récurrente de ces échecs, le manque d'analyse des tests après leur relecture.
L'absence d'analyse automatisée des tests après relecture entraîne l'échec de l'automatisation.
La mise en place de tests automatisés permet de diminuer le coût d'exécution et la mise en place d'une très bonne pratique de test, qui est un des principes du test : " les tests précoces ".
Tester plus fréquemment est une des raisons pour lesquelles il est conseillé d'automatiser ses tests. Néanmoins, la multiplication des campagnes de tests est inutile si les résultats de ces campagnes et plus particulièrement les tests exécutés lors de ces campagnes ne sont pas analysés. En fait, ne pas analyser les campagnes de tests est encore pire que de ne pas les exécuter du tout, car l'exécution seule donne l'illusion que la qualité est assurée alors qu'elle ne l'est pas.
Enfin, vous pouvez avoir des campagnes de test exécutées plusieurs fois par jour mais jamais analysées, car le temps d'analyse de chaque campagne peut prendre plusieurs heures. Cela conduit à un cercle vicieux où les tests automatisés ne garantissent plus rien car leurs résultats ne sont plus analysés et les livraisons se font dans tous les cas. Cela conduit au déploiement de versions 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 tests sont gratuites. Ce n'est malheureusement pas le cas. Seule l'exécution des tests est quasiment gratuite avec l'automatisation, l'exécution elle-même n'est qu'une partie de la campagne de test comme nous pouvons le voir avec cet exemple :
Multiplier les exécutions signifie multiplier les analyses et le coût de l'analyse des tests ratés est loin d'être gratuit. Cette analyse peut être plus coûteuse avec une campagne automatisée qu'avec une campagne manuelle, pour la simple raison qu'il n'y a pas d'œil humain derrière l'exécution.
Pour éviter ce problème, il est possible de mettre en œuvre quelques bonnes pratiques :
Comment éviter le problème de la non-analyse des campagnes de tests automatisés ?
Pour éviter ce problème, il est évidemment nécessaire d'analyser les résultats de chaque campagne, de savoir pourquoi chaque test a échoué et de 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 pourquoi l'équipe peut mettre en place plusieurs bonnes pratiques :
Limiter le nombre de tests dans les campagnes
Le coût de l'analyse d'une campagne de tests doit être maintenu à un niveau que l'équipe peut se permettre. Plus il y a de tests, plus l'analyse est coûteuse. Il est donc parfois nécessaire d'effectuer moins de tests. Cela peut se faire de plusieurs manières, par exemple en créant plusieurs campagnes, en adaptant les tests à exécuter en fonction des campagnes ou en maintenant moins de tests.
Limiter le nombre de reprises de la campagne
Une analyse doit être faite après chaque campagne. Il est préférable de faire 1 campagne par jour et de l'analyser que 3 campagnes sans l'analyser.
Mettre en place des systèmes pour faciliter l'analyse des tests échoués
Ceci est particulièrement important pour l'automatisation des tests. Les tests doivent être capables de fournir des preuves de ce qui s'est passé et pas seulement un état. Lorsque le testeur analyse le test, il doit être en mesure de savoir ce qui s'est passé, comment le reproduire et comprendre la raison de l'échec.
Agilitest fournit des outils pour cette facilitation avec des vidéos ou des captures d'écran pour chaque étape et échec du test. Vous pouvez trouver un rapport complet de la campagne de test, incluant vidéo, html et pdf pour chaque test.
Tous les rapports produits par Agilitest sont personnalisables, et il est également possible d'avoir un rapport qui regroupe les échecs par différents critères pour faciliter l'analyse.
Les rapports HTML en particulier vous permettent de sauter directement dans Agilitest pour éditer la ligne défectueuse, réduisant ainsi le coût de maintenance .
Proposer la reprise automatique de certains tests donnés
Ce n'est pas une solution idéale mais il n'est pas rare d'avoir des instabilités liées à l'environnement ou aux partenaires sur les plateformes de test. Dans ce cas, les tests échouent pour de mauvaises raisons et doivent être rejoués. Il est donc préférable de les rejouer automatiquement dans ce cas, ce qui peut être utile si vous avez eu des défaillances matérielles, et cela vous rassurera sur la qualité de votre logiciel.
Il est important de noter qu'Agilitest est une solution robuste qui garantit qu'il y a un échec du test avant de produire une erreur. Cela réduit les faux négatifs, les tests qui sont inutiles à analyser (flaky tests).
Ajouter des tests à l'intégration continue et les rendre bloquants
Cette pratique garantit l'efficacité des campagnes de régression. Si un test considéré comme bloquant échoue, le déploiement ne peut avoir lieu, ce qui oblige à une analyse.
Dans l'absolu, si la campagne de tests n'a pas vocation à déboucher sur un déploiement automatique, nous recommandons de rejouer tous les tests et de ne pas s'arrêter au premier échec, afin d'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 tels que Jenkins, via le standard TestNG
.png)
