Les nouvelles tentatives ne corrigeront pas un mauvais localisateur 

Un test de connexion réussit le lundi, échoue le mardi, puis réussit à nouveau le mercredi. Personne n'a modifié le processus de connexion. Le seul changement réside dans l'ajout d'un conteneur par l'équipe de conception autour du bouton de connexion, ce qui a déplacé ce dernier d'un niveau plus bas dans l'arborescence des éléments de l'écran. La requête XPath pointant vers ce bouton a été écrite en fonction de l'ancienne structure. Selon la vitesse d'affichage de l'écran, la requête aboutissait parfois, parfois non. 

Voilà à quoi ressemble souvent un comportement instable dans une suite Appium. Ce n'est pas un mystère, mais un test qui dépend de détails de l'interface utilisateur qu'il n'était pas censé vérifier. 

La squame a plus d'une cause 

Un test instable est un test qui réussit et échoue sur le même code. À grande échelle, cela coûte cher. Atlassian indique que les tests instables représentent environ 15 % des échecs dans son dépôt backend Jira, entraînant des relances qui gaspillent plus de 150 000 heures de développement par an, et étaient responsables de jusqu'à 21 % des échecs de compilation de la branche principale dans Jira Frontend (Atlassian, 2025). 

Les causes se répartissent en deux catégories : 

• Causes testées. Localisateurs fragiles, pauses fixes au lieu d'attentes réelles, données de test partagées, dépendances d'ordre : ces éléments sont présents dans votre code, et vous pouvez les corriger. 

• Causes environnementales. Un appareil qui se déconnecte du réseau, un appel au serveur d'arrière-plan lent, une boîte de dialogue inattendue du système d'exploitation : ces éléments sont extérieurs à votre code. Vous pouvez les atténuer, mais pas les éliminer. 

Cette distinction est importante car les solutions diffèrent. Relancer un test avec un localisateur défectueux ne fait que reproduire l'échec plus lentement, voire pire, obtenir une réussite occasionnelle masquant le problème. Commencez par examiner vos propres éléments. Dans les tests d'interface utilisateur mobile, les localisateurs sont généralement le premier élément à vérifier. 

Pourquoi les localisateurs cessent-ils de fonctionner alors que l'application, elle, ne le fait pas ? 

Chaque étape Appium commence par la recherche d'un élément. Le localisateur est l'adresse utilisée par le test pour le trouver. Si cette adresse décrit la structure de l'écran plutôt que l'identité de l'élément, toute modification de la mise en page peut entraîner un dysfonctionnement. 

Les chercheurs appellent cela la fragilité du localisateur. Une étude de 2026 a analysé 359 dépôts open-source et reproduit 449 ruptures de localisateur : des cas où une modification structurelle de l’interface utilisateur a entraîné l’échec d’un test même si l’application fonctionnait toujours correctement (ReproBreak, ASE 2026Cette étude portait sur les frameworks de test web, mais le mécanisme est identique sur mobile. Renommer un élément, ajouter un conteneur, réorganiser une liste, et un localisateur basé sur la structure pointe vers un autre emplacement. 

Le mobile ajoute deux pressions supplémentaires : 

• Différences entre les plateformes. La même interface affiche une arborescence d'éléments différente sur iOS et Android, il est donc rare qu'une même expression XPath fonctionne sur les deux systèmes. 

• Rendu du temps. Le chargement des écrans mobiles est asynchrone. Un localisateur correct peut néanmoins échouer si le test effectue une recherche avant que l'élément n'existe, ce qui explique pourquoi les problèmes de localisateur et d'attente surviennent souvent simultanément. 

Les tests générés par l'IA font monter la pression 

Le volume de tests augmente plus vite que les équipes ne peuvent les examiner. On estime que 40 à 50 % du code d'entreprise est désormais généré par l'IA (Digital.ai), et une part croissante de code de test est également générée. 

L'équipe d'ingénierie de Slack a récemment exécuté des tests Playwright générés par l'IA sur des flux de travail réels. Les tests générés ont échoué environ 8 % du temps sur un flux simple et environ 48 % du temps sur un flux plus complexe. Slack a attribué ces échecs principalement à la variabilité de l'état de l'interface utilisateur et aux abstractions existantes qui interféraient avec le ciblage précis des éléments (Slack Engineering, 2026Il s'agissait d'une application web, pas mobile, mais la leçon reste la même : les tests générés héritent des habitudes de localisation qui leur sont imposées. Si personne ne vérifie la manière dont les éléments sont trouvés, une suite de tests plus étendue risque d'entraîner des recherches plus fragiles. 

Un ordre de localisation pratique pour Appium 

Les recommandations du projet Appium classent les stratégies de localisation dans cet ordre et considèrent XPath comme le dernier recours.: 

 

1. Identifiant d'accessibilité en premier. Elle est configurée délibérément par l'équipe de développement de l'application, elle est rapide à trouver et elle utilise la même stratégie sur iOS et Android. 
2. ID de ressource ou ID suivant. Stables tant que les développeurs ne les renomment pas. 
3. Requêtes natives de la plateforme lorsqu'aucun ID n'existe. Chaînes de prédicats et de classes iOS, ou UiAutomator Android. Plus précis que XPath, mais spécifique à la plateforme. 
4. XPath en dernier. Les recommandations d'Appium le décrivent comme lent et fragile. Si son utilisation est indispensable, privilégiez les expressions courtes et basées sur les attributs plutôt que sur les index. 

Habitudes qui stabilisent les localisateurs 

• Intégrez la testabilité à la définition de « terminé ». Demandez aux équipes de développement d'ajouter des identifiants d'accessibilité aux éléments interactifs. Cela améliore également l'accessibilité pour les utilisateurs finaux. 

• Centraliser les localisateurs. Conservez-les dans des objets de page ou des classes d'écran, afin qu'une modification de l'interface utilisateur ne nécessite qu'une seule modification, et non vingt. 

• Attendez les conditions, pas le temps. Remplacez les pauses fixes par des attentes explicites qu'un élément soit présent ou cliquable. 

• Examiner les localisateurs lors de la revue de code, y compris les tests générés. Une expression XPath contenant trois index est vouée à l'échec. 

• Suivre les échecs de recherche séparément. Si les erreurs d'élément introuvable se concentrent sur quelques écrans, c'est là que le nettoyage du localisateur porte ses fruits en premier. 

Réparez ce qui vous appartient, puis gérez ce qui ne vous appartient pas. 

Les localisateurs stables éliminent une grande partie des défaillances que vous pouvez contrôler. Ils ne suppriment pas celles qui ne le peuvent pas. Les appareils, les réseaux et les environnements continuent de produire des défaillances intermittentes ; la question est alors de savoir à quelle vitesse votre équipe peut les distinguer des véritables défauts sans relancer les tests manuellement. 

Voilà la seconde partie du problème de l'inconstance, et ce sera le sujet de notre prochain article : Les nouvelles tentatives sont faciles. Savoir ce qu'on vous a dit, en revanche, ne l'est pas..