Les nouvelles tentatives sont faciles. Savoir ce qu'on vous a dit, c'est une autre histoire. 

Si vous exécutez des tests Appium, vous pouvez déjà relancer un test ayant échoué. Des frameworks comme TestNG intègrent un analyseur de nouvelles tentatives. Les équipes JUnit ajoutent une extension ou un paramètre de plugin de compilation. Un ingénieur peut configurer cela en un après-midi. Il est donc légitime de se demander de quoi une équipe a encore besoin. 

La tentative de relance en elle-même n'est pas le plus difficile. Le plus difficile, c'est tout ce qui l'entoure : où se trouve la logique de relance, comment le reste de l'exécution est configuré et si quelqu'un peut voir ce qui s'est passé ensuite. 

Trois problèmes liés à une nouvelle tentative 

1. La logique de nouvelle tentative se trouve dans le code de test. Dans TestNG, les nouvelles tentatives sont gérées via un analyseur ou un écouteur. Dans JUnit, elles le sont via une extension ou une configuration de compilation. Chaque équipe choisit sa propre approche, et modifier le nombre de tentatives implique de modifier le code et de le recompiler.
2. Le reste de la configuration d'exécution se trouve ailleurs. Quel cloud utiliser, quelle version de l'application choisir, quels appareils utiliser, quels tests exécuter : ces éléments sont souvent répartis entre les capacités, les scripts d'intégration continue et les annotations. Lorsqu'une exécution se comporte différemment des attentes, la première étape consiste à identifier l'origine de chaque paramètre.
3. Les tentatives suivantes laissent peu de traces. Un test qui échoue une première fois puis réussit à la seconde est souvent perçu comme une réussite. L'échec peut figurer dans les résultats de la compilation locale, mais il n'apparaît pas dans le rapport de test, contrairement aux autres résultats. L'équipe a donc du mal à distinguer une réussite sans problème d'une réussite ayant nécessité une intervention, information qui révèle un test instable ou un environnement instable.

Aucun de ces éléments n'est alarmant pris individuellement. Ensemble, ils expliquent pourquoi une équipe qui a « déjà géré les nouvelles tentatives » passe encore la semaine de la mise en production à relancer les tests manuellement pour déterminer ce qui fonctionne réellement. 

Pourquoi cela devient-il plus cher à mesure que les suites s'agrandissent ? 

On estime que 40 à 50 % du code d'entreprise est désormais généré par l'IA (Digital.aiPlus de code signifie plus de risques de défaillances, et les suites de tests s'allongent en conséquence. 

Les tests instables constituent un coût connu à grande échelle : Atlassian attribue environ 15 % des échecs de son dépôt backend Jira à des tests instables, les exécutions répétées entraînant un gaspillage de plus de 150 000 heures de développement par an (Atlassian, 2025). 

Si vous êtes encore en train de régler les localisateurs et les temps d'attente, commencez par Les nouvelles tentatives ne corrigeront pas un mauvais localisateurCe qui suit concerne les échecs qui subsistent après cela. 

Orchestrateur de tests : une couche intermédiaire pour l’exécution des tests 

Test Orchestrator dans Digital.ai Les tests se situent entre vos tests Appium et le Digital.ai Plateforme de test. Elle gère l'exécution des tests et relance automatiquement les tests en cas d'échec, sans modifier les tests eux-mêmes ni redémarrer manuellement la compilation. Il s'agit d'un agent Java distribué sous forme de fichier JAR. Vous l'ajoutez à votre projet de test existant et l'utilisez lors de l'exécution des tests. 

Un seul fichier YAML pour l'exécution. La connexion au cloud, l'application, la sélection de l'appareil, les tests à exécuter et le nombre de tentatives en cas d'échec sont tous gérés par une configuration centralisée basée sur YAML. Le nombre de tentatives est une valeur de configuration, et non une modification du code ; tous les paramètres d'exécution sont ainsi regroupés au même endroit. 

Vous pouvez voir les nouvelles tentatives. Lorsqu'un test ayant échoué est relancé, chaque tentative et son résultat sont visibles dans Test Reporter. L'équipe peut ainsi identifier les échecs répétés, les tests réussis lors de la nouvelle tentative et déterminer si un test critique a interrompu l'exécution. Une réussite à la deuxième tentative n'est plus indiscernable d'une réussite complète. 

Vos tests restent inchangés. Vous ajoutez Test Orchestrator comme couche intermédiaire. Les méthodes de test existantes restent inchangées. Compatible avec JUnit et TestNG, il s'intègre aux pipelines CI/CD comme contrôle qualité et est disponible pour les clients SaaS et sur site. 

Ce qui change au jour le jour 

• Ingénieurs QA Passez moins de temps à relancer manuellement les tests ayant échoué pour déterminer si une erreur se reproduit. En cas d'échec, les tentatives consignées dans Test Reporter offrent un point de départ plus clair. 

• responsables de l'assurance qualité Il est essentiel de savoir ce qui nécessite une attention particulière avant la validation de la version. Les échecs répétés font l'objet d'une enquête approfondie, les tests ayant réussi après une nouvelle tentative sont suivis et un test critique ayant interrompu l'exécution est facilement repérable, ce qui permet à l'équipe de ne pas traiter systématiquement tous les échecs de la même manière. 

Quand une nouvelle tentative du framework est suffisante 

Si votre suite de tests est restreinte, gérée par une seule équipe, et qu'un simple résultat (succès ou échec) dans la console suffit, un analyseur de nouvelles tentatives peut s'avérer suffisant. Test Orchestrator est conçu pour les équipes disposant d'un nombre suffisant de tests automatisés pour que l'analyse des échecs et la réexécution des tests individuels soient réalisées en temps réel à chaque version. 

Cela ne supprime pas non plus la cause d'un test défaillant. Un test qui réussit à la deuxième tentative fournit toujours une information, qu'il s'agisse d'un environnement instable ou d'un localisateur qui commence à dériver. L'important est que le signal reste visible, afin que vous puissiez agir en conséquence. 

De « est-ce que ça a fini par passer » à « que s'est-il passé à chaque tentative ? » 

Ajouter une nouvelle tentative prend un après-midi. Comprendre les résultats de ces nouvelles tentatives et gérer la configuration de chaque exécution est la partie qui se complexifie à mesure que les suites de tests s'étoffent. Test Orchestrator centralise ces deux aspects et vous permet de laisser vos tests en toute tranquillité. 

En savoir plus dans le Documentation de Test Orchestrator.