Come riprodurre un bug, e cosa fare con quelli che non si riescono a riprodurre

Lo stato “Cannot reproduce” (“non riproducibile”) è il modo più comune in cui una segnalazione di bug si arena, ed è utile leggere questa espressione con attenzione, perché non dice quello che si pensa dica. Non è un’affermazione sul bug. È un’affermazione su due ambienti: quello di chi lo ha visto, dove è accaduto, e quello di chi lo verifica, dove non è accaduto.

Il bug non è in discussione: qualcuno lo ha visto accadere. Quello che è in discussione è se sia possibile ricreare le condizioni che lo hanno causato, e nella maggior parte dei casi la segnalazione non le contiene, perché chi l’ha scritta non aveva idea di quale, tra le mille cose che lo circondavano, fosse quella rilevante.

Cosa serve davvero per una riproduzione

I passaggi sono solo una delle quattro cose necessarie, ed è quella a cui pensano tutti.

Gli stessi passaggi. Che cosa è stato cliccato, in che ordine, a partire da un punto dal quale sia possibile ripartire anche per chi indaga.

Lo stesso stato. L’account, i permessi, i feature flag, le impostazioni modificate diciotto mesi prima, la bozza a metà rimasta nel database. È l’elemento che manda in fumo la maggior parte dei tentativi, perché lo stato è invisibile a chi ci vive dentro. Non sa che il proprio account è fuori dal comune: per chi lo usa è semplicemente il proprio account.

Gli stessi dati. Non un record di test appena creato, ma quello specifico: l’ordine con un rimborso associato, il nome con un apostrofo, la lista vuota, il caricamento da quaranta megabyte. I dati di seed sono ordinati. I dati di produzione sono quindici anni di decisioni, lo stesso scarto che fa mentire l’ambiente di staging.

Lo stesso ambiente. Browser e build, dispositivo, rete, dimensione dello schermo, orologio di sistema, estensioni. Anche solo la versione può bastare: “l’ultima versione di Chrome” è stata tre major version diverse nel giro di una settimana.

Quattro assi, e una segnalazione di norma ne fissa uno solo. Il lavoro di riproduzione consiste nell’indovinare gli altri tre, ed è per questo che richiede un intero pomeriggio e finisce così spesso in un’alzata di spalle.

Partire dallo stato, non dai passaggi

L’istinto porta a seguire i passaggi e vedere cosa succede. La mossa migliore, invece, è chiedersi cosa dovrebbe essere vero perché quei passaggi falliscano.

Se il checkout si rompe nella fase di pagamento, i passaggi sono tre clic che chiunque può fare. Quello che non è universale è il carrello, l’indirizzo, il metodo di pagamento, la valuta, se su quell’account sia mai stato effettuato un rimborso. Capire quale di questi elementi possa cambiare l’esito trasforma una segnalazione vaga in tre o quattro esperimenti precisi.

Debole

Seguiti i passaggi su un account di test. Funziona tutto. Chiuso come non riproducibile.

Migliore

I passaggi funzionano su un account nuovo. L'account di chi ha segnalato il bug ha una carta salvata in una valuta che non supportiamo più, e l'errore è nella ricerca della valuta. Riprodotto aggiungendone una a un account di test.

La seconda versione non richiede più sforzo. È lo stesso sforzo indirizzato alla domanda giusta.

Ridurre la riproduzione al minimo che continua a fallire

Una volta che il fallimento è affidabile, si può iniziare a togliere pezzi. Rimuovere un passaggio, rimuovere un campo, usare un file più piccolo, disattivare un’estensione, ridurre i dati. Ogni rimozione o mantiene il fallimento, e allora quel pezzo non era necessario, oppure lo fa sparire, e allora si è appena trovato qualcosa di rilevante.

Vale la pena farlo anche quando la correzione è già pronta, per due motivi. Una riproduzione minima è un test case che si può conservare. E l’atto stesso di ridurre trova spesso la causa prima ancora di aver guardato il codice: il bug che sopravvive solo quando la lista è vuota sta già dicendo cos’è.

Attenzione alla riproduzione che funziona solo a volte. Non è una riproduzione fallita, è una forma diversa di bug, e l’intermittenza è un dato, non rumore: c’è una race condition, oppure una dipendenza dall’ordine, oppure una cache fredda. Vale qui la stessa logica per cui un test flaky merita di essere indagato piuttosto che semplicemente rilanciato.

I bug che non si possono riprodurre per costruzione

Alcuni fallimenti non possono essere ricostruiti sulla propria macchina, e nessuna dose di ostinazione lo cambia. Riconoscerli in anticipo vale più che insistere.

Serviva il loro orologio. Un dispositivo con l’ora sbagliata produce errori di certificato, sessioni scadute e timestamp impossibili. Erano tre delle cinque cause dietro un avviso di certificato.

Serviva la loro rete. Un proxy aziendale, un filtro DNS, un captive portal, un operatore mobile che riscrive le richieste. Non è possibile collegarsi a quella rete, quindi non è possibile vedere cosa fa.

Serviva la loro build. Un rollout graduale ha messo una parte degli utenti su una versione che nessun altro ha, nemmeno chi indaga.

Serviva quel momento preciso. Un deploy a metà, una cache fredda, un servizio di terze parti lento per novanta secondi. Lo stato che lo ha causato ha smesso di esistere prima ancora che la segnalazione fosse scritta.

Servivano le loro estensioni. Qualcosa iniettato nella pagina l’ha modificata. Chi indaga ne ha di diverse, quindi vede una pagina diversa.

In questi casi la domanda non è “come lo riproduco” ma “cosa era vero in quel momento, e posso ancora scoprirlo?”

Il che è un argomento a favore della cattura, invece della riproduzione

Ogni voce di quell’elenco è invisibile a posteriori ma economica da registrare nel momento in cui accade. La console nell’istante in cui si rompe. La richiesta fallita, con il suo stato e i suoi tempi. La build del browser, la dimensione dello schermo, l’URL. Nulla di tutto questo richiede che chi segnala sappia cosa sia rilevante, che è proprio la difficoltà principale, perché chi segnala non lo sa mai.

Questo è l’argomento a favore di una segnalazione che porta con sé le proprie prove, invece di una loro descrizione. La riproduzione è un modo per recuperare informazioni che sono state buttate via, ed è costosa proprio perché quelle informazioni sono state buttate via.

Chiedere di nuovo a chi ha segnalato il bug, nel modo giusto

Quando è davvero necessario tornare a chiedere, meglio chiedere cose a cui chi ha segnalato il bug può effettivamente rispondere, non quelle che si vorrebbe avesse già scritto.

Male: “fornisca i passaggi esatti per riprodurre il problema.” Chi lo ha scritto crede già di averlo fatto.

Meglio, e ciascuna di queste domande ha un buon tasso di successo:

• A che ora è successo, e che ora segna il dispositivo adesso? Sono due domande, non una. Lo scarto tra le due risposte è già una diagnosi.
• È successo più di una volta? Una volta sola è un momento. Ripetutamente è uno stato.
• Succede anche su una rete diversa, per esempio con i dati mobili invece del wifi?
• Cosa c’è esattamente sullo schermo? Le parole esatte, non un loro riassunto.
• Con chi altro si può riprodurre il problema? Un altro account restringe il campo ai dati; un’altra persona sullo stesso account lo restringe al dispositivo.

La guida alla segnalazione di bug ha la forma completa di una buona segnalazione, mentre l’articolo su gli errori più comuni copre quello che manca più spesso.

Cosa scrivere quando ci si arrende

A volte non è davvero possibile, e chiudere la segnalazione è la scelta giusta. Non chiuderla semplicemente come “cannot reproduce” e nient’altro, perché quella frase non dice nulla a chi la leggerà dopo, e finirà per passarci lo stesso pomeriggio.

Scrivere cosa si è provato. Quale account, quale browser e quale build, quali dati, quale dei quattro assi è stato variato e quale no. Così la prossima segnalazione dello stesso problema, da un’altra persona con un dettaglio diverso, non è un punto di partenza da zero. È il secondo dato, e due segnalazioni che condividono un elemento insolito sono di solito già la risposta completa.

Questa è anche la versione onesta dello stato. Il bug non è stato smentito. Non è stato riprodotto con le informazioni disponibili, il che è un’affermazione diversa e molto più utile da lasciare a chi verrà dopo.