Ce test est-il instable, ou s'agit-il d'un véritable bug ?

Un test instable échoue puis réussit lors d'un rejeu sans que personne n'ait rien corrigé, tandis qu'un véritable bug échoue pour une raison qu'aucune tentative ne saurait modifier. Nexus Studio, développé par Verdict System LLC, fait la distinction en consignant chaque rejeu : FLAKY pour un échec résolu par un rejeu, BREACHED pour une anomalie avérée, et BREACHED_FLAKY pour un échec lui-même inconstant. Une tentative supplémentaire ne transforme jamais un défaut en exécution réussie.

Par l'équipe Nexus Studio, Verdict System LLC. 7 octobre 2026.

Qu'est-ce qu'un test instable (« flaky test ») ?

Un test instable (flaky) est un test dont les tentatives ne concordent pas : il échoue une fois puis réussit lors d'un autre essai, sans modification du code ni du test. Dans Nexus Studio, ce mot a un sens précis. FLAKY désigne un test qui a échoué, puis a réussi lors d'une nouvelle tentative, sans qu'aucun élément n'ait été réparé. Quelque chose est instable, dans l'application ou dans le test, et rien n'a été corrigé.

Un échec franc qui se produit à chaque tentative n'est pas instable, même lorsque l'étape d'auto-réparation a tenté sans succès de réparer un sélecteur. Une version antérieure du moteur classait ce cas comme FLAKY. Les équipes interprétant FLAKY comme « le test est mauvais » passent à autre chose, de sorte qu'une application défaillante était livrée sous forme de bruit. Le moteur ne procède plus ainsi.

Les nouvelles tentatives masquent-elles de véritables bugs ?

C'est possible, et la raison en est le nombre d'états. Avec seulement succès et échec, une nouvelle tentative qui réussit fait passer au vert une exécution rouge, et un défaut intermittent dans l'application devient invisible. Il s'agit de l'un des types de bugs les plus coûteux à identifier. Lorsque le rouge peut également signifier une coupure réseau ou un plantage du navigateur, l'équipe prend l'habitude de relancer les échecs au lieu de les analyser, et la suite de tests perd sa crédibilité.

Nexus Studio maintient la nouvelle tentative visible. Un test qui a échoué puis réussi n'est pas SECURE. Il renvoie le code 0 en CI, de sorte qu'il n'interrompt pas le build, mais il apparaît dans le rapport et dans l'Historique sous le statut FLAKY, un succès avec réserve. Consultez comment les 14 verdicts sont décidés pour connaître l'ordre complet des vérifications.

Quelle est la différence entre FLAKY, BREACHED et BREACHED_FLAKY ?

• FLAKY : a échoué, puis une nouvelle tentative l'a fait réussir, sans qu'aucune réparation n'ait été effectuée. Consultez le fichier raw-data.json de la tentative échouée, puis la tendance dans l'Historique. Il renvoie le code 0.
• BREACHED : le test a échoué sur une seule tentative, et aucun modèle d'environnement ou de banc d'essai n'explique l'erreur. Une assertion a échoué. Il s'agit du signalement de bug, et il renvoie le code 1.
• BREACHED_FLAKY : le test a échoué lors de sa dernière tentative après une nouvelle tentative antérieure, et aucun modèle d'environnement ou de banc d'essai ne l'explique. L'échec lui-même est incohérent. Comparez les tentatives avant de signaler un bug. Il renvoie le code 1.

Deux verdicts voisins garantissent l'exactitude de la situation. AUTO_RECOVER est un succès où l'auto-réparation a remplacé un sélecteur : le localisateur de l'auteur est donc obsolète et le test n'est pas intègre. Une première tentative qui a échoué uniquement en raison du temps imparti, puis a réussi lors de la nouvelle tentative, est classée SECURE, car cela met en évidence de la latence, non une instabilité.

Avant qu'un échec ne puisse être qualifié de BREACHED ou BREACHED_FLAKY, le classificateur élimine les autres explications dans un ordre fixe : une erreur de banc d'essai, un crash, un blocage, un hôte inaccessible et un délai d'attente dépassé (timeout). Seul un échec qu'aucune de ces causes n'explique constitue un incident avéré. C'est pourquoi un dépassement de délai ou un CAPTCHA ne se traduit pas par un signalement de bug.

Comment les nouvelles tentatives sont-elles comptabilisées ?

Le moteur lit le numéro de tentative de l'exécution. Un test réussi dont le nombre de nouvelles tentatives est supérieur à zéro est FLAKY, à moins qu'un sélecteur n'ait été réparé, auquel cas il est classé AUTO_RECOVER. Un test en échec ou ayant dépassé le délai imparti, avec un nombre de nouvelles tentatives supérieur à zéro et aucune explication liée à l'environnement, est BREACHED_FLAKY. Un succès net nécessite un nombre de nouvelles tentatives égal à zéro et aucun sélecteur réparé.

FLAKY signifie que les tentatives n'ont pas concordé, et rien d'autre. Un échec sur une seule tentative, avec zéro nouvelle tentative, n'est jamais étiqueté comme instable. Chaque ligne d'Historique enregistre également retry_attempt et attempts, afin que le décompte reste associé à l'exécution.

Quelles preuves chaque verdict laisse-t-il ?

• FLAKY : screenshot.png, metadata.json et raw-data.json. Le dossier conserve le fichier raw-data.json de la tentative ayant échoué, de sorte qu'une nouvelle tentative ayant masqué l'échec laisse tout de même son journal. Cela suit le paramètre Conserver les preuves d'une réussite FLAKY / AUTO_RECOVER, activé par défaut.
• BREACHED_FLAKY : report.md, metadata.json, raw-data.json et screenshot.png, et sa vidéo d'échec est conservée par défaut.
• BREACHED : les mêmes fichiers, avec la vidéo conservée par défaut.

Le verdict se trouve dans le nom du dossier de preuves, par exemple un nom qui se termine par [BREACHED]. La page Preuves suit un test ayant échoué à travers chaque fichier.

Comment l'Historique repère-t-il un test instable ?

L'Historique conserve une ligne par exécution pour chaque test et navigateur ou appareil, avec le verdict, la tentative de relance et la signature de l'erreur. À partir de ces lignes, il affiche les tendances par session, jour ou semaine : En régression, Rétabli, Toujours en échec et Plus lent. Un test qui passe au vert, au rouge puis à nouveau au vert y apparaît au lieu de disparaître dans les réexécutions.

Le classement des risques, dans l'Evidence Locker et dans Patrol, classe les tests selon la fréquence à laquelle ils oscillent, échouent ou font perdre du temps. Il affiche également un risque prédit à partir d'une régression logistique sur votre historique, avec un recours à l'EWMA lorsque les données sont limitées. Rien n'est qualifié d'instable en dessous de cinq exécutions, car une ou deux exécutions ne peuvent pas révéler de tendance.

Limites

• Les tentatives de rejeu (« retries ») séparent FLAKY de SECURE, et BREACHED_FLAKY de BREACHED. Sans ces tentatives, un échec intermittent est considéré comme un BREACHED.
• FLAKY indique que les tentatives n'ont pas donné le même résultat. Cela n'en indique pas la raison. Trouver la cause dans l'application ou dans le test reste le travail d'une personne.
• La classification analyse le texte de l'erreur, de sorte qu'un message d'assertion personnalisé contenant des termes tels que 403 ou Forbidden peut être interprété comme un problème d'environnement. Ouvrez metadata.json lorsqu'un verdict vous surprend.
• En dessous de cinq exécutions, l'Historique et le classement des risques ne qualifient rien d'instable.

Où aller ensuite

La page Preuves montre chaque fichier laissé par un test ayant échoué, et Comment Nexus Studio détermine 14 verdicts de test explique l'ordre des vérifications. La version d'essai de 30 jours exécute le même moteur sur vos propres tests.

Pour exécuter d'abord la vérification sur votre propre machine, Comment distinguer un vrai bug d'un test instable ? propose un exemple exécutable.