Invitare gli utenti a scrivere segnalazioni di bug decenti e utili

32

Qualcuno conosce un buon modo per indurre gli utenti a scrivere una segnalazione di bug semi-decente (leggi: utile ) ?

Volevamo creare qualcosa che avrebbe senso per la maggior parte degli utenti (essere di facile lettura e comprensione), ma fornire anche informazioni utili agli sviluppatori.

Non funziona quando faccio clic sul pulsante blu! Ahhh, ho appena perso una settimana di lavoro ... fallo funzionare.

non è molto utile così com'è.

Ho iniziato a sistemare un elenco, ma ho pensato di verificare con voi ragazzi, se esiste già un metodo simile.

client-relations bug-report

— Torre
fonte

2

Potrei capire votare per la chiusura ai programmatori, ma offtopic? Segnalazioni di bug sul sito di un programmatore ?!

— Rook,

1

Importa? Scriveranno comunque segnalazioni di errori. Ciò che in genere è necessario fare è in qualche modo comunicare con gli utenti.

— David Thornley,

@DavidThornley - Siamo in una sorta di settore specifico. Con la maggior parte degli utenti non comunico mai, o ricevo quei rapporti pochi mesi dopo. Non chiedere.

— Arriva il

3

Costruisci il meccanismo di segnalazione nella tua applicazione, in modo che l'utente possa fare clic su un pulsante, aggiungere un commento e avere lo stato appropriato allegato dall'applicazione. "Ora, per favore, fai clic sulla posizione sullo schermo dove è sbagliato" ...

3

Fammi sapere se trovi una risposta. Ho abbastanza problemi a ottenere utili segnalazioni di bug dai tester, non importa gli utenti.

— Kristof Provost,

16

Il modo più efficace per indurre gli utenti a scrivere segnalazioni di bug decenti e utili è

per consentire loro di vedere i loro rapporti online ...
^{[Sistema] Grazie per aver segnalato, puoi trovare lo stato della tua richiesta qui: ...}
... insieme alla valutazione e ai commenti dell'ingegnere assegnato ...
^{[Ingegnere] Richiesta respinta, per i seguenti dettagli mancanti: ...}
... con un'opzione per modificare / migliorare il loro rapporto.
^{[Utente] Sono stati aggiunti i dettagli richiesti, rivalutare: ...}

Vorrei arrivare al punto di affermare che è l' unico modo efficace.

Ammettiamolo, l'abilità di scrivere segnalazioni di bug arriva effettivamente solo con esperienza. Bisogna imparare per acquisire esperienza. L'apprendimento implica esercitarsi, ottenere feedback e migliorare.

Le segnalazioni di bug online modificabili dall'utente sono il modo più efficace per insegnare agli utenti a migliorare .

^{Le opzioni alternative sopra indicate sono 1) per organizzare sessioni di apprendimento faccia a faccia con gli utenti (sì certo, specialmente quando ce ne sono migliaia sparse in tutto il mondo). Oppure 2) spiega loro le cose al telefono ("guarda, se solo potessi vedere la merda che hai scritto alla linea 225 ..."). Cos'altro? Oh 3) via e-mail, certo "nella mail che ci hai inviato due mesi fa, hai menzionato ... no non quella e-mail, ci hai inviato cinque e-mail questo giorno, tre di loro erano con oggetto Re: clic del pulsante blu , guarda la seconda, quella con una schermata da 10 Mb attaccata ad essa ... cosa? non riesci a trovarla? "}

— moscerino
fonte

27

Secondo me, ciò che è più importante è usare il bug per stabilire un contatto significativo con l'utente. Scrivere e comprendere le segnalazioni di bug è un'abilità e il mio consiglio sarebbe di rendere il più semplice possibile all'utente il primo contatto, quindi rendere progressivamente il feedback di più valore se necessario.

Ad esempio, basta ricevere l'e-mail dell'utente e assegnare loro un campo di testo normale con il seguente testo da completare:

"I did _____ , and expected ______ to happen, but ______ happened instead."

Dopo aver ricevuto l'e-mail, fai una risposta automatica per ottenere una doppia opzione per confermare che hanno inviato il bug, l'hai ricevuto e il follow-up sul bug va bene.

— errori
fonte

2

Bella risposta. Succinto e comunicativo. Sto andando a rubare questo andando avanti per spiegare alla gente.

— Erik Dietrich,

Questo dovrebbe anche essere il modello con cui iniziano le domande SO.

— Cody Piersall,

5

Ho premuto il pulsante blu e mi aspettavo che le cose funzionassero , ma non è successo nulla . : D

— Songo,

"Ho fatto _____ e mi aspettavo che accadesse ______, ma invece è successo ______." Stavo usando il software ______ versione _____ in ambiente di produzione / qa / test.

— kubanczyk,

10

Potresti prendere in considerazione l'idea di prendere alcune idee da Mozilla e Sun su questo argomento:

Linee guida per la scrittura di bug - articolo Mozilla MDN
Come scrivere un bug corretto - articolo Mozilla QMO
Come scrivere una segnalazione di bug utile - articolo di Sun SDN

In particolare (dalla pagina "Come scrivere un bug corretto" di Mozilla):

Schema generale di una segnalazione di bug

Riepilogo : come descriveresti il bug in meno di 60 caratteri? Dovrebbe identificare rapidamente e in modo univoco una segnalazione di bug, nonché spiegare il problema, non la soluzione suggerita.

Buono : "L'annullamento di una finestra di dialogo Copia file provoca l'arresto anomalo di File Manager"

Cattivo : "Il software si arresta in modo anomalo"

Cattivo : "Il browser dovrebbe funzionare con il mio sito Web"

Componente : in quale sotto-parte del software esiste? Questo campo è obbligatorio per inviare qualsiasi segnalazione di bug. Fare clic sulla parola "Componente" per visualizzare una descrizione di ciascun componente. Se nessuno sembra appropriato, evidenziare il componente "Generale".

OS : da quale sistema operativo (OS) l'hai trovato? (ad es. Linux, Windows XP, Mac OS X.) Esempio: "Se sai che il bug si verifica su più di un tipo di sistema operativo, scegli" Tutto ". Se il tuo sistema operativo non è elencato, scegli Altro ”.

Descrizione : i dettagli della segnalazione del problema, tra cui:

- Panoramica : si tratta di una rivisitazione dettagliata più ampia del riepilogo. Un esempio potrebbe essere: "La selezione trascinata di qualsiasi pagina si arresta in modo anomalo su build Mac nella funzione NSGetFactory".

- ID build : per trovarlo, vai alla pagina “about:” tramite la barra degli indirizzi oppure, se hai l'estensione Strumenti notturni di MozQA Tester, vai su Strumenti | Strumenti Nightly Tester e selezionare l'opzione che contiene l'output dell'ID build. Dovrebbe assomigliare a questo: "Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20090305 Firefox / 3.1b3 ″.

- Build e piattaforme aggiuntive : indipendentemente dal fatto che il bug si verifichi o meno su altre piattaforme (o browser, se applicabile). Dovrebbe assomigliare a questo: "Non si verifica su Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20081107 Firefox / 3.1b2 ″.

Passaggi da riprodurre : passaggi minimizzati e facili da seguire che attiveranno il bug. Se sono necessari, assicurati di includere eventuali passaggi di installazione speciali. Un buon esempio di questo sarebbe simile al seguente: 1) Visualizza qualsiasi pagina web. (Ho usato la pagina di esempio predefinita, http://www.google.com/ ). 2) Trascina e seleziona la pagina. In particolare, tenendo premuto il pulsante del mouse, trascinare il puntatore del mouse verso il basso da qualsiasi punto nell'area di contenuto del browser nella parte inferiore dell'area di contenuto del browser.

Risultati effettivi : cosa ha fatto l'applicazione dopo aver eseguito i passaggi precedenti. Un esempio potrebbe essere: l'applicazione si è arrestata in modo anomalo.

Risultati previsti : cosa avrebbe dovuto fare l'applicazione, se il bug non fosse presente. Un esempio potrebbe essere: la finestra dovrebbe scorrere verso il basso. Il contenuto fatto scorrere dovrebbe essere selezionato. O almeno l'applicazione non dovrebbe arrestarsi in modo anomalo.

— Brian Snow
fonte

10

Non capisco davvero perché questo abbia ottenuto così tanti voti. La domanda non è "come scrivere una segnalazione di bug decente?" ma "come convincere gli utenti a scrivere una buona segnalazione di bug".

— Tamás Szelei,

8

Tali risorse sono principalmente rivolte ai tecnici. Anche Mozilla è l'organizzazione che ci ha portato Bugzilla. Non sto dicendo che Bugzilla è male, ma è stato fatto da ingegneri per ingegneri: In realtà non è uno strumento per l'utente finale a tutti .

— Joachim Sauer

3

Sono d'accordo con @fish. Siamo in grado di fornire ai nostri tester tutte le linee guida del mondo, senza che possano effettivamente produrre utili segnalazioni di errori. E sto parlando di persone che hanno il compito di segnalare i bug - se non possiamo motivarli con linee guida non abbiamo alcuna speranza con gli utenti reali. L'unica cosa che abbiamo trovato efficace è stata la chiusura attiva delle segnalazioni di bug "inutili" come "informazioni insufficienti" - hanno ottenuto il messaggio abbastanza rapidamente allora. Non lo consiglio agli utenti esterni però :-)

— HappyCat,

3

Non sto discutendo dell'utilità del post (risorse abbastanza buone lì, davvero) ma questo non risponde alla domanda, e penso che la politica di voto si basi su questo (potrei sbagliarmi).

— Tamás Szelei,

1

Sono il tipo di persona a cui era rivolto e anche io non riuscivo a leggere tutto. Cosa ti fa pensare che gli utenti lo faranno?

— Tacroy,

4

C'è come segnalare efficacemente i bug di Simon Tatham. Spiega bene le cose, per renderlo facile da capire per gli utenti meno esperti. Tuttavia, l'aspetto negativo è che è un bel po 'di testo. Quando un utente tenta di segnalare un problema ma non riesce a spiegarlo, di solito non sarà in grado di convincerlo a leggere tutto questo.

— Wladimir Palant
fonte

4

Puoi chiedere agli utenti domande facili da capire e di facile risposta in attesa di rapporti utili.

Ad esempio, "Qual è stata la tua ultima azione prima di questo errore?", "Hai provato a ... poco prima di questo errore?".

Nessun utente ti scriverebbe una segnalazione di bug del tipo: "Il mio driver video non è aggiornato. La tua libreria grafica potrebbe non essere compatibile con i vecchi driver grafici".

— Mert Akcakaya
fonte

3

Supponendo che la base di utenti siano gli utenti finali che hanno avuto problemi con il software che hai scritto ....

Non è compito dei tuoi utenti diventare un abile ingegnere del software o un professionista dei test e non dovresti aspettartelo. I tuoi utenti sono persone normali che si aspettano giustamente che il software "funzioni". In caso contrario, segnaleranno tutto ciò che pensano di seguire per attirare la tua attenzione. Non puoi cambiarlo e non dovresti tentare di farlo. Qualsiasi tentativo di insistere sul tipo di segnalazioni che un professionista dovrebbe fare comporterà la perdita della segnalazione di bug e il cliente - "Ho avuto un problema con quel software, ma invece di aiutarmi, hanno fatto riempire tutti tipi di forme inutili che non significano nulla e non hanno alcun valore per me. Vado a cercare un software che funzioni davvero ".

cioè non è il loro lavoro .....

Se vuoi avere buone segnalazioni di bug, impiega professionisti per trovare i tuoi bug. Se tu, come sviluppatore di software, non puoi preoccuparti di trattare con i clienti, assumi qualcuno che possa farlo.

— mattnz
fonte

1

Non credo che l'OP stia dicendo che non vogliono trattare con gli utenti. Penso che l'OP stia dicendo che non possono davvero aggiustare nulla in base alla segnalazione di bug "si è bloccato". L'OP vuole un modo per ottenere il massimo dagli utenti che si lamentano, in modo che l'OP possa effettivamente risolvere il problema.

— Michael Kohne,

1

Il mio punto è che se "si è schiantato" è ciò che accade dal punto di vista dell'utente. Quando porto la mia auto da un meccanico, non si aspetta che gli dia un rapporto diagnostico dettagliato di ciò che è sbagliato - mi fa domande per aiutarlo a usare la sua esperienza per diagnosticare il problema. Ad esempio, una visita il mio problema era "Si blocca quando fa freddo, ma va bene quando fa caldo", alcune domande ben ponderate (con sì nessuna risposta) in seguito fu abbastanza sicuro (e si rivelò corretto) che era un difetto termometro. Il nostro compito è porre le domande, incorniciate per dare sì, non risposte.

— mattnz,