L'automatisation des tests peut échouer pour de nombreuses raisons. Aujourd'hui, nous allons nous pencher sur l'une des principales causes de ces échecs, la robustesse des tests.
Le manque de robustesse des tests entraîne nécessairement l'échec de l'automatisation.
Tout d'abord, il est important de se rappeler ce qu'est un test "robuste". Un test est robuste si, lorsqu'il échoue, cet échec est dû à une erreur dans ce qu'il doit vérifier. Cet échec n'est pas dû à un problème tiers comme :
- environnement
- lié à un événement aléatoire
- causés par la modification des données
- causé par un temps d'affichage trop long
- connectivité avec les partenaires
- lié à toute autre cause externe...
L'analyse d'un cas d'échec faible est généralement assez facile car les problèmes sont souvent connus et récurrents. Cet échec entraîne alors une perte de temps dans l'analyse et peut même conduire à l'abandon de l'analyse de ce test lorsqu'il échoue. Une pratique courante avec les tests faibles est de les ré-exécuter avant l'analyse. Cela augmente le nombre d'exécutions et nécessite une vérification avant la ré-exécution. La vérification peut être manuelle ou automatique. Dans le second cas, elle nécessite le développement d'un outil supplémentaire. Dans tous les cas, la réexécution ne permet pas de garantir le succès des tests qui ont échoué. Pour pallier cette double exécution, Agilitest enregistre un fichier vidéo du déroulement des tests lorsqu'il a été rejoué, cela permet l'analyse immédiate des conditions d'échec.
Il est également bon de se rappeler que plus d'un test est exécuté dans une campagne de tests automatisés ! Enfin, j'aimerais vous rappeler qu'une bonne pratique en Agile (et encore plus avec une chaîne d'intégration continue) est de prévenir les livraisons lorsque les tests automatisés échouent.
La multiplication des tests entraîne une multiplication des risques d'échec d'un test par manque de robustesse. Cette probabilité de voir un ou plusieurs tests échouer, même si chaque test est considéré comme "plutôt robuste".
Prenons l'exemple d'une campagne de tests dont les tests peuvent être considérés à première vue comme "assez robustes" avec une robustesse de "98%" :
Comme vous pouvez le constater, même avec des tests robustes à 98 % pour une campagne particulièrement petite de 10 tests, un test échoue pour de mauvaises raisons dans plus d'un cas sur six (18 %).
Avec seulement 50 cas, le succès n'est garanti qu'une fois sur trois. A partir de 100, il est difficile de faire passer tous les tests.
Ces échecs répétés peuvent ensuite générer de nombreux problèmes qui conduisent à court ou moyen terme à de gros échecs comme :
- Ne plus bloquer les tests échoués
- Plus d'analyse des tests échoués : plus besoin de chercher chaque fois qu'un test échoue pour une mauvaise raison.
- Arrêtez de lancer des campagnes d'essai
- Reprise systématique qui devient très chronophage
Vous l'avez compris : pour assurer une véritable robustesse des campagnes de tests et donc une véritable efficacité de ces dernières, il est nécessaire de disposer de tests particulièrement stables dont la robustesse est proche de 100% !
Comment améliorer la robustesse des tests ?
Leproblème de la robustesse des tests est assez complexe à gérer car il dépend de nombreux paramètres. Néanmoins, il existe quelques bonnes pratiques qui permettent de l'augmenter considérablement. En voici quelques-unes :
Disposer d'environnements dédiés aux tests automatisés
Les échecs de tests dus à un environnement non contrôlé sont une cause d'erreur très courante. Un environnement totalement dédié et contrôlé assure le contrôle des données, un environnement à jour, un environnement non impacté par d'autres tests ou d'autres équipes. Cela réduit considérablement le caractère aléatoire et donc les risques d'échec.
Écrire des tests qui vérifient correctement les résultats
Un test automatisé est réalisé par un robot, et non par un humain. Certaines imprécisions acceptables avec un humain ne le sont pas avec un robot. Un test automatisé doit donc vérifier la présence d'un élément qui est unique et qui apparaît tout le temps sur cette page. Un élément qui permettra de s'assurer que le logiciel est bien dans l'état souhaité. Cela peut se faire par une combinaison de plusieurs éléments.
Agilitest est très bien pensé pour que la vérification soit pertinente et apporte une preuve suffisante grâce à son outil de capture. En effet, son outil de capture permet l'unicité mais aussi la recherche à un endroit particulier et, si besoin, la vérification d'images. En bref, c'est une fonctionnalité qui permet aux testeurs fonctionnels de créer des tests techniquement robustes.
Avoir une politique de création et de gestion des données bien définie
Les échecs dus à des données parasites ou manquantes sont particulièrement fréquents.
Voici un exemple pour vous convaincre :
Une application me permet de réserver des billets pour un concert. Je dispose de 10 billets. Je fais un test pour réserver un siège : il est réussi. Je fais ensuite un autre test pour acheter 10 places, le test échoue si la réservation du test précédent n'a pas été annulée.
L'adoption de processus stricts et bien encadrés est donc d'une grande aide pour améliorer la robustesse des tests.
Nous pouvons par exemple penser à la création et à la suppression de données directement dans chaque test.
Le lecteur pourra se référer à un autre article sur le sujet, qui traite de la gestion d'un grand volume de tests et donc de la robustesse.
.png)
