Kurzform - korrekte Fehlermeldung besteht immer aus:

• Worum geht es (url, Screenshot, Beschreibung)
• Was wurde gemacht? Wie können wir es reproduzieren?
• Was ist das falsche Verhalten/Ergebniss?
• Was ist das korrekte Verhalten/Ergebniss?
• Geht es in gewissen Fällen und in anderen nicht?
• Screenshots verwenden(!) Bild sagt mehr als tausend Worte(!)

"Das Haus ist gelb" - Beispiele für gängige und extrem schlechte Fehlermeldungen

Wir wissen nicht was gemacht wurde. Wir haben keine Ahnung auf welcher Seite/System etwas gemacht wurde. Wir wissen nicht was der korrekte Fall ist. Wir wissen nicht welche Daten verwendet wurden. Wir wissen basierend auf solchen Aussagen schlicht überhaupt nichts. Weder wissen wir was falsch / richtig ist. Noch wo wir überhaupt starten sollen mit der Suche.

Wir sind komplett auf Ihre Informationen angewissen um Ihnen helfen zu können (!)

Leider erhalten wir Informationen wie

"Das Haus ist gelb"

Gemeint kann hier sein:

"Das Haus ist gelb" und alles ist in Ordnung

"Das Haus ist gelb" es sollte aber grün sein

"Das Haus ist gelb" es sollte aber ein Karusell sein

"Das Haus ist gelb" es sollte sich aber drehen

"Das Haus ist gelb", wenn ich es per Smartphone öffne (ansonsten ist es blau und dreht sich)

"Das Haus ist gelb", wenn ich durch die Haustür rausgehe (durch das Fenster bleibt es blau)

[...] endlose Optionen was damit gemein sein soll.

Solche Meldungen, die einfach etwas beschreiben ohne jegliche Einordnung zur Aussage sind komplett unbrauchbar.

[/span12]

1. Worum geht es? - Adminbereich / Frontend / welche Erweiterung / Funktion / URL/ Bereich ....

Beschreiben Sie uns immer(!) worum es geht. Um was für einen Bereich geht es.

Url zum Bereich ist das eindeutigste. Die URL ist eindeutig und wenn möglich sollte diese immer genannt werden. Wenn die url genannt ist, kann es unmöglich Missverständnisse geben um was für einen Bereich es geht.

Falls dies nicht geht fügen Sie immer(!) einen Screenshot hinzu. Dieser darf auf keinen Fall einen zu kleinen Ausschnitt zeigen. Es muss klar sein in welchem Kontext der Screenshot aufgenommen wurde. Smartphone? Tablet? Welche Menü? Bereich. All das lässt sich bei einem Screenshot einfach ableiten

Idealerweise Url und Screenshot

Ziel muss sein, dass wir sofort wissen um was es geht. Kein Suchen einfach nur den Bereich aufrufen und es geht weiter.

2. Was wurde gemacht (und wann)?

Beschreiben Sie uns so exakt wie nur möglich was gemacht wurde. z.B. Sie haben den Wert XY eingefügt, dann auf den Button ABC geklickt. Dann kam die Meldung ABC.

Wenn Sie Werte verwendet haben kopieren Sie diese wenn möglich bitte immer mit in die E-Mail/Ticketsystem. Es ist nichts schlimmer als komplett unnnötig Werte von einem Screenshot abzutippen. Das ist als würden wir Ihnen ein Fax schicken mit bitte die URL darauf abzutippen. Es ist komplett unnötig.

Machen Sie lieber zuviele Screenshots als zuwenig. Markieren Sie auf den Screenshots idealerweise auch das was Sie meinen. Egal wie "formlos" es ist. Ein kleiner "Kringel" an der entscheidende Stelle kann zwischen verstehen und nicht verstehen unterscheiden.

Geben Sie auch immer eine Info zum "wann". Haben Sie es "jetzt" gemacht? war es vor X Tagen usw. Auch die zeitliche komponente kann in vielen Fällen entscheidend sein.

Erklären Sie uns was Sie gemacht haben, als wären wir komplett dumm. Erklären Sie lieber zu ausführlich was Sie gemacht haben, als dass Sie Dinge weglassen. Leider sind es teils mini Details die Fehler verursachen.

Ziel muss sein, dass 100% verständlich ist was Sie gemacht haben. Idealerweise können wir es so reproduzieren und exakt das selbe passiert bei uns auch.

3. Was war falsch? Was ist überhaupt der Fehler?

Es reicht auf keinen Fall aus zu beschreiben was gemacht wurde und es ist eine Fehlermeldung. Es muss klar aufgezeigt werden was der Fehler ist.

z.B.

Wert XY eingefügt, Button ABC geklickt und die Fehlermeldung XY ist erschienen.
Die Fehlermeldung XY ist jedoch falsch, weil diese gilt für den Fall ABD

Es ist somit klar, dass die Fehlermeldung XY der Fehler ist

Es muss für uns komplett eindeutig sein, was überhaupt der Fehler ist. Ansonsten besteht die hohe Wahrscheinlichkeit, dass wir keine Ahnung haben, was Sie meinen. Sie arbeiten womöglich stündlich mit Ihrem System und wissen aus dem Kopf was für Ausgaben/Reaktionen falsch sind und warum. Wir nicht.

4. Wie hätte es sein sollen? Was ist der korrekte Ablauf/Verhalten?

Wir wissen nun wo der Fehler auftritt. Wissen wie Sie Ihn erzeugt haben und können den Fehler idealerweise so reproduzieren. Dazu wissen wir was der Fehler überhaupt ist.

Nun fehlt das entscheidende. Wie ist es korrekt?! Denken Sie bitte an "Das Haus is gelb". Wir haben womöglich keine Ahnung wie die Farbe oder Drehrichtung des Hauses sein soll. Erläutern Sie daher immer und lieber zuviel als zu wenig wie der korrekte Fall ist.

Angaben wie "15 ist falsch" helfen nicht weiter. Wir brauchen die komplette Info z.B. "15 ist falsch. Weil 5 + den im Admin hinterlegte Faktor 20, hätte 25 ergeben müssen"

korrekt wäre z.B.

Ich habe den Wert XY eingefügt, Button ABC geklickt und die Fehlermeldung XY ist erschienen.
Die Fehlermeldung XY ist jedoch falsch, weil diese gilt für den Fall ABD
Es hätte die Meldung "Das ist ein Baum" erscheinen müssen, weil ich den Button "Baum" angeklickt habe und den Wert 13 eingefügt habe.

So ist für uns eindeutig, wie der korrekte Fall aussieht. Wir können Somit prüfen warum der Fehler erschienen ist. Dazu ist es jedoch nötig nicht nur den Fehler zu kennen sondern auch was überhaupt der korrekte Fall sein soll.

Ziel muss es sein, dass wir wissen was hätte passieren sollen. Nur so können wir beurteilen was überhaupt angepasst/geprüft werden muss. 

5. Wo funktioniert es? Funktioniert es in anderen Fällen?

Es ist extrem wichtig, dass Fälle in denen der Fehler auftritt  von Fällen abgegrenzt werden, wo dieser nicht auftritt.

Denken Sie bitte an das Beispiel "Das Haus ist gelb". Wenn das Haus gelb ist, bei Nacht. Am Tag aber blau und es soll blau sein. Dann ist das eine extrem wichtige Info, die auf keinen Fall fehlen darf.

Insbesondere bei komplexen Fehlern ist es super wichtig über die Fälle wo es funktioniert, gewisse Ursachen ausschließen zu können.

Dies kann praktisch sein z.B.

Aufruf per Smartphone funktioniert, per Desktop jedoch nicht. Die Funktion funktioniert auf dem Testystem, aber nicht auf dem produktivem System. Bei Eingabe von Wert XY geht es, bei Eingabe von ABC jedoch nicht.

Dies ist jedoch nur relevant, wenn der Fehler an gewissen Stellen auftritt und an anderen nicht. Dann darf diese Info auf keinen Fall "vergessen" werden.

Ziel muss es sein, dass wir wissen wo und wie es funktionierte und wo nicht. Es ist ein riesiger Unterschied ob eine Funktion unter Bedingung XY geht oder nicht geht oder ob die komplette Funktion defekt ist.

6. Lieber zuviele Infos als zu wenige - urls und Screenshots

Denken Sie bitte immer daran, dass es für Sie womöglich nur wenige Sekunden sind die Info uns mitzuteilen. Wenn wir genau diese aber nicht finden bzw. erraten, finden usw. kostet es uns alle womöglich Stunden an komplett unnötiger Zeit

Denken Sie bitte immer daran, dass wir letztlich mit so wenig Aufwand wie möglich das beste mögliche Ergebniss liefern möchten. Das geht nur, wenn sich jeweils in den anderen reinversetzt wird.

Ein Screenshot ist in wenigen Sekunden erstellt. Eine Url in wenigen Sekunden kopiert und in eine Mail/Ticketsystem gefügt. Ein Wert ist in Sekunden kopiert (wir hassen es Werte von Screenshots abzutippen obwohl diese hätten als Text mitgeschickt werden können)

Die Qualität der Fehlerbehebung wird maßgeblich von dem Input bestimmt. Je schlechter und ungenauer die Informationen sind umso unwahrscheinlicher ist eine zeitnahe oder auch sinnvolle Hilfe. Ein Screnshot oder URL ist viel eindeutiger als nur eine Beschreibung.

7. Besser strukturiert als womöglich missverständliche Fließtexte

Eine klare deutliche Struktur ist immer einfacher zu verstehen als ein Fließtext. Der Sinn einer Fehlermeldung ist kein schöner Text zu werden. Es geht darum die Informationen so verständlich und eindeutig wie nur möglich zu übermitteln. Klare Strukturierung hilft dort meist sehr.

z.B. kann es wie folgt aussehen:

Was gemacht wurde:

Ich habe den Wert XY eingefügt, Button ABC geklickt und die Fehlermeldung XY ist erschienen.

Falsch ist:
Die Fehlermeldung XY ist jedoch falsch, weil diese gilt für den Fall ABD.

Korrekt wäre:
Es hätte die Meldung "Das ist ein Baum" erscheinen müssen, weil ich den Button "Baum" angeklickt habe und den Wert 13 eingefügt habe.

Fehler tritt nicht auf:
Wenn statt der 13 eine 15 eingegeben wird, verhält es sich normal. Dann erscheint die Meldung "Das ist ein Baum". Es tritt scheinbar nur bei Wert 13 auf. Andere Fälle bei denen es korrekt funktioniert konnte ich keine finden.