PHP Blogger

Startseite Schreib mir ne Mail! RSS Abo Webnews

Der ultimative Guide für Fehlerbeschreibungen

SOSEs ist doch immer das selbe: Ungenügende Fehlerbeschreibungen á la ”Das Programm funktioniert nicht”. Cool. Setzen, 6.

An alle N0bs, DAUs und Freds da draussen: Warum ist es so schwer, gescheite Fehlerbeschreibungen abzugeben? 

Wer remote (z.B. via E-Mail oder ICQ) geholfen bekommen möchte, geht wohl zwangsweise davon aus, das die potentiellen Helfer hellsehen können. Hallo? Wir haben keine Glaskugel auf dem Schreibtisch. Meckern allein hilft nicht, deshalb gibts jetzt hier auf dem PHP Blogger den ultimativen Guide für Fehlerbeschreibungen. Die URL werde ich allen Kunden, Freunden und Bekannten die mich um Hilfe fragen schicken.

In der Hoffnung, das es in Zukunft besser wird, sollten also folgende Fragen von der Fehlermeldung beantwortet werden:

  1. Wird eine nicht erwartete Funktion ausgeführt oder passiert gar nichts?
  2. Wenn gar nichts passiert, wird wenigstens ein optischer Hinweis gegeben (Fehlermeldung, sonstige Veränderung des Bildschirms)
  3. Besteht das Problem immer oder nur in einer besonderen Situation?
  4. Wenn es nur in einer besonderen Situation auftritt - ist es reproduzierbar?
  5. Wie lauten die einzelnen Schritte, um zu dem Problem zu kommen?
  6. Tritt das Problem bei einer Reproduktion immer an der selben Stelle auf?
  7. Wenn es zufällig aufzutreten scheint, gibt es Parallelen, die zu beobachten sind?
  8. Wenn es nicht reproduzierbar ist, welche Arbeiten wurden bevor der Fehler auftrat durchgeführt?
  9. Wenn eine nicht erwartete Aktion durchgeführt wird, wird immer die selbe Aktion durchgeführt oder wechseln die Aktionen?
  10. Wenn die nicht erwarteten Aktionen wechseln, wird eine Reihenfolge beibehalten oder passiert das Wechseln zufällig?
  11. Kann man das Problem mit einem anderen Computer (z.B. beim Kollegen) nachvollziehen?
  12. Wenn man es nicht nachvollziehen kann, mit welchem Computer wurde getestet?
  13. Kann man das Problem mit einem anderen Benutzer (z.B. vom Kollegen) nachvollziehen?
  14. Wenn man es nicht nachvollziehen kann, wie heisst der Benutzer?
  15. Wurden bereits Aktionen zur Problemlösung ausprobiert?
  16. Wenn bereits versucht wurde, das Problem zu lösen, welche Aktionen wurden ausgeführt?
  17. Wurde die Situation deshalb verschlimmert oder ist der Zustand nach wie vor der selbe?
  18. Verhindert das Problem die Weiterarbeit im Programm? Oder kann man es ignorieren? 
  19. Gibt es eine alternative Möglichkeit, um die Aufgabe im Programm zu erledigen? 
  20. Wurden alternative Möglichkeiten ausprobiert, um die Aufgabe im Programm zu erledigen?
  21. Wenn nein, bitte erst ausprobieren.
  22. Wenn ja, welche Möglichkeiten gibt es und welche führen zum erwünschten Ergebnis?

 Bitte auf KEINEN Fall, wirklich niemals:

  1. Wild darüber spekulieren, was den Fehler verursachen könnte.
  2. Vergleiche zum täglichen Leben ziehen.
  3. Den Fehler selbst beheben wollen.
  4. Jemand um Problemhilfe bitten, der sich “gut mit dem Computer auskennt”.
  5. Den richtigen Ansprechpartner ganz zum Schluss anrufen.
  • MisterWong
  • del.icio.us
  • Technorati
  • Digg
  • Slashdot
  • YahooMyWeb
  • Furl
  • Ma.gnolia
  • Spurl
  • Netscape
  • StumbleUpon
  • MyShare
  • blogmarks

latita meint dazu:

15. Januar 2008 um 16:54

das würde sich gut in einer Grafik machen ^^ Da kann dann der Betreffende mit dem Finger die Linien entlangfahren um zu sehen was er schon gemacht hat oder machen muss

timi meint dazu:

15. Januar 2008 um 16:58

Hehe stimmt :) Mal schauen vielleicht hab ich die Woche mal Zeit für ein kleines Flowchart…

Nikolas meint dazu:

15. Januar 2008 um 17:13

Was ich immer wieder beobachte ist, dass Tester den Fehler bei sich vermuten und nicht am Programm. Wenn irgendwas nicht klappt meinen sie immer, sie wären unfähig, dass Programm zu bedienen, vermuten daher keinen Fehler und sagen es mir dementsprechend nicht.

timi meint dazu:

15. Januar 2008 um 17:20

Jo, das hatte ich auch des öfteren. Genauso gibts aber User, die generell *nix* machen und immer die Schuld auf die Applikation schieben.

Nils Hitze meint dazu:

15. Januar 2008 um 17:38

Vergiss es, das setzt sich nie durch … hier wird immer erst mal laut geschrieen und geflucht … trotzdem ein schöner Artikel

Brati meint dazu:

18. Januar 2008 um 17:31

“Wild darüber spekulieren, was den Fehler verursachen könnte.”
Also das kann man durchaus machen, wenn man dazu auch noch eine saubere Fehlerbeschreibung schreibt.
Ich hatte bei TheManaWorld (OpenSource 2D-MMORPG) ein Problem (das Programm stürzte immer ab) und habe dann erzählt, seit wann das Problem auftritt, dass neues Herunterladen der Dateien nichts brachte, die Log-Datei mitgepostet und noch spekuliert, dass der Fehler wohl im neuesten Update liege. Daran lag es meines Wissens dann auch. Der Admin meinte irgendwas von New Particle System oder so.

Also man kann ruhig spekulieren, wenn man etwas Ahnung vom Thema hat und zuvor einen sauberen Text über die Symptome (deine vielen Fragen) postet.

Computer Freak meint dazu:

21. Januar 2008 um 20:16

Den vierten Punkt der negativ-Liste solltest du fett schreiben - es ist wirklich faszinierend, was passieren kann, wenn sich mehrere Nichtswisser zusammenrotten ;)

Zu deinem Guide hab ich mir ein Lesezeichen gesetzt. Der nächste Kunde, der mir wieder mitten in den Nacht dumm kommt, bekommt den vorgesetzt.

RSS für Kommentare zu diesem Artikel · TrackBack URI

Schreib Deine Meinung