Che cos'è la segnalazione visiva dei bug e in cosa differisce dal session replay

Qualcuno sul vostro sito incontra un bug. Lo vede: il layout rotto, il pulsante che non fa niente, l’errore in rosso. Quando arriva a uno sviluppatore è diventato una frase. “Il checkout è rotto.” Tutto quello che si poteva vedere è stato buttato via, e il primo compito dello sviluppatore è ricostruirlo facendo domande.

La segnalazione visiva dei bug è la pratica di catturare quello che c’era sullo schermo, e quello che il browser sapeva, nel momento in cui qualcuno ha deciso di segnalare un problema. Il report è la prova, non una descrizione di essa.

Che cosa contiene davvero

La parola “visiva” non le rende giustizia. L’immagine è la parte che si nota; la maggior parte del valore sta in quello che il browser stava facendo dietro l’immagine.

Un report visivo di un bug di solito contiene alcune di queste cose, o tutte:

• Uno screenshot o una registrazione della pagina così come l’ha vista chi segnala, spesso con qualcosa disegnato sopra per indicare il problema.
• L’ambiente: browser e versione, sistema operativo, dimensione dello schermo. I dati che decidono se un difetto è universale o appartiene a una sola configurazione.
• L’output della console, compreso l’errore stampato mentre nessuno stava guardando la console.
• Il log di rete: quali richieste ha fatto la pagina, che cosa è tornato indietro, quanto ci ha messo. Spesso la risposta è un 403 che nessuno ha visto.
• Che cosa ha fatto chi segnala: i clic, quello che ha scritto nei moduli e i cambi di pagina che hanno portato fin lì, in ordine.

È l’ultimo punto a trasformare un report in istruzioni. Dei passi di riproduzione scritti a memoria sono una ricostruzione; una sequenza registrata è un verbale.

In cosa differisce dal session replay

I due vengono confusi, anche da noi: il nostro prodotto si chiama Session Replay, che è un nome che abbiamo scelto e una categoria in cui non siamo.

Il session replay, nel senso in cui il termine viene normalmente usato, è una pratica di analytics. Uno script gira su ogni pagina per ogni visitatore e registra le sessioni di continuo perché qualcuno possa guardarle dopo, di solito cercando schemi ricorrenti: dove le persone esitano, dove abbandonano un modulo, quale rage click precede quale abbandono. Nessuno preme niente. La registrazione esiste perché vengono registrati tutti.

La segnalazione visiva dei bug comincia quando una persona decide che qualcosa non va. Non viene registrato niente finché non agisce, e quello che produce è indirizzato a un lettore preciso con un difetto preciso in mente.

Session replay

Sempre attivo, tutti i visitatori, guardato dopo per trovare problemi che nessuno ha segnalato

Segnalazione visiva dei bug

Comincia quando qualcuno segnala, cattura un singolo episodio, va a chi può risolverlo

La differenza conta per due ragioni pratiche. La prima è la privacy: uno strumento che registra tutti per impostazione predefinita deve rispondere di quello che ha conservato su persone che non hanno mai chiesto niente, ed è per questo che gli strumenti di session replay dedicano una parte così grande della loro documentazione al mascheramento. Un report che esiste solo perché qualcuno ha scelto di inviarlo ha una domanda molto più piccola a cui rispondere.

La seconda è il ritrovamento. Trovare fra migliaia l’unica sessione che contiene il bug di cui vi hanno parlato è un lavoro a sé. Un report arriva già sapendo di quale episodio parla.

Dove è lo strumento sbagliato

La segnalazione visiva dei bug vede solo quello che qualcuno ha scelto di segnalare. Non vi dirà quante altre persone hanno incontrato lo stesso difetto e se ne sono andate, e non farà emergere un problema di cui nessuno si è lamentato. A quello risponde l’analytics, e un report di un bug non può.

È altrettanto inutile per tutto quello che il browser non può vedere. Un job fallito in coda, un import notturno che ha scritto le righe sbagliate, una corsa fra due servizi: niente di tutto questo sta su una pagina, e nessuna quantità di catture dello schermo lo troverà. Per quello ci sono i log e il tracing.

La posizione onesta è che si tratta di tre strumenti per tre domande diverse. Che cosa è andato storto per questa persona, adesso, è l’unica a cui un report visivo di un bug risponde bene.

Come funziona in pratica

La versione che costruiamo noi è un’estensione Chrome. Qualcuno incontra un bug, fa clic sull’icona e ottiene uno screenshot o una registrazione con allegati l’ambiente, l’output della console, il log di rete e la sequenza di quello che ha fatto. Riceve un link da incollare dove il lavoro viene tracciato. Per inviarne uno non serve un account.

Due cose che non fa, dato che una spiegazione di categoria che elenca solo i pregi è una pubblicità. Non guarda tutti: non viene registrato niente finché qualcuno non decide di segnalare qualcosa, quindi non vi parlerà mai delle persone che hanno incontrato lo stesso difetto e se ne sono andate senza dire niente. E non decide che cosa conta. Il titolo, la gravità e il giudizio su se due sintomi siano un solo difetto restano alla persona che era lì, che è l’argomento di come scrivere un report di bug perfetto.

Se state scegliendo fra i due

Chiedetevi a quale domanda state cercando di rispondere.

Se è “perché le persone abbandonano questo modulo”, volete analytics, e il session replay fa parte di quella famiglia. Se è “perché si è rotto per questa persona”, volete l’episodio catturato e mandato a qualcuno, e quella è segnalazione di bug. I team che hanno bisogno di entrambe le cose di solito usano entrambe, e confonderle è il modo per ritrovarsi a guardare quattrocento registrazioni per trovarne una che qualcuno avrebbe potuto consegnarvi in quindici secondi.

I report in sé devono comunque essere scritti bene: la cattura toglie la scusa del contesto mancante, non il bisogno di un titolo chiaro e di un resoconto onesto di quello che vi aspettavate. I dieci errori più comuni restano alla portata di chiunque segnali, anche con i migliori strumenti del mondo.