Les raisons de l’échec de l’automatisation des tests : le manque de robustesse

par Marc Hage Chahine | 24 février 2021

L’automatisation des tests peut échouer pour de nombreuses raisons. Nous allons aujourd’hui nous pencher sur une des causes majeures de ces échecs, la robustesse des tests.

Le manque de robustesse des tests aboutit nécessairement à l’échec de l’automatisation.

Avant toute chose est important de rappeler ce qu’est un test « robuste ». Un test est robuste si, quand il est en échec, cet échec est dû à une erreur dans ce qu’il devait vérifier. C’est à dire que cet échec n’est pas du à un problème tiers comme des problèmes:

  • d’environnement
  • liés à un événement aléatoire
  • engendrés par des données changeantes
  • causés par un temps d’affichage trop long
  • de connectivité avec des partenaires
  • liés à toute autre cause externe…

L’analyse d’un cas en échec peu robuste est généralement assez facile car les problèmes sont souvent connus et récurrents. Cet échec cause alors une perte de temps dans l’analyse et peu même pousser à un l’abandon de l’analyse de ce test lorsqu’il est en échec. Une pratique répandue avec les tests peu robustes est la ré-exécution avant analyse de ces derniers. Cela augmente le nombre d’exécutions et demande une vérification avant la relance. La vérification peut être manuelle ou automatique. Dans le second cas cela demande de développer un outil supplémentaire. Dans tous les cas, le rejeu n’assure pas une réussite des tests en échec. Pour palier à cette double exécution, Agilitest enregistre une vidéo complète du déroulement des tests lorsqu’il est rejoué, cela permet de faire l’analyse immédiate des conditions d’échec.

Il est également bon de rappeler que l’on exécute plus qu’un test dans les campagnes de tests automatisés! Enfin, je tiens à rappeler qu’une bonne pratique en Agile (et encore plus avec une chaîne d’intégration continue) est d’empêcher les livraisons quand des tests automatisés sont en échec.

La multiplication des tests engendre une multiplication des risques d’échec d’un test par manque de robustesse. Cette probabilité d’avoir un ou plusieurs tests en échec et ce même si séparément on considère chaque test comme « plutôt robuste ».

Prenons l’exemple d’une campagne de tests avec des tests que l’on peut considérer au premier abord comme « assez robuste » avec une robustesse de « 98% »:

Nombre de testsProbabilité de succès si aucun bug détecté
1082%
5036%
10013%
2500.6%
Probabilité de succès si aucun bug détecté

Comme vous pouvez le constater, même avec des tests robustes à 98% pour une campagne particulièrement restreinte de 10 tests, un test est en échec pour de mauvaises raisons dans plus d’un cas sur 6.

Avec seulement 50 cas le succès n’est garanti qu’une fois sur trois. A partir de 100 il faut mieux oublier l’idée d’avoir tous ses tests en succès.

Ces échecs répétés peuvent alors engendre de nombreux problèmes qui entrainent à court ou moyen terme de gros échecs comme:

  • Ne plus rendre bloquant les tests en échecs
  • L’absence d’analyse des tests en échec: pas besoin de regarder à chaque fois que c’est en échec c’est pour une mauvaise raison
  • L’arrêt des exécutions des campagnes de test
  • De rejeux systématiques qui deviennent très chronophages

Vous l’avez compris, afin d’assurer une vraie robustesse des campagnes de tests et donc une vraie efficience de ces dernières il faut avoir des tests particulièrement stables dont la robustesse frise avec les 100%!

Comment améliorer la robustesse de ses tests ?

Le problème de robustesse des tests est un problème assez complexe à gérer car il dépend de très nombreux paramètres. Néanmoins, il existe quelques bonnes pratiques qui permettent d’augmenter considérablement cette dernière. En voici quelques unes:

Avoir des environnements dédiés aux tests automatisés

Les échecs de test liés à un environnement non maitrisé est une cause d’erreur très fréquente. Une environnement totalement dédié et maitrisé permet d’assurer une maitrise sur les données, un environnement à jour, un environnement non impacté par d’autres tests ou d’autres équipes. Cela réduit considérablement l’aléatoire et donc les chance d’échec

Écrire des tests qui vérifient correctement les résultats

Une tests automatisé est exécuté par un robot et non 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 apparait tout le temps sur cette page. En bref un élément qui est une preuve suffisante pour assurer que le logiciel est effectivement dans l’état souhaité. Cela peut être fait avec la combinaison de plusieurs éléments.

Agilitest est d’ailleurs très bien pensé afin d’assurer que la vérification est pertinente et remonte une preuve suffisante grâce à son outil de capture. En effet, son outil de capture permet d’assurer l’unicité mais aussi de recherche à un endroit particulier et, si besoin, de la vérification d’image. Bref, c’est une fonctionnalité qui permet à des testeurs fonctionnels de créer des tests techniquement robustes

Avoir une politique de gestion et de création de données bien définie

Les échecs liés à des données parasites ou absentes sont particulièrement courants.

Voici un exemple pour vous convaincre. J’ai une application qui permet de réserver des billets pour un concerts. J’ai 10 places pour ce concert. Je fais un test pour réserver une place: il est en succès. Je fais ensuite un test pour acheter 10 places, le test est en échec si la réservation du test précédent n’a pas été annulée.

Adopter des processus strictes et bien cadrés est donc d’une grande aide pour améliorer la robustesse des tests.

On peut 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 gros volume de tests et donc de robustesse.