Joel on Software   Joel über Software

Andere auf Deutsch verfügbare "Joel on Software"-Artikel

Andere auf Englisch verfügbare "Joel on Software"-Artikel

Email an den Verfasser (nur auf Englisch)

TRS-80 Level-I BASIC konnte nur zwei Stringvariablen speichern: A$ and B$. Genauso wurde ich mit nur zwei Bugspeicherplätzen in meinem Kopf geboren: ich kann mir immer nur zwei Bugs auf einmal merken. Wenn ich mir Drei merken soll, fällt einer auf die Erde, wird unter das Bett gefegt und landet bei den Staubmäusen, die ihn auffressen.

Die Benutzung einer Bugdatenbank ist eines der Kennzeichen eines guten Entwicklerteams. Ich wundere mich immer wieder darüber, wie selten das wirklich getan wird. Eine der größten Fehleinschätzungen, auf die Entwickler immer wieder reinzufallen scheinen, ist der Glaube, dass sie sich alle Bugs im Kopf merken, oder mit Hilfe von Post-It Zetteln den Überblick behalten können.

Wenn Sie ein wenig Zeit haben, dann würde ich Ihnen gerne einen einfachen Weg darstellen, wie man Bugverwaltung betreiben kann; im Sinne meiner früheren Artikel über Terminpläne leicht gemacht und Spezifikationen leicht gemacht.

Zuerst einmal braucht man eine richtige Datenbank. Bei einem 2-Personen-Team, das während eines langen Wochenendes ein bisschen programmiert, reicht dafür eventuell eine Textdatei. Sobald es darüber hinausgeht braucht man eine richtige Bugverwaltungs-Datenbank. Es gibt Tausende käuflicher Bugdatenbanken. (Schamlose Eigenwerbung: Die Bugdatenbank, die wir bei Fog Creek Software geschrieben haben (FogBUGZ), ist web-basiert, ziemlich einfach zu benutzen und recht leistungsfähig, wenn ich das hier selbst mal so sagen darf).

Beobachten wir mal zur Verdeutlichung einen Bug auf seinem Lebensweg vom ersten bis zum letzten Atemzug. Folgen wir dem berühmten Bug 1203. Hier ist, was die Bugdatenbank uns über in erzählt:

Was ging da vor?

Mikey, der Entwickler, schreibt an seinem neuen FTP-Client-Feature für seine coole Macintosh-Software. Irgendwann schreibt er dabei seine eigene String-Kopierfunktion, weil er unbedingt seinen Spieltrieb befriedigen muss. Die mit ihrer nervigen Wiederverwendungsrichtline! Hah!

Es geschehen schlimme Dinge, wenn man Code nicht wiederverwendet, Mikey! Und diesmal geschah Folgendes: Mikey vergaß, den kopierten String mit einem "Null" Zeichen abzuschließen. Aber das Problem trat bei ihm nie auf, weil er die meiste Zeit in einen Speicherbereich kopierte, dessen Bytes bereits mit "Null" initialisiert waren.

Einige Tage später ist Jill, die sehr, sehr gute Testerin, dabei den Code zu quälen, indem sie Ihre Stirn auf der Tastatur vor- und zurückrollt - oder einen vergleichbar grausamen Test durchführt. (übrigens heißen die meisten guten Tester Jill oder so ähnlich, wie zum Beispiel Gillian) Plötzlich passiert etwas sehr Seltsames: Der FTP Server, auf dem sie testet, stürzt ab. Ja, ich weiß, es ist eine Linux Maschine und Linux Maschinen stürzen nie ab (kein Grummeln aus der slashdot-Ecke, bitte), aber diese verdammte Kiste stürzte nun mal ab. Und dabei hat sie den Server nicht mal berührt. Sie übertrug nur Dateien auf den Server, indem sie Mikeys Mac Code benutzte.

Nun, Jill ist eine sehr, sehr gute Testerin, also schrieb sie genau auf, was sie tat (zum Beispiel zeichnet sie genau auf, in welchem Winkel und in welchem Takt sie ihren Kopf auf der Tastatur hin- und herrollte). Sie fährt alles neu hoch und fängt mit einem frischen System an, wiederholt die Schritte und siehe da: es passiert wieder! Der Linux FTP Server stürzt wieder ab! Zum zweiten Mal an einem Tag! Hörst Du, Linus?

Jill guckt auf die Liste der Schritte, mit denen der Bug reproduziert werden kann. Es sind etwa 20 Schritte. Manche von ihnen scheinen nicht maßgeblich zu sein. Nach einigem Rumprobieren schafft Jill es, die Liste auf 4 Schritte zu reduzieren, die den Fehler immer hervorrufen. Jetzt ist sie soweit, den Bug einzutragen.

Jill trägt einen neuen Bug in die Bugdatenbank ein. Der Vorgang des Eintragens erfordert einige Disziplin, denn es gibt gute und schlechte Bugberichte.

Drei Teile eines guten Bugberichts

Und der Herr hob an und sprach also: "Zuerst sollest du den Heiligen Zündring ziehen. Dann sollest du zählen bis drei, nicht mehr und nicht weniger. Drei soll die Zahl sein, die du zählest, denn die Zahl zu zählen sei Drei. Vier sollest du nicht zählen, noch zähle auf Zwei, es sei denn, du schreitest hernach voran zur Drei. Fünf ist zu viel. Hast du dann erreicht die Drei, welche ist die dritte Ziffer unter den Ziffern, so werfe denn deine Heilige Handgranate Antiochias gegen deinen Feind, der in Meinen Augen ungehörig ist, und darob ausgelöschet werde."

-- Monty Python: Die Ritter der Kokosnuss

Es gibt eine sehr leicht zu merkende Regel für einen guten Bugbericht:
Jeder gute Bugbericht braucht genau drei Dinge.

1. Schritte, mit denen man den Bug reproduzieren kann
2. Was man zu sehen erwartet hatte, und
3. Was man statt dessen gesehen hat

Scheint einfach zu sein, oder? Vielleicht aber auch nicht. Als Entwickler bekomme ich des öfteren Bugs zugewiesen, bei denen der eine oder andere Teil ausgelassen wurde.

Wenn du mir nicht sagst, wie ich den Bug reproduzieren kann, dann weiß ich womöglich gar nicht, wovon du sprichst. "Das Programm stürzte ab, und hinterließ einen stinkenden Kuhfladen auf meinem Arbeitsplatz." Wie schön, Liebling. Ich kann aber nichts machen, wenn du mir nicht sagst, was du getan hast. Gut, ich muss zugeben es gibt zwei Fälle, in denen es schwierig ist zu sagen, wie ein Bug zu reproduzieren ist. Manchmal kann man sich einfach nicht mehr erinnern, und manchmal schreibt man den Bug aus einem Bericht vom "Feld" ab. (Apropos, wieso nennt man das eigentlich "Feld"? Ist das sowas wie ein Roggenfeld? Egal ...). Der andere Fall ist, wenn der Fehler nicht immer auftritt. Aber Schritte zur Reproduktion sollte man trotzdem angeben, mit einem Hinweis darauf, dass der Bug damit nur manchmal auftaucht, nicht immer. Solche Bugs sind schwer zu finden, aber wir können es ja wenigstens versuchen.

Wenn man nicht angibt, was man erwartet hat, dann werde ich warscheinlich nicht verstehen, wieso das ein Bug sein soll. "Auf dem Startbildschirm sind Blutspritzer". Na und? Ich hatte mir in den Finger geschnitten, als ich ihn programmiert hab', also was willst du? Ach, du meinst die Spezifikationen erfordern "kein Blut". Jetzt weiß ich, wieso du meinst, dass dies ein Bug ist.

Teil drei: Was man statt dessen gesehen hat. Wenn das nicht drin steht, dann weiß ich nicht, was überhaupt falsch ist. Das ist offensichtlich.

Zurück zu unserer Geschichte

Nun gut. Jill trägt den Bug ein. In einem guten Bug-Verfolgungssystem wird der Bug automatisch dem leitenden Entwickler für dieses Projekt zugewiesen. Und darin liegt das zweite Konzept: Jeder Bug muss genau einer Person zu einem Zeitpunkt zugewiesen sein, bis er "geschlossen" wird. Ein Bug ist wie eine heiße Kartoffel: Wenn er dir zugewiesen ist, dann musst du ihn beheben oder ihn jemand anderem zuweisen.

Willie, der leitende Entwickler, schaut sich den Bug an, beschließt dass das etwas mit dem FTP Server zu tun haben muss, und löst ihn als "wird nicht behoben". Schliesslich haben wir den FTP Server nicht geschrieben.

Wenn ein Bug gelöst ist, dann wird er wieder der Person zugewiesen, die ihn eingetragen hat. Das ist ein wichtiger Punkt. Er verschwindet nicht, weil der Entwickler meint, er sollte. Die goldene Regel sagt, dass nur die Person, die den Bug eingetragen hat, ihn auch abschließen kann. Der Entwickler kann den Bug lösen, das heißt "Hey, ich denke, das ist erledigt", aber um den Bug wirklich abzuschließen und ihn aus den Büchern zu streichen, muss die ursprüngliche Person, die ihn eingetragen hat, bestätigen dass das Problem wirklich behoben ist, oder dass der Bug aus irgend einem bestimmten Grund nicht bearbeitet werden muss.

Jill bekommt eine E-Mail, die ihr mitteilt, dass der Bug wieder auf ihrem Tisch liegt. Sie schaut ihn sich an, und liest Willies Kommentar. Irgendwas stimmt da aber nicht. Dieser FTP Server wird seit vielen Jahren überall benutzt, und er stürzt nicht ab. Er stürzt nur ab, wenn man Mikeys Code benutzt. Also reaktiviert Jill den Bug wieder, erklärt ihre Meinung, und der Bug geht wieder zurück an Willie. Dieses Mal weist Willie den Bug Mikey zu.

Mikey untersucht den Bug, denkt lang und heftig nach, und stellt eine völlig falsche Diagnose. Er löst ein ganz anderes Problem, und setzt unseren Bug dann auf "gelöst".

Der Bug ist zurück bei Jill, dieses mal markiert als "GELÖST - BEHOBEN". Jill probiert ihre Schritte, mit denen sie den Bug reproduzieren kann, und siehe da: Der Linux Server stürzt wieder ab. Sie reaktiviert den Bug erneut und weist ihn direkt Mikey zu.

Mikey ist perplex, aber schlussendlich findet er die Ursache des Fehlers. (Wissen Sie noch, was es war? Die Antwort überlasse ich dem Leser als Übung. Hinweise habe ich genug gegeben!) Er behebt ihn, testet ihn und - Eureka! Jills Reproduktionsschritte schießen den FTP Server nicht mehr ab. Erneut setzt er den Bug auf "GELÖST - BEHOBEN". Jill probiert es wieder aus, sieht dass der Bug nun behoben ist, und schließt den Fall.

Die 10 besten Tipps für Bugmanagement

1. Ein guter Tester wird immer die Zahl der nötigen Schritte zum Reproduzieren auf ein Minimum reduzieren; dies ist sehr hilfreich für den Entwickler, der den Bug finden muss
2. Denken Sie daran, dass die einzige Person, die einen Bug schließen kann, die Person ist, die ihn zu Anfang geöffnet hat. Jeder kann ihn lösen, aber nur die Person die den Bug entdeckt hat, kann sicher feststellen ob er behoben wurde.
3. Es gibt viele Arten einen Bug zu lösen. FogBUGZ lässt Sie Fehler als behoben, wird nicht behoben, verschoben, nicht reproduzierbar, Duplikat oder ist kein Fehler lösen.
4. Nicht reproduzierbar heißt, dass niemand den Bug je wieder reproduzieren konnte. Programmierer nutzen das oft, wenn die Reproduktionsschritte nicht angegeben waren.
5. Sie sollten eine genaue Übersicht über die Versionen haben. Jede Entwicklungsstufe der Software, die an die Tester geht, sollte eine eindeutige Nummer (Build-ID) haben, damit der arme Tester den Bug nicht erneut mit einer Version testet, in der er noch gar nicht als behoben gekennzeichnet ist.
6. Wenn Sie ein Programmierer sind, und Schwierigkeiten haben, die Tester zur Benutzung der Bugdatenbank zu bringen, akzeptieren Sie einfach keine Fehlerberichte auf eine andere Art. Wenn es die Tester gewöhnt sind, Ihnen E-Mails mit Bugmeldungen zu schicken, dann schicken Sie die Mails einfach mit einer kurzen Mitteilung, wie zum Beispiel: "Bitte leg das in der Bugdatenbank ab, bei E-Mails verliere ich den Überblick." zurück.
7. Wenn Sie Tester sind, und Schwierigkeiten haben, die Programmierer zur Benutzung der Bugdatenbank zu bringen, dann erzählen Sie ihnen nichts über die Bugs, tragen Sie sie statt dessen in die Bugdatenbank ein, und lassen Sie die Datenbank die Benachrichtigungsmail verschicken.
8. Wenn Sie Programmierer sind, und nur einige Ihrer Kollegen nutzen die Datenbank, fangen Sie einfach an, ihnen Bugs über die Datenbank zuzuweisen, vielleicht bemerken sie den Hinweis.
9. Wenn Sie Manager sind, und niemand scheint die Datenbank zu benutzen, die Sie für viel Geld installiert haben, dann weisen Sie den Leuten die Entwicklung neuer Features über die Datenbank zu. Eine Bugdatenbank ist auch wunderbar dazu geeignet, neue, noch nicht implementierte Funktionen zu verwalten.
10. Lassen Sie sich nicht dazu verführen, neue Felder in die Datenbank aufzunehmen. Alle paar Monate wird jemand eine tolle Idee für ein neues Feld haben. Sie werden jede Menge cleverer Vorschläge erhalten, zum Beispiel den Namen der Datei zu speichern, in der der Bug gefunden wurde; den Anteil zu speichern, wie häufig der Bug reproduziert werden kann; zu speichern, wie oft der Fehler auftrat; zu speichern welche genauen Versionen welcher DLLs auf dem Rechner installiert waren, auf der der Fehler passierte. Es ist sehr wichtig, diesen Wünschen nicht nachzugeben. Wenn Sie es tun, dann wird Ihre Eingabemaske bald Tausende von Feldern haben, die man eingeben muss, und niemand wird mehr Lust haben Bugs einzutragen. Wenn die Bugdatenbank funktionieren soll, dann muss sie jeder benutzen, und wenn das Eintragen von Bugs zu viel "formale" Schreibarbeit wird, dann wird man die Datenbank umgehen.

Wenn Sie Code entwickeln, sogar wenn sie dies alleine tun, dann werden Sie ohne organisierte Datenbank, die alle bekannten Bugs im Programm auflistet, garantiert schlechte Software produzieren. Gute Entwicklerteams benutzen die Bugdatenbank nicht nur immer und überall, die Teammitglieder gehen sogar dazu über, sie als eigene Aufgabenliste zu verwenden. Sie verwenden die Liste der ihnen zugewiesenen Bugs als Startseite im Browser. Manche fangen sogar an sich zu wünschen, dass sie auch dem Chef der Cafeteria Bugs zuweisen könnten, damit dieser endlich die richtige Sorte Schokoriegel kauft.