Bugs sind die natürlichen Feinde der Programmierer und wollen gut erforscht sein. In größeren Projekten tauchen sie so oft auf, dass man dafür professionelle Werkzeuge braucht. Bugzilla ist ein solches Tool, das sich in freien und kommerziellen Projekten bewährt.
Software wird trotz der Erfindung von Computern immer noch von Menschen geschrieben. Viele Werkzeuge nehmen inzwischen den gebeutelten Programmierern zwar große Teile der stumpfsinnigen und fehlerträchtigen Arbeit ab, so dass sie sich mehr auf den kreativen Teil der Programmierung konzentrieren können. Die Kreativität geht dabei manchmal jedoch über das gewünschte Ziel hinaus oder versandet vorher, sodass am Ende das Programm nicht mehr genau das macht, was es gemäß Spezifikation machen sollte.
Der gemeine Nutzer bezeichnet dies Verhalten gerne als Fehler. Auf der anderen Seite sind die Benutzer selten mit dem glücklich, was sie einmal selbst spezifiziert haben oder was man ihnen vor die Füße geworfen hat, ohne sie zu fragen. So kommen neben den Fehlern auch noch Änderungswünsche (neudeutsch: Change Request oder CR) dazu.
Bei großen Projekten reichen gutes Gedächtnis, eine Wandtafel oder eine Tabellenkalkulation zur Verfolgung von Fehlern und CRs nicht aus. Zum Beispiel stehen in der Fehlerdatenbank für Mozilla inzwischen mehr als 150000 Einträge (die meisten davon allerdings im Erledigt-Status). Ein Bug-Tracking-System wie Mozilla ist dazu da, auch hier Erleichterung zu schaffen und das Melden und Bearbeiten von Fehlern zu automatisieren.
Naturgemäß ist eine solche Software komplex und reich an Features, da sie zahlreiche unterschiedliche Anwendungsfälle abdecken muss. Im Folgenden soll es also nur darum gehen, die wichtigsten Eigenschaften zu zeigen, ansonsten wäre hier mindenstes die ganze Anleitung nachzudrucken.
Ein Anwender, der einen neuen Fehler entdeckt hat, möchte diesen möglichst einfach und ohne viel Tipparbeit eingeben können. Das geschieht in zwei Schritten: Im ersten wird das Produkt ausgewählt, in dem der Fehler entdeckt wurde. Falls die Bugzilla-Instanz nur Fehler zu einem bestimmten Produkt verwaltet, entfällt dieser Schritt natürlich. Im zweiten Schritt wird der Fehler genauer beschrieben:
Das gesamte Formular ist in Abbildung 1 zu sehen. Einige Features von Bugzilla sind auf dem Formular jedoch nicht zu erkennen: In der Beschreibung kann man sich auf andere Fehler beziehen (durch den Text »bug«, gefolgt von der Nummer des Fehlers) oder auch URLs eingeben, die später automatisch in Links umgewandelt werden. An einmal erfasste Fehler lassen sich beliebige Attachments hängen, beispielsweise Testdaten für die Reproduktion des Fehlers oder auch ein Patch, mit dem sich der Fehler beheben lässt.
Abbildung 1: Das Eingabeformular für neue Fehler. Die Felder »Platform« und »OS« füllt Bugzilla automatisch aus, wenn es den verwendeten Browser erkennt.
Bei Bugzilla in der Standardkonfiguration erhalten neue Fehler den Zustand »new«. Bei einem öffentlich zugänglichen Bugzilla ist es angebracht, eingehende Fehlermeldungen zu prüfen. Dazu lässt sich noch vor »new« der Zustand »unconfirmed« für frisch hereingekommene Meldungen einbringen. Der Übergang zwischen den beiden Zuständen erfolgt auf zwei Wegen. Entweder durch einen Nutzer aus der Gruppe »Canconfirm« oder durch eine demokratische Wahl vieler Nutzer, die diesen Fehler gerne beseitigt haben wollen. Die zweite Variante kann der Admin des Systems abschalten. Sie eignet sich eher für Erweiterungswünsche als für Fehler.
Bereits im Zustand »new« ist jeder Fehler einem Entwickler zugeordnet, standardmäßig dem Komponenten-Verantwortlichen. Diese Zuordnung lässt sich beliebig oft ändern. Den nächsten Zustand - »assigned« - kann man je nach Arbeitsweise im Projekt unterschiedlich nutzen: Die erste Variante ist eine Planung von außen, bei der ein Projekt- oder Teamleiter den Fehler auf »assigned« setzt und damit einem Entwickler den Auftrag zum Beheben erteilt. Die zweite Variante entspricht eher der Arbeitsweise in Open-Source-Projekten: Der Entwickler selbst setzt den Zustand »assigned« und markiert damit, dass er mit der Arbeit beginnt. Diese Variante entspricht auch eher der Philosophie von Bugzilla, wie der Text neben der Auswahl zeigt.
Hinter dem Zustand »resolved« verbirgt sich genau genommen eine ganze Gruppe von Zuständen. Ein behobener Fehler wird als »fixed« markiert, ein nicht reproduzierbarer mit »works for me«. Stellt sich heraus, dass der Fehler doppelt erfasst wurde, setzt man ihn auf »duplicate«. In der Praxis ziehen es Anwender oder Tester leider immer wieder vor, sofort einen neuen Fehler einzutragen statt erst einmal die Liste der bereits erfassten gründlich zu durchsuchen. Gerade dazu bietet Bugzilla hervorragende Möglichkeiten.
Für einen Entwickler mag die Welt in Ordnung sein, wenn er den Fehler per »resolved« aus seinem Blickfeld verbannt hat. ("Regression Testing? Was ist das? Wenn es kompiliert, ist es gut, wenn es hochfährt, ist es perfekt" - so Linus Torvalds kurz vor der Release von Linux 2.1.94.) Ängstliche Anwender wünschen sich vorher noch eine Qualitätssicherung.</>
Open-Source-Projekte haben dafür eine große Schar Freiwilliger, die sich aus Neugier und Interesse mit Versionen vor der nächsten Stable-Release beschäftigen. Bei kommerzieller Software übernimmt meist ein Qualitätssicherungsteam diese Aufgabe. Wenn auch nach ihren Tests der Fehler nicht mehr auftritt, setzen sie den Status auf »verified«. Bei der Auslieferung der nächsten stabilen Version der Software können die Fehler abgehakt werden, dem entspricht der Zustand »closed«.
Der vorgestellte gerade Weg ist eine Idealisierung, an die sich die reale Welt nicht immer hält: Ist ein Tester mit der Arbeit des Entwicklers nicht zufrieden, kann er den Fehler wieder öffnen. Aus dem resultierenden Zustand »reopened« kann der Fehler die gleichen Wege wie aus dem Zustand »new« einschlagen.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
