oder:
The Hitch-Hiker's Guide to Bug-Reports
Es ist inzwischen in Mode gekommen, Software keiner großen Testphase mehr auszusetzen. Stattdessen werden 'Previews', 'Betaversionen' und 'Vollversionen' an die Endkunden verteilt, die damit unfreiwillig zu zahlenden (und nicht bezahlten) Betatestern werden. Allerdings dürfte das eher eine Entscheidung des Managements sein, als von den Programmierern selber - zumindest bei größeren Softwarefirmen.
Im Amiga-Bereich werden jedoch viele Programme von einer einzigen Person designt, entwickelt und gewartet und "nebenbei" gibt es für diese dann auch noch den Beruf und das Privatleben.
Es gibt eine Vielzahl von Büchern, die einem Ratschläge geben, wie man am besten seine Software entwickelt, testet und Fehler ausmerzt. Die schlechteren zeigen einem DEN Weg, die besseren sagen, daß es keinen goldenen Weg gibt.
Jedoch hat kaum jemand den Anwendern erklärt, wie sie dem Programmierer am besten helfen können vorhandene Fehler zu beseitigen. Daher gebe ich hier einige - meiner Meinung nach - wichtige Ratschläge für das Schreiben von Bugreports. Die Liste ist weder vollständig, noch erhebt sie Anspruch auf Makellosigkeit.
Ich gehe hierbei von dem "durchschnittlichen Amiga-Hobby-Programmierer" als Empfänger des Bug-Reports aus, der per eMail meist sehr einfach direkt zu erreichen ist. Bei Softwarefirmen sind die Punkte evtl. leicht anzupassen.
Kein Programmierer fügt dem Programm absichtlich Fehler hinzu (okay, insbesondere bei mindestens einem großen Softwarehaus bin ich mir da nicht so sicher ;). Wenn Du also einem Programmier einen Fehler beschreibst, sei freundlich!
Es bringt nichts gleich eine eMail der Form: "Hey, dein Schei*-Programm ist gecrashed und ich habe damit X Std. Arbeit verloren. This sucks!" zu schreiben.
Einerseits: wer zig Stunden arbeitet ohne zu Speichern, ist selber Schuld und andererseits wird der Programmierer nur demotiviert und verständlicherweise verärgert sein. Am Ende lag der Absturz vielleicht nicht einmal an dessen Programm, sondern an irgendeinem sekundären Programm/Problem (z.B. können sich durch die Erwärmung des Rechners bereits lockere Karten oder Chips soweit lösen, daß der Kontakt verloren geht).
Merke:
Schreibe nicht im Zorn und mache Dir klar, daß der Programmierer nichts
absichtlich getan hat, um Dich zu ärgern.
Viele Programme haben eingebaute Sanity-Checks, die noch bestimmte Informationen ausgeben, bevor das Programm abbricht. Diese Requester wurden vom Programmierer eingebaut, um die Fehlersuche zu erleichtern. Allerdings wird dazu der Text und insbesondere die Fehlernummer (falls vorhanden) benötigt. Wichtig ist es auch, zu wissen, ob es sich um Requester des Programmes selber oder um Betriebssystem-Meldungen handelt.
Es hilft dem Programmierer nur wenig, wenn er die Information bekommt: "Da kam dann ein Requester mit dem Text 'blabla Fehler Nr. 42xx', den habe ich aber gleich wieder weggeklickt." und der Anwender dabei nicht mehr weiß, welche Ziffern bei 'xx' standen.
Merke:
Notiere Dir genau, welchen Inhalt Fehlermeldungen haben und von welchem
Programm sie stammen.
Versuche den Fehler soweit einzugrenzen, daß Du ihn auf Wunsch nachvollziehen kannst. Zum Beispiel kann man versuchen, die Daten zu finden, die das Programm zum Absturz bringen. Dadurch, daß Du den Fehler eingeschränkt hast und ihn reproduzieren kannst, ist ein großer Schritt getan. Der Programmierer kann nun gezielter auf die Ursachensuche gehen und es wird viel schneller gehen, herauszufinden, ob der Bugfix wirklich geholfen hat.
Merke:
Versuche genau festzustellen, wodurch der Fehler auftritt und teile das
dem Entwickler mit (und zwar nur den wichtigen Teil, siehe Regel 6).
Wenn Du den Fehler reproduzieren kannst oder er zumindest relativ häufig auftritt, versuche herauszufinden, ob es vielleicht an einem Programm liegen kann, das im Hintergrund läuft. Spitzenkandidaten sind Patches bzw. Hacks wie MCP, MagicMenu und ähnliche. Einige Programmierer beachten ein Bugreport schon nicht mehr so ernsthaft, wenn man es nicht auch ohne MCP probiert hat. Versuch auch von den Libraries aktuelle Versionen zu bekommen bzw. entferne irgendwelche Replacements oder Hacks (z.B. MagicASL).
Merke:
Schließe aus, daß der Fehler durch ein anderes oder nicht richtig
installiertes Programm entsteht. Wenn Du das nicht kannst, teile es dem
Programmierer mit, damit er feststellen kann, welches Programm fehlerhaft
ist.
Jedes System ist anders. Kaum zwei Anwender haben das selbe System - weder von der Hardware (die es meist auch in verschiedenen Versionen/Revisionen gibt!) geschweige denn von der Software.
Gebe dem Programmierer daher die nötige Beschreibung Deines Systems, aber übertreibe es auch nicht. Du brauchst nicht jedes Programm, Tool und Bild auf deiner Partition aufzählen. Meist lassen sich die wichtigsten Informationen in weniger als einer Zeile zusammenfassen. Meist reicht die Angabe des Rechners (CPU, OS-Version, Filesystem) und der Programme, die im Hintergrund mitlaufen (insbesondere Patches/Hacks wie MCP).
Wäge auch ab, welche Informationen in Bezug auf den Fehler wichtig sein können. Falls z.B. ein Fehler bei Dateioperationen auftritt, ist es wichtig anzugeben, ob man vielleicht ein ungewöhnliches Dateisystem benutzt, wie z.B. SFS oder PFS. Wenn allerdings beim Öffnen eines Fensters nur Grafikmüll dargestellt wird, ist es wichtiger zu wissen, welche Grafikkarte und Grafiktreiber (Picasso96, CyberGraphX, ...) man benutzt, statt welches Dateisystems.
Falls eine längere 'Unterhaltung' mit dem Programmierer stattfindet, können andere Angaben immer noch nachgereicht werden (um dem Programmierer vielleicht auf eine neue Idee zu bringen), bzw. wird der Programmierer nachfragen.
Merke:
Gib eine aussagefähige Kurzbeschreibung Deines Systems und wichtige
Informationen in Bezug auf den konkreten Fehler an und vergiß die
Versionsnummer des Programmes nicht!
Schreibe vollständige, aber dennoch knappe Beschreibungen. Es mag zwar interessant sein, an welchem Projekt Du gerade gearbeitet hast, als Du den Fehler entdeckt hast, aber vergiß nicht, daß es Dein Ziel ist, dem Programmierer einen Bugreport zu schreiben und nicht deinen Lebenslauf.
Merke:
Schreibe so wenig wie möglich, aber nicht weniger!
Wenn Du Programmierern häufiger hilfst, dann mache Dich möglichst mit den gängigen Debug-Tools in so weit vertraut, daß Du sie anwenden kannst und dem Programmierer die richtigen Informationen schicken kannst. Vielleicht mögen Dir die kryptischen Ausgaben des Enforcers nichts sagen, dem Programmierer können sie jedoch sehr helfen.
Merke:
Verwende, soweit es geht, Debug-Tools, um zusätzliche Informationen zu
dem Fehler zu erhalten und dem Programmierer seine Arbeit zu erleichtern.
Habe Geduld! Bugfixen ist meist eine langwierige Arbeit, die auch nach Stunden nicht zwangsweise mit Erfolg gekrönt ist. Einige Fehler können auch in früheren Designentscheidungen liegen, die sich nicht so einfach wieder rückgängig machen lassen. Ansonsten hat der Programmierer vielleicht auch einfach nicht die Zeit momentan daran zu arbeiten.
Merke:
Habe Geduld und beschwere Dich nicht, wenn nächste Woche noch kein Bugfix
vorliegt (d.h. aber auch nicht, daß Du alles hinnehmen sollst. Versuche
einen guten Mittelweg zu finden).
Auch wenn Du keinen Fehler gefunden hast, schreibe dem Programmierer! Dadurch weiß dieser einerseits, daß sein Programm überhaupt benutzt wird und andererseits motiviert es auch einfach, wenn jemand schreibt, daß die Software tadellos läuft. Es muß ja kein Roman sein, den Ihr schreibt, zwei formlose Zeilen reichen schon aus und dauern auch keine Ewigkeit zu Schreiben (und trotzdem können sie einen Programmierer glücklich machen ;).
Merke:
Schreibe dem Programmierer auch dann, wenn Du keinen Fehler gefunden hast.
|
Inhaltsverzeichnis | |
| © `99 Der AmZeiger | ||