Fare in modo che gli utenti scrivano segnalazioni di bug decenti e utili

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

1. per fargli vedere i loro rapporti online ...
   ^{[System] Grazie per aver segnalato, puoi trovare lo stato della tua richiesta qui: ...}
2. ... insieme alla valutazione e ai commenti del tecnico assegnato ...
   ^{[Ingegnere] Richiesta respinta, per i seguenti dettagli mancano: ...}
3. ... con un'opzione per modificare / migliorare il loro rapporto.
   ^{[Utente] I dettagli richiesti sono stati aggiunti, si prega di rivalutare: ...}

Arriverei fino a sostenere che è il solo modo efficace.

Diciamocelo, l'abilità di scrivere rapporti sui bug in modo efficace viene fornita solo con esperienza. Uno ha bisogno di imparare per acquisire esperienza. L'apprendimento implica praticare, 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 di cui sopra sono 1) per organizzare sessioni di apprendimento faccia a faccia con gli utenti (sì certo, soprattutto quando ce ne sono migliaia in tutto il mondo). O 2) spiega loro le cose per telefono ("guarda, se solo potessi vedere la merda che hai scritto alla riga 225 ..."). Cos'altro? Oh 3) via e-mail, certo "nella mail che ci hai inviato due mesi fa, hai detto ... no, non quella e-mail, ci hai inviato cinque e-mail oggi, tre di loro erano con argomento Re: clic del pulsante blu , guarda il secondo, quello con lo screenshot da 10 Mb ad esso collegato ... cosa? Non riesci a trovarlo? "}

Secondo me, la cosa più importante è usare il bug per stabilire un contatto significativo con l'utente. Scrivere e capire le segnalazioni di bug è un'abilità, e il mio consiglio è di rendere il più semplice possibile l'utente per il primo contatto, quindi di aumentare progressivamente il proprio feedback di valore in base alle esigenze.

Ad esempio, ricevi l'e-mail dell'utente e fornisci loro un campo di testo semplice 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 un doppio opt per confermare che hanno inviato il bug, lo hai ricevuto e il follow-up sul bug è ok.

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

• Linee guida per la scrittura di bug - Mozilla MDN article
• Come scrivere un bug corretto - Mozilla QMO Articolo
• Come scrivere un utile rapporto bug - articolo Sun SDN

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

General Outline of a Bug Report

Summary: How would you describe the bug in less than 60 characters? It should quickly and uniquely identify a bug report as well as explain the problem, not your suggested solution.

Good: “Cancelling a File Copy dialog crashes File Manager”

Bad: “Software crashes”

Bad: “Browser should work with my web site”

Component: In which sub-part of the software does it exist?This field is a requirement to submit any bug report. Click the word “Component” to see a description of each component. If none seems appropriate, highlight the “General” component.

OS: On which operating system (OS) did you find it? (e.g. Linux, Windows XP, Mac OS X.)Example: “If you know the bug happens on more than one type of operating system, choose “All”. If your OS isn’t listed, choose Other”.

Description: The details of your problem report, including:

-Overview: This is a larger detailed restatement of the summary. An example would be: “Drag-selecting any page crashes Mac builds in the NSGetFactory function”.

-Build Id: To find this either go to the “about:” page via the location bar or, if you have MozQA’s Nightly Tester Tools extension, then go to Tools | Nightly Tester Tools and select the option that contains the output of the build Id. It should look something like this: “Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3″.

-Additional Builds and Platforms: Whether or not the bug takes place on other platforms (or browsers, if applicable). It should look something like this: “Doesn’t Occur On Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3) Gecko/20081107 Firefox/3.1b2″.

Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the bug. If they’re necessary, make sure to include any special setup steps.A good example of this would look like the following: 1) View any web page. (I used the default sample page, http://www.google.com/). 2) Drag-select the page. Specifically, while holding down the mouse button, drag the mouse pointer downwards from any point in the browser’s content region to the bottom of the browser’s content region.

Actual Results: What the application did after performing the above steps.An example would be: The application crashed.

Expected Results: What the application should have done, were the bug not present.An example would be: The window should scroll downwards. Scrolled content should be selected. Or, at least, the application should not crash.

C'è Come segnalare efficacemente i bug di Simon Tatham. Spiega bene le cose, per renderle facilmente comprensibili agli utenti meno esperti. Tuttavia il lato negativo è che è un po 'di testo. Quando hai un utente che prova a segnalare un problema ma non riescono a spiegarlo, di solito non sarai in grado di convincerlo a leggere tutto questo.

Puoi chiedere domande facili e comprensibili agli utenti per prevedere rapporti utili.

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

Nessun utente potrebbe scrivere una segnalazione come: "Il mio driver video non è aggiornato. La tua libreria grafica potrebbe non essere compatibile con i vecchi driver grafici."

Qualcuno conosce un buon modo per convincere gli utenti a scrivere un semi-decente (leggi: utile ) bug report ?

Volevamo pubblicare qualcosa che avrebbe avuto senso per la maggior parte degli utenti (sia facile da leggere e capire), ma fornire informazioni utili anche agli sviluppatori.

Non funziona quando clicco sul pulsante blu! Ahhh, ho appena perso una settimana di lavoro ... farlo funzionare.

non è molto utile, così com'è.

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

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

1. per fargli vedere i loro rapporti online ...
   ^{[System] Grazie per aver segnalato, puoi trovare lo stato della tua richiesta qui: ...}
2. ... insieme alla valutazione e ai commenti del tecnico assegnato ...
   ^{[Ingegnere] Richiesta respinta, per i seguenti dettagli mancano: ...}
3. ... con un'opzione per modificare / migliorare il loro rapporto.
   ^{[Utente] I dettagli richiesti sono stati aggiunti, si prega di rivalutare: ...}

Arriverei fino a sostenere che è il solo modo efficace.

Diciamocelo, l'abilità di scrivere rapporti sui bug in modo efficace viene fornita solo con esperienza. Uno ha bisogno di imparare per acquisire esperienza. L'apprendimento implica praticare, 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 di cui sopra sono 1) per organizzare sessioni di apprendimento faccia a faccia con gli utenti (sì certo, soprattutto quando ce ne sono migliaia in tutto il mondo). O 2) spiega loro le cose per telefono ("guarda, se solo potessi vedere la merda che hai scritto alla riga 225 ..."). Cos'altro? Oh 3) via e-mail, certo "nella mail che ci hai inviato due mesi fa, hai detto ... no, non quella e-mail, ci hai inviato cinque e-mail oggi, tre di loro erano con argomento Re: clic del pulsante blu , guarda il secondo, quello con lo screenshot da 10 Mb ad esso collegato ... cosa? Non riesci a trovarlo? "}

Secondo me, la cosa più importante è usare il bug per stabilire un contatto significativo con l'utente. Scrivere e capire le segnalazioni di bug è un'abilità, e il mio consiglio è di rendere il più semplice possibile l'utente per il primo contatto, quindi di aumentare progressivamente il proprio feedback di valore in base alle esigenze.

Ad esempio, ricevi l'e-mail dell'utente e fornisci loro un campo di testo semplice con il seguente testo da completare:

Dopo aver ricevuto l'e-mail, fai una risposta automatica per ottenere un doppio opt per confermare che hanno inviato il bug, lo hai ricevuto e il follow-up sul bug è ok.

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

• Linee guida per la scrittura di bug - Mozilla MDN article
• Come scrivere un bug corretto - Mozilla QMO Articolo
• Come scrivere un utile rapporto bug - articolo Sun SDN

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

C'è Come segnalare efficacemente i bug di Simon Tatham. Spiega bene le cose, per renderle facilmente comprensibili agli utenti meno esperti. Tuttavia il lato negativo è che è un po 'di testo. Quando hai un utente che prova a segnalare un problema ma non riescono a spiegarlo, di solito non sarai in grado di convincerlo a leggere tutto questo.

Puoi chiedere domande facili e comprensibili agli utenti per prevedere rapporti utili.

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

Nessun utente potrebbe scrivere una segnalazione come: "Il mio driver video non è aggiornato. La tua libreria grafica potrebbe non essere compatibile con i vecchi driver grafici."

Supponendo che la base utenti sia utenti finali che hanno avuto un problema con il software che hai scritto ....

Non è il tuo lavoro agli utenti di diventare un Software Engineer esperto o test professionali, e non è a deve aspettarsi. I tuoi utenti sono persone normali che giustamente si aspettano che il software "funzioni". Altrimenti, riferiranno qualunque cosa pensino di ascoltare per attirare la vostra attenzione. Non puoi cambiarlo e non dovresti tentare di farlo. Qualsiasi tentativo di insistere sul tipo di rapporti ci si aspetta un professionista per fare comporterà la perdita del bug report, e il cliente - "Ho avuto un problema con questo software, ma invece di aiutarmi, hanno fatto essere compilare tutti tipi di forme inutili che non significano nulla e non hanno alcun valore per me. Vado a cercare un software che funzioni davvero ".

vale a dire. Non è il loro lavoro .....

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