Quali informazioni si richiedono quando si risolve un problema sulla scatola di un cliente utilizzando un'applicazione desktop?

Question

Scriviamo un'applicazione desktop di Windows che è installato su un paio di migliaia di computer che non abbiamo accesso. Quando uno di questi utenti segnala un bug, anche se la descrizione è abbastanza completa, non v'è altra informazione che può essere utile.

Attualmente stiamo lavorando su un agent risposte automatizzato, il che significa avremo accesso alle informazioni molto dettagliate. Ma come un bambino in un negozio di caramelle, non siamo sicuri dove cominciare. Quali informazioni vorresti includere nel pacchetto di feedback nello stesso caso? Che cosa è utile per aiutarci a riprodurre c'è errore?

Quello che abbiamo finora è:

• Il numero di versione della nostra applicazione,
• sistema operativo e versione del sistema operativo numero
• le informazioni proxy
• .NET versione e aggiornare il numero
• Informazioni specifiche per la nostra applicazione (ad es. le versioni dei dati)
• L'accesso e di errore log

Si noti che questo è simile a questa domanda , tuttavia abbiamo non è tanto interessato a ottenere informazioni quando il programma va in crash come siamo, come quando l'utente si verifica un errore.

Modifica: Precisazione: non chiedere quali informazioni l'utente dovrebbe dare nel caso di un bug, ma piuttosto quali informazioni dovremmo raccogliere programmaticaly

?

Answer 1

Anche se si dispone di tutte queste informazioni, che riproduce il problema può essere difficile. Quando gli utenti descrive come hanno creato il bug che sono spesso scambiato sui passaggi chiave - è difficile per loro di sapere quali aree sono fondamentali quando non conoscono il funzionamento interno dell'applicazione. Si potrebbe desiderare di implementare un modo di tracciare le azioni degli utenti, come ad esempio la gestione degli eventi a livello di root o altri mezzi - se si dispone di funzionalità di annullamento / redo, allora sono sicuro che questo sarebbe sufficiente. Si potrebbe quindi includere gli ultimi (x) passi della catena di azione nel rapporto di errore.

Answer 2

Edit: Credo che ho letto male la tua domanda. Ho pensato che si sta parlando di quali informazioni di ottenere da un cliente di segnalare un bug, piuttosto che già pianificando quello che ho descritto qui. Lascio per riferimento in ogni caso.

In una situazione simile, nonostante un minor numero di utenti, la nostra applicazione ha un pulsante di "Pacchetto registri per il supporto" che creerà un file zip con tutti i file di registro e il file di progetto attualmente aperto, se presente. Tutte le altre informazioni che hai descritto è già parte di uno dei file di log. In questo modo, il cliente può comodamente inviare il file ZIP a noi, che può essere fatto dalla finestra principale senza aprire un file di progetto o la connessione a un'interfaccia di rete, che sono i due punti principali in cui qualcosa può andare storto. Questo rende molto più facile che fare affidamento su l'utente fornendo un feedback "a mano".

Oltre a questo, la procedura esatta per riprodurre il problema devono essere disponibili. La maggior parte di che è in genere nel file di progetto in sé (che si trova nel file ZIP otteniamo), con solo pochi passi manca.

Le cose che sembravano essere importante per questo, diverso da quello che già elencato:

• / informazioni sugli account utente. Questo può aiutare con problemi di autorizzazione. Si potrebbe desiderare di includere le cose come fuso orario, locale, tema di Windows.
• Configurazione applicazione, tra cui in cui è installato.
• Come già detto, il file corrente l'utente sta lavorando con, perché questa potrebbe essere la causa del problema.
• Impostazioni utente, vale a dire i dati l'applicazione memorizza per utente. Visto cose strane con questi. MRU può anche essere utile.

Answer 3

A parte la condizione di base dell'applicazione (versione, configurazione, ecc), le informazioni più importanti per ottenere è:

• Il passo (s) necessario per riprodurre l'errore o insetto, compresi gli ingressi utilizzati se possibile
• Il risultato atteso
• L'uscita effettiva
• Informazioni di contatto in caso di necessità di follow-up (se il software viene consumato in forma anonima)

Sarà abbastanza informazioni per risolvere il 99,9% dei problemi. Per il resto, follow-up e ottenere tutte le informazioni dettagliate si ritiene possano aiutare a risolvere il problema (che, si spera, sarà di gran lunga migliore intesa a questo punto).