Préambule
Les flaky tests… ce nom peut vous être inconnu mais sachez qu’il fait faire des cauchemars à de nombreux testeurs! Car les flaky tests peuvent vite devenir la pire hantise des professionnels de la qualité… En effet, les flaky tests retournent l’outil principal de mesure de la qualité (les tests) des professionnels de la qualité contre eux en rendant ces chers tests imprévisibles avec un même test pouvant être correct, faux-positif ou faux-négatif selon les exécutions ou les conditions d’exécution!
Présentation des flaky tests
Bon, j’arrête là le parallèle entre flaky tests et monstre pour en revenir à du plus factuel et du plus concret.
Comme décrit précédemment les flaky tests sont des tests qui ne donnent pas le même résultat selon les exécutions et dont les différences de résultat ne sont pas forcément liées à un bug. Pour faire simple les flaky tests sont des tests peu fiables ce qui est particulièrement problématique pour quelque un test qui, par essence, est censé donner de la confiance.
Il pourrait être simple de se dire qu’il suffit de fiabiliser ces tests malheureusement cela n’est pas si simple… d’ailleurs si c’était le cas cela ne ferait pas l’objet d’un article spécifique! Un des problèmes des flaky tests c’est qu’il est souvent difficile d’identifier la (ou les) source(s) de cette instabilité ou mêe lorsque l’on réussi à l’identifier d’implémenter un moyen d’éviter cette problématique.
Les impacts des flaky tests
Outre le problème majeur de confiance, les flaky tests posent énormément de problèmes.
Il y a par exemple les problèmes de perte de temps liés aux faux positifs. En effet, un test en échec demandant du temps d’analyse, si cette analyse conduit à l’absence de bug mais un test non stable et que cela arrive régulièrement cela entraine une perte de temps assez conséquente.
Il y a également les problèmes de manque de confiance. La présence de flaky test fait peser un doute légitime sur la fiabilité des autres tests de la campagne. On voit facilement les faux-positifs mais beaucoup moins les faux-négatifs. La présence de nombreux potentiels faux positifs entraîne une probabilité non négligeable de faux négatifs et donc de tests en succès alors qu’ils ne devraient pas l’être. De même, à force de voir les mêmes tests en échec sans bonne raison on ne fait plus confiance aux tests et cela peut entrainer un manque d’investigation. Au final on n’a plus confiance dans le résultat des campagnes.
Un autre problème, est beaucoup plus lié à l’automatisation qui, de manière générale est plus sensible aux flaky tests. Je pense ici aux tests inclus dans les chaînes d’intégration continue. Les flaky tests engendrent 2 problématiques possibles: le rejet régulier de livraisons pour de mauvaises raisons… ou le fait de ne plus considérer certains tests en échec comme bloquant et donc un compromis sur la qualité.
Dans le cas de l’intégration continue il est primordial d’avoir des tests fiables à près de 100%. Pour vous en convaincre je vous propose de voir le % de chance qu’aucun test ne soit en échec dans une campagne en fonction du nombre de tests de la campagne et de leur probabilité de fonctionner de la manière prévue:
Présentation rapide du tableau:
- Sur la première colonne vous avez: le nombre de tests dans la campagne
- Sur la première ligne la probabilité de succès de chaque test
- Dans chaque case la probabilité d’absence de test en échec en raison de l’instabilité
Comme vous pouvez le voir même avec des tests qui semblent relativement stable on tombe très vite sous les 90% de chance de n’avoir que des résultats fiables. Une chaîne d’intégration continue se retrouve alors très vite à toujours être en échec.
Attention, il me semble quand même important de relativiser ce tableau très théorique. Dans les faits il est plutôt rare d’avoir uniquement des flaky tests dans une campagne de 100 tests ou plus. En général les flaky tests sont assez vite identifiés et représentent une minorité des tests de la campagne. On peut par contre imaginer une campagne de 100 tests avec 5 flaky tests ayant chacun 15% de chance d’être en échec. Le calcul à faire pour connaitre la probabilité qu’aucun de ces tests ne soit en échec pour de mauvaises raisons est alors 0.85^5 ce qui est environ égal à 44% de chance uniquement mais qui reste mieux qu’avec 100 tests à 99% de chance de réussite (37%). De même cela diminue le travail effectif à réaliser car seuls 5 tests doivent vraiment être retravaillés pour améliorer considérablement la fiabilité de la campagne.
Comment sont engendrés les flaky tests et comment les éviter ?
Il y a plusieurs raisons qui engendrent des flaky tests et le travail à faire dépend de ces raisons. Voici une liste non exhaustive de raisons engendrant des flaky tests:
- Avoir des tests mal conçus: on est ici sur une des bases du travail du testeur! On peut notamment penser à des tests qui vérifient des éléments qui ne sont pas toujours présents ou qui ne vérifient pas vraiment ce que l’on souhaite. On peut par exemple rechercher la présence d’un mot (comme le mot Bus) sur une page alors que ce mot est toujours présent sur cette page (ex: avec Business) ou que ce dernier n’est pas toujours affiché car d’autres trajets en train ou avion sont proposés et qu’il faut appuyer sur « afficher plus » pour télécharger le trajet
- Avoir des tests dépendant d’une date ou de données: on peut par exemple décider d’acheter 10 fois le même produit sur une « marketplace » sans s’assurer du stock. On peut imaginer que le test est là pour s’assurer d’une rupture de stock ou que l’on puisse acheter plusieurs fois le même produit voire même avoir une réduction à partir de 10 produits. Le problème c’est que le résultat est différent s’il reste 9 ou 11 produits. Afin d’éviter ce type de problème il faut s’assurer en amont du test (cela peut se faire lors de la conception avec des produits illimités comme des achats virtuels ou en prérequis des test avec une vérification du stock ou même la création du stock nécessaire au test) de la présence des données nécessaires.
- Avoir des tests trop sensibles à la performance ou trop lents: cette problématique tend à être moins présente grâce à des bonnes pratiques (notamment l’utilisation de WaitUntil). Mais j’ai régulièrement eu des tests en échecs car le chargement de la page était 1 seconde trop long ou alors que l’exécution prenait trop de temps et que certains paramètres se retrouvaient ne plus être valables. Afin d’éviter ces problèmes il faut réussir à bien optimiser le temps d’exécution en attendant le temps qu’il faut mais pas plus et potentiellement en divisant certains tests en plusieurs tests.
- Avoir des tests trop dépendants de paramètres extérieurs: avec par exemple le passage par un ou plusieurs partenaires extérieurs qui doivent renvoyer certaines réponses d’une certaine manière mais qui ne sont pas forcément stables. Dans ce cas il existe des solutions de bouchonnage qui ont un intérêt mais aussi l’inconvénient d’isoler nos tests et donc de diminuer l’intégration.
- Des instabilités de l’automate de test: il peut alors être intéressant de revoir l’architecture de ce dernier
- Une utilisation en parallèle du même environnement: un test se doit d’être exécuté dans certaines condition sur un environnement spécifique. L’accès concurrentiel d’autres tests faits en parallèle ou d’autres équipes peut engendre de nombreuses modifications. On peut penser par exemple à une équipe gérant l’inventaire de chambres d’hôtels et une autre proposant les réservations. Si une équipe fait passer l’inventaire à 0 alors que la seconde veut réserver une chambre à la même date on a alors un test en échec. Il y a plusieurs manière de régler ce type de problème. La virtualisation est évidemment une solution mais n’est pas toujours possible. On peut alors envisager de mettre en place de moyens de gestion des environnements comme une identification des données (ex: les hôtels de Paris pour la première équipe et de Lyon pour la deuxième) ou des créneaux liés aux différentes équipes.
Je n’ai proposé ici que des erreurs courantes engendrant des flaky tests. La réalité est évidemment plus complexe mais commencer par les cas facile permet généralement de supprimer un nombre assez important de tests défectueux. De même les raisons sont souvent multiples et il s’avère important de jouer sur plusieurs tableaux.
Conclusion
Les flaky tests sont une plaie qui pose de nombreux problèmes qui peuvent aller, dans des cas extrêmes, jusqu’à remettre en question l’intérêt de certains tests. De manière plus générale, ces tests qui impactent principalement les tests automatisés, font perdre beaucoup de temps, de confiance et impactent la qualité. Ils ne sont cependant pas une fatalité et il est possible de lutter contre. Pour cela il y a de nombreuses bonnes pratiques disponibles et il faut réussir à identifier les raisons de ces flaky tests pour apporter une réponse appropriée.
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.
