Benutzer dazu bringen, anständige und nützliche Fehlerberichte zu schreiben

32

Kennt jemand eine gute Methode, um Benutzer dazu zu bringen, einen halbwegs anständigen (gelesenen: nützlichen ) Fehlerbericht zu schreiben ?

Wir wollten etwas entwickeln, das für die meisten Benutzer sinnvoll ist (leicht zu lesen und zu verstehen), aber auch Entwicklern nützliche Informationen bieten.

Es funktioniert nicht, wenn ich auf den blauen Knopf klicke! Ahhh, ich habe gerade eine Woche Arbeit verloren ... damit es funktioniert.

ist nicht sehr nützlich, wie es ist.

Ich fing an, mich um eine Liste zu kümmern, überlegte aber, ob es eine ähnliche Methode gibt.

client-relations bug-report Turm
quelle
2
Ich könnte verstehen, für das Schließen von Programmierern zu stimmen, aber offtopisch? Fehlerberichte auf der Site eines Programmierers ?!
Turm
1
Ist das wichtig? Sie werden sowieso schlechte Fehlerberichte schreiben. Was Sie normalerweise tun müssen, ist irgendwie mit den Benutzern zu kommunizieren.
David Thornley
@ DavidThornley - Wir sind in einer bestimmten Branche. Mit den meisten Benutzern kommuniziere ich nie oder erhalte diese Berichte einige Monate später. Frag nicht
Turm
3
Integrieren Sie den Berichtsmechanismus in Ihre Anwendung, sodass der Benutzer auf eine Schaltfläche klicken, einen Kommentar hinzufügen und den entsprechenden Status der Anwendung hinzufügen kann. "Klicken Sie jetzt bitte auf die Stelle auf dem Bildschirm, an der es falsch ist" ...
3
Lassen Sie mich wissen, wenn Sie eine Antwort finden. Ich habe genug Probleme damit, nützliche Fehlerberichte von Testern zu bekommen, egal, welche Benutzer.
Kristof Provost

Antworten:

16

Der effektivste Weg, um Benutzer dazu zu bringen, anständige und nützliche Fehlerberichte zu schreiben, ist

  1. Damit sie ihre Berichte online sehen können ...
    [System] Vielen Dank für Ihre Meldung. Den Status Ihrer Anfrage finden Sie hier: ...
  2. ... zusammen mit der Bewertung und den Kommentaren des beauftragten Ingenieurs ...
    [Ingenieur] Antrag abgelehnt, da folgende Details fehlen: ...
  3. ... mit einer Option zum Bearbeiten / Verbessern des Berichts.
    [User] Angeforderte Details werden hinzugefügt, bitte neu bewerten: ...

Ich würde sogar behaupten, dass dies der einzig wirksame Weg ist.

Seien wir ehrlich, die Fähigkeit , Fehlerberichte effektiv zu schreiben, kommt nur mit Erfahrung. Man muss lernen, um Erfahrungen zu sammeln. Lernen heißt üben, Feedback bekommen und sich verbessern.

Vom Benutzer bearbeitbare Online-Fehlerberichte sind die effizienteste Methode, um Benutzern Verbesserungen beizubringen .

  • Alternative Optionen zu den oben genannten Optionen sind 1) persönliche Lernsitzungen mit Benutzern zu vereinbaren (ja sicher, besonders wenn Tausende von Benutzern auf der ganzen Welt verteilt sind). Oder 2) erkläre ihnen die Dinge am Telefon ("sieh mal, wenn du nur den Mist sehen könntest, den du in Zeile 225 geschrieben hast ..."). Was sonst? Oh 3) per E-Mail, sicher "In der E-Mail, die Sie uns vor zwei Monaten gesendet haben, haben Sie erwähnt ... nein, nicht diese E-Mail, Sie haben uns heute fünf E-Mails gesendet, von denen drei mit dem Betreff Re: Blauer Knopf klicken , schauen Sie der zweite, der mit einem 10MB-Screenshot ... was? Sie können ihn nicht finden? "
Mücke
quelle
27

Meiner Meinung nach ist es wichtiger, den Fehler zu verwenden, um einen sinnvollen Kontakt mit dem Benutzer herzustellen. Das Schreiben und Verstehen von Fehlerberichten ist eine Fertigkeit, und mein Rat wäre, es dem Benutzer so einfach wie möglich zu machen, zuerst Kontakt aufzunehmen und dann sein Feedback nach und nach von größerem Wert zu machen, je nach Bedarf.

Erhalten Sie zum Beispiel einfach die E-Mail-Adresse des Benutzers und geben Sie ihm ein Klartextfeld mit folgendem Text:

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

Nachdem Sie die E-Mail erhalten haben, antworten Sie automatisch, um zu bestätigen, dass der Fehler übermittelt wurde. Sie haben ihn erhalten, und die Nachverfolgung des Fehlers ist in Ordnung.

Fehler
quelle
2
Gute Antwort. Prägnant und kommunikativ. Ich werde dies künftig für Erklärungen an die Leute plündern.
Erik Dietrich
Dies sollte auch die Vorlage sein, mit der SO-Fragen beginnen.
Cody Piersall
5
Ich habe den blauen Knopf gedrückt und erwartet, dass alles funktioniert , aber stattdessen ist nichts passiert. : D
Songo
"Ich habe _____ und erwartet, dass ______ passiert, aber ______ ist stattdessen passiert." Ich habe die Software ______ Version _____ in der Produktions- / QA- / Testumgebung verwendet.
Kubanczyk
10

Sie könnten in Betracht ziehen, zu diesem Thema einige Ideen von Mozilla und Sun zu übernehmen:

Insbesondere (von der Mozilla-Seite "Wie schreibe ich einen richtigen Fehler?"):

Allgemeiner Überblick über einen Fehlerbericht

Zusammenfassung : Wie würden Sie den Fehler in weniger als 60 Zeichen beschreiben? Es sollte schnell und eindeutig einen Fehlerbericht identifizieren und das Problem erklären, nicht Ihre vorgeschlagene Lösung.

Gut : "Abbrechen eines Dateikopie-Dialogfelds stürzt im Dateimanager ab"

Schlecht : "Software stürzt ab"

Schlecht : "Browser sollte mit meiner Website funktionieren"

Komponente : In welchem ​​Teil der Software ist sie vorhanden? Dieses Feld ist erforderlich, um einen Fehlerbericht einzureichen. Klicken Sie auf das Wort „Component“, um eine Beschreibung der einzelnen Komponenten anzuzeigen. Wenn keine angezeigt wird, markieren Sie die Komponente "Allgemein".

OS : Auf welchem ​​Betriebssystem (OS) haben Sie es gefunden? (z. B. Linux, Windows XP, Mac OS X.) Beispiel: „Wenn Sie wissen, dass der Fehler auf mehreren Betriebssystemtypen auftritt, wählen Sie„ Alle “. Wenn Ihr Betriebssystem nicht aufgeführt ist, wählen Sie Andere.

Beschreibung : Die Details Ihres Problemberichts, einschließlich:

- Übersicht : Dies ist eine ausführlichere Darstellung der Zusammenfassung. Ein Beispiel wäre: "Durch Ziehen der Maus stürzt eine Seite ab, die Mac in der NSGetFactory-Funktion erstellt".

- Build-ID : Um dies zu finden, gehen Sie entweder über die Adressleiste auf die Seite "about:" oder, wenn Sie die Erweiterung "Nightly Tester Tools" von MozQA haben, auf "Tools |" Nightly Tester Tools und wählen Sie die Option aus, die die Ausgabe der Build-ID enthält. Es sollte ungefähr so ​​aussehen: "Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20090305 Firefox / 3.1b3".

- Zusätzliche Builds und Plattformen : Gibt an, ob der Fehler auf anderen Plattformen (oder gegebenenfalls in Browsern) auftritt. Es sollte ungefähr so ​​aussehen: "Tritt unter Mozilla / 5.0 nicht auf (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1b3) Gecko / 20081107 Firefox / 3.1b2".

Zu reproduzierende Schritte : Minimierte, leicht zu befolgende Schritte, die den Fehler auslösen. Stellen Sie bei Bedarf sicher, dass Sie spezielle Setup-Schritte ausführen. Ein gutes Beispiel hierfür sieht folgendermaßen aus: 1) Zeigen Sie eine beliebige Webseite an. (Ich habe die Standard-Beispielseite http://www.google.com/ verwendet. ) 2) Wählen Sie die Seite mit gedrückter Maustaste aus. Ziehen Sie den Mauszeiger bei gedrückter Maustaste von einem beliebigen Punkt im Inhaltsbereich des Browsers nach unten zum unteren Rand des Inhaltsbereichs des Browsers.

Tatsächliche Ergebnisse : Was die Anwendung nach Durchführung der obigen Schritte getan hat. Ein Beispiel wäre: Die Anwendung ist abgestürzt.

Erwartete Ergebnisse : Was die Anwendung hätte tun sollen, wenn der Fehler nicht vorhanden wäre. Ein Beispiel wäre: Das Fenster sollte nach unten scrollen. Gescrollter Inhalt sollte ausgewählt sein. Zumindest sollte die Anwendung nicht abstürzen.

Brian Snow
quelle
10
Ich verstehe nicht wirklich, warum das so viele Stimmen bekommen hat. Die Frage ist nicht "Wie schreibe ich einen anständigen Fehlerbericht?" aber "wie man Benutzer dazu bringt, einen anständigen Fehlerbericht zu schreiben".
Tamás Szelei
8
Diese Ressourcen richten sich hauptsächlich an technische Mitarbeiter. Mozilla ist auch die Organisation, die uns Bugzilla gebracht hat. Ich sage nicht , dass Bugzilla ist schlecht, aber es ist gemacht worden von Ingenieuren für Ingenieure: Es ist wirklich nicht ein Endbenutzer - Tool überhaupt .
Joachim Sauer
3
Muss mit @fish einverstanden sein. Wir können unseren Testern alle Richtlinien der Welt geben - lassen sie nicht wirklich nützliche Fehlerberichte erstellen. Und ich spreche von Leuten, die Fehler melden sollen. Wenn wir sie nicht mit Richtlinien motivieren können, haben wir bei den tatsächlichen Benutzern überhaupt keine Hoffnung. Das einzige, was wir als effektiv empfanden, war das aktive Schließen von "nutzlosen" Fehlerberichten als "nicht genügend Informationen" - sie bekamen die Nachricht dann ziemlich schnell. Ich
rate
3
Ich diskutiere überhaupt nicht über die Nützlichkeit des Beitrags (wirklich sehr gute Ressourcen), aber dies beantwortet die Frage nicht, und ich denke, die Abstimmungspolitik basiert darauf (ich könnte mich irren).
Tamás Szelei
1
Ich bin die Art von Person, auf die dies abzielte, und selbst ich konnte nicht durch das Lesen der ganzen Sache sitzen. Was lässt Sie glauben, dass Benutzer dies tun werden?
Tacroy
4

Es gibt Möglichkeiten, Fehler effektiv zu melden von Simon Tatham. Es erklärt die Dinge gut, um es weniger erfahrenen Benutzern verständlich zu machen. Der Nachteil ist jedoch, dass es sich um ziemlich viel Text handelt. Wenn ein Benutzer versucht, ein Problem zu melden, es jedoch nicht erklärt, kann er in der Regel nicht dazu verleitet werden, dies alles zu lesen.

Wladimir Palant
quelle
4

Sie können Benutzern leicht verständliche und leicht zu beantwortende Fragen stellen, um nützliche Berichte zu erhalten.

Beispiel: "Was war Ihre letzte Aktion vor diesem Fehler?", "Haben Sie versucht ... kurz vor diesem Fehler?".

Kein Benutzer würde Ihnen einen Fehlerbericht schreiben, der wie folgt lautet: "Mein Grafiktreiber ist nicht auf dem neuesten Stand. Ihre Grafikbibliothek ist möglicherweise nicht mit alten Grafiktreibern kompatibel."

Mert Akcakaya
quelle
3

Angenommen, die Benutzerbasis besteht aus Endbenutzern, die ein Problem mit der von Ihnen geschriebenen Software hatten.

Es ist nicht Ihre Aufgabe, ein kompetenter Software-Ingenieur oder Testprofi zu werden, und Sie sollten nicht erwarten, dass sie es tun. Ihre Benutzer sind Durchschnittsbürger, die zu Recht erwarten, dass die Software "nur funktioniert". Wenn dies nicht der Fall ist, melden sie, was sie für nötig halten, um Ihre Aufmerksamkeit zu erregen. Das können Sie nicht ändern und sollten es auch nicht versuchen. Jeder Versuch, auf der Art von Berichten zu bestehen, die von einem Fachmann erwartet werden, führt zum Verlust des Fehlerberichts und des Kunden: "Ich hatte ein Problem mit dieser Software, aber anstatt mir zu helfen, wurde alles ausgefüllt nutzlose Formen, die nichts bedeuten und für mich keinen Wert haben. Ich werde eine Software suchen, die tatsächlich funktioniert. "

Dh es ist nicht ihre Aufgabe .....

Wenn Sie gute Fehlerberichte wünschen, wenden Sie sich an Fachleute, um Ihre Fehler zu finden. Wenn Sie als Softwareentwickler keine Probleme mit Kunden haben, beschäftigen Sie jemanden, der dies kann.

mattnz
quelle
1
Ich glaube nicht, dass das OP sagt, dass sie sich nicht mit Benutzern befassen wollen. Ich denke, das OP sagt, dass sie basierend auf dem Fehlerbericht "Es ist abgestürzt" nichts wirklich reparieren können. Das OP möchte, dass die Benutzer, die sich beschweren, das meiste aus ihnen herausholen, damit das OP das Problem tatsächlich beheben kann.
Michael Kohne
1
Mein Punkt ist, dass, wenn "es abgestürzt ist", was aus der Sicht des Benutzers geschieht. Wenn ich mein Auto zu einem Mechaniker bringe, erwartet er nicht, dass ich ihm einen fachmännisch detaillierten Diagnosebericht über das, was falsch ist, sende - er stellt mir Fragen, damit er sein Fachwissen zur Diagnose des Problems nutzen kann. Zum Beispiel war ein Besuch meines Problems "Es bleibt stehen, wenn es kalt ist, aber es ist in Ordnung, wenn es heiß ist", ein paar wohlüberlegte Fragen (mit ja, keine Antworten) später war er sich ziemlich sicher (und stellte sich als richtig heraus), dass es ein Fehler war Thermometer. Unsere Aufgabe ist es, die Fragen zu stellen, gerahmt, um ja keine Antworten zu geben.
Mattnz