Come ottenere una segnalazione di bug utilizzabile da qualcuno che non è tecnico

Una persona che non è tecnica non è un cattivo segnalatore. Sta rispondendo a una domanda diversa da quella che hai posto, e di solito il problema era la domanda stessa.

Quasi ogni modulo di segnalazione di bug chiede le stesse tre cose: cosa è andato storto, i passaggi per riprodurlo e cosa ti aspettavi che accadesse invece. Ognuno di questi chiede al segnalatore di fare un pezzo di diagnosi. “Cosa è andato storto” chiede una causa. “Atteso contro reale” chiede loro di sapere cosa avrebbe dovuto fare il software, il che è la conoscenza che non hanno e il motivo per cui ti stanno scrivendo. “Passaggi per riprodurre” chiede loro di aver prestato attenzione a una sequenza che non valeva la pena seguire fino a quando è fallita.

Quello che una persona può darti in modo accurato è quello che stava cercando di fare e quello che ha visto. Questi sono osservazioni. La maggior parte del resto del modulo è una richiesta di una teoria.

La teoria è la parte da mettere da parte

La cosa costosa in una segnalazione non addestrata non è il dettaglio mancante. È la spiegazione, perché una spiegazione arriva sembrando un’osservazione e passerai la mattina dentro di essa.

“Mi ha disconnesso” è una conclusione. Sotto di essa, la cosa che è effettivamente accaduta è che è apparsa una schermata con un modulo di accesso. Quella schermata ha almeno quattro cause che non hanno nulla a che fare l’una con l’altra: la sessione è veramente scaduta, una chiamata API ha restituito un 401 e il client ha reindirizzato su di essa, una pagina memorizzata nella cache è stata servita con l’intestazione disconnessa, oppure aveva una seconda scheda aperta e ha effettuato l’accesso in quella. Inizia da “disconnesso” e vai al session store. Inizia da “una schermata di accesso è apparsa mentre ero nel mezzo del checkout” e hai il timing, la pagina e il sintomo, e il session store è uno di quattro posti da guardare piuttosto che l’unico.

Debole

Il sito mi ha disconnesso mentre stavo pagando.

Meglio

Ero sul passaggio di pagamento e la pagina è tornata al modulo di accesso. Il mio carrello era ancora lì dopo.

Nulla nella versione migliore richiede alcuna conoscenza tecnica. È la stessa persona, interrogata su quello che ha visto invece che su quello che significava.

Parole che non significano quello che assumi

Il vocabolario è condiviso e le definizioni non lo sono. Questi cinque causano il maggior danno perché entrambi i lati sono sicuri di essersi capiti.

Bloccato

La scheda si è chiusa, la pagina è diventata bianca, uno spinner non si è mai fermato, oppure il browser stesso ha smesso di funzionare.

Congelato

Nulla ha risposto ai clic, oppure qualcosa stava caricando senza indicazione che lo stava facendo.

Eliminato

È scomparso dall'elenco di fronte a loro. Potrebbe essere filtrato, su un'altra pagina, in un altro account, o veramente eliminato.

Pagina

Un URL, una scheda, una finestra modale, un passaggio in un flusso, o l'intero sito.

Errore

Un messaggio che hai scritto, una schermata di errore del browser, o semplicemente un risultato che non volevano.

Non puoi risolvere questo pubblicando un glossario, perché nessuno ne legge uno prima di segnalare un problema. Lo risolvi non facendo mai una domanda la cui risposta è una di queste parole. “Si è bloccato?” non ha una risposta utile. “Cosa c’era sullo schermo quando ha smesso di funzionare?” ne ha una.

Chiedi dell’ultima cosa che ha funzionato

La domanda più produttiva da porre a qualcuno senza il vocabolario non è affatto sul fallimento.

Chiedi cosa stava facendo subito prima, e chiedi se ha mai funzionato. Entrambi sono cose che una persona ricorda senza sforzo, e insieme limitano il problema: il primo ti dà il punto di ingresso, e il secondo ti dice se stai guardando una regressione o qualcosa che non ha mai funzionato per questa persona in questa situazione. Una funzione che ha funzionato per loro martedì scorso e non oggi è un’indagine diversa da una che non hanno mai visto funzionare nemmeno una volta.

“Ha mai funzionato per te?” fa anche qualcosa che le altre domande non fanno. È rispondibile con un sì o un no, quindi quasi sempre riceve una risposta.

Chiedi lo schermo, non una descrizione

Una screenshot è l’unico artefatto che qualcuno non addestrato produce in modo affidabile e accurato, perché scattarne una non ha bisogno di alcun vocabolario. Contiene cose che non avrebbero potuto dirti se te lo avessi chiesto: l’URL nella barra degli indirizzi, la larghezza della finestra, quale account è connesso, il testo esatto del messaggio, se un banner copriva il pulsante. La maggior parte di quello che avresti estratto in quattro email è seduta in un’immagine che ha richiesto loro cinque secondi.

Quindi “puoi mandarmi un’immagine di quello che stai vedendo” vale più di qualsiasi domanda che avresti potuto scrivere, ed è la cosa più facile dell’elenco da chiedere.

Il limite vale la pena sapere anche. Una screenshot mostra la superficie in un momento. Non può dirti cosa stava facendo il browser sotto, e il fallimento spesso non lascia segni sulla superficie affatto: una richiesta che ha restituito un 500 mentre la pagina continuava a sembrare normale è invisibile in un’immagine.

Quello che non possono darti e non dovrebbe essere chiesto

Errori della console, il registro di rete, la versione del browser, le dimensioni del viewport. Questi sono gli elementi che accorcierebbero effettivamente l’indagine, e ognuno di loro richiede al segnalatore di aprire uno strumento di sviluppo e sapere cosa cercare.

Chiedere questi elementi ha un costo reale e non è il tempo del segnalatore. È che la richiesta sembra un test. Qualcuno che non riesce a trovare la console ora sa di aver fallito nell’aiutare correttamente, e la cosa successiva che notano è quella che tengono per sé. La fornitura di persone disposte a parlarti di un problema è piccola e interamente volontaria, ed è più facile da perdere che da costruire.

La risposta onesta è che questa metà dovrebbe essere raccolta piuttosto che richiesta.

Non ti scriverà il titolo, e non può dirti cosa la persona stava cercando di fare. Quella parte viene solo facendo loro domande, motivo per cui le domande contano.

Chiedi uno alla volta

Un elenco di sei domande torna con due risposte e nessuna indicazione di quali quattro siano state saltate. Peggio ancora, sembra un modulo, e un modulo è una cosa che le persone rimandano fino al fine settimana.

Invia una domanda. Quando è risposta, invia la prossima se ne hai ancora bisogno. Sembra più lento e non lo è, perché l’alternativa è un lungo silenzio seguito da una risposta parziale che genera tre ulteriori domande comunque.

Ricorda cosa stai interrompendo. Un rapporto di bug è la fine di una catena di piccole decisioni per la fatica: hanno notato, hanno deciso che non era colpa loro, hanno scoperto dove dirti, e l’hanno scritto. Ogni scambio dopo quello è un’altra chance per la catena di rompersi, e nulla ti dice quando accade. Non senti più niente, il che dal tuo lato è indistinguibile dal problema che è scomparso.

Le domande, nell’ordine in cui farle

Quattro domande, nessuna delle quali richiede alla persona di sapere nulla del software:

• Cosa stavi cercando di fare?
• Cosa hai visto invece? Se puoi, mandami un’immagine.
• Quando è stato, più o meno, e cosa stavi usando in quel momento?
• Ha mai funzionato per te prima?

Se ottieni questi quattro, hai il punto di ingresso, il sintomo, una finestra per cercare nei tuoi registri, e se è una regressione. È abbastanza per iniziare, ed è più di la maggior parte dei ticket scritti da persone che conoscono il vocabolario.