"Bug-tracking" ist ein weites Thema von dem viele Aspekte im Verlauf dieses Buchs besprochen werden. Ich werden versuchen mich hier auf die Einrichtung und die technische Erwägungen zu konzentrieren. Vorher müssen wir aber mit einer Grundsätzlichen Frage anfangen: Welche Informationen genau, sollten im Bug-Tracker gehalten werden?
Der Begriff Bug-Tracker ist irreführend. Diese Systeme werden häufig auch verwendet um Anfragen für neue Funktionen, einmalige Aufgaben, unaufgeforderte Patches—im Prinzip alles zu verfolgen (engl. to track), was einen eindeutigen Anfangs- und Endzustand sowie optionale Übergangszuständen und bei denen im ihrem Lebenszyklus Informationen anfallen. Aus diesem Grund haben Bug-Tracker auch häfig Namen[32] wie Issue Tracker, Defect Tracker, Artifact Tracker, Request Trackers, Trouble Ticket System, usw. Eine Liste verfügbarer Software finden sie im Anhang Anhang B, Freie Bug-Tracker.
In diesem Buch werde ich weiterhin "Bug-Tracker" für Software benutzen, die jegliche der vorher erwähnten Angelegenheiten verfolgt, da es weithin so bezeichnet wird, ein einzelnes Element in der Datenbank des Bug-Tracker werde ich jedoch als Ticket (im engl. auch "issue") bezeichnen. So können wir zwischen Verhalten oder Fehlverhalten unterscheiden, die ein Nutzer beobachtet hat, (also einen Fehler) und die Erfassung seiner Entdeckung, Diagnose und Lösung im Tracker. Behalten Sie im Hinterkopf, dass auch wenn es bei den meisten Tickets um Fehler handelt, sie auch benutzt werden können um andere Aufgaben zu verfolgen.
Der klassische Verlauf eines Tickets sieht wie folgt aus:
Jemand reicht den Ticket ein. Sie machen eine Zusammenfassung, eine anfängliche Beschreibung (einschließlich wie man den Fehler reproduziert, falls anwendbar, siehe „Behandeln Sie Jeden Nutzer, Wie Einen Möglichen Freiwilligen“ im Kapitel Kapitel 8, Leitung von Freiwilligen in der beschrieben wird, wie man gute Bug Meldungen fördert ermutigen kann), und sonstige Informationen die der Tracker verlangt. Die Person die den Fehler meldet, kann dem Projekt völlig unbekannt sein—Bug Meldungen und Anfragen für Funktion können genau so aus der Nutzer-Gemeinschaft kommen, wie von den Entwicklern.
Sobald der Ticket gemeldet wurde sagt man, dass er offenen ist. Da bisher nichts unternommen wurde, kennzeichnen manche Tracker diese auch als unbestätig (engl. "unverified") oder nicht angefangen (engl. "unstarted"). Er wurde noch niemandem Zugewiesen; oder, in manchen Systemen, wird es einem fiktiven Benutzer zugewiesen um anzudeuten, dass es nicht wirklich jemandem zugewiesen wurde. Zu diesem Zeitpunkt steht es in einer Warteschlange: Der Ticket wurde erfasst, jedoch nicht im Bewusstsein des Projekts aufgenommen.
Andere lesen den Ticket, sie fügen Kommentare hinzu, und bitten vielleicht dem Meldenden einige Punkte zu klären.
Der Fehler wird reproduziert. Dieser Augenblick mag der Wichtigste in seinem Lebenszyklus sein. Auch wenn der Bug noch nicht behoben wurde ist die Tatsache, dass jemand außer dem der ihn gemeldet hat, es geschafft hat selber den Fehler zu finden beweist, dass er echt ist und, nicht zuletzt, dem Berichtenden bestätigt hat, dass sie durch die Meldung eines echten Fehlers etwas zum Projekt beigetragen haben.
Der Fehler wird untersucht: seine Ursache wird identifiziert und wenn möglich, wird der nötig Aufwand geschätzt um ihn zu beheben. Stellen Sie sicher, dass diese Sachen in dem Ticket erfasst werden; wenn die Person die den Bug untersucht hat, plötzlich eine längere Zeit vom Projekt wegtreten muss (was bei freiwilligen Entwicklern häufig passieren kann), sollte jemand anders in der Lage sein, seine Arbeit wieder aufzunehmen.
In dieser Phase oder manchmal schon vorher, kann ein Entwickler den Ticket in Besitz nehmen, und ihn sich selber zuweisen (In „Unterscheiden Sie Eindeutig Zwischen Anfrage und Anweisung“ im Kapitel Kapitel 8, Leitung von Freiwilligen wird der diese Zuweisung genauer untersucht. Die Priorität kann in dieser Phase auch bestimmt werden. Wenn er z.B. derart schwerwiegend ist, dass er die nächste Version verzögern würde, muss diese Tatsache frühzeitig erkannt werden und der Tracker sollte eine Möglichkeit bieten das zu erfassen.
Es wird geplant wann der Ticket aufgelöst werden soll, wobei dabei nicht unbedingt ein bestimmtes Datum gemeint ist an dem er behoben sein soll. Manchmal bedeutet es einfach eine Entscheiden bis zu welcher Version (nicht unbedingt die Nächste) der Bug behoben sein soll, oder dass er keine bestimmte Version blockieren muss. Wenn der Bug schnell behoben werden kann, ist die Planung wahrscheinlich überflüssig.
Der Bug wird behoben (oder die Aufgabe wird erledigt, oder der Patch angewandt, oder was auch immer). Die Änderung die ihn beheben sollten in einem Kommentar des Tickets protokolliert werden, worauf er geschlossen wird und/oder als gelöst markiert wird.
Dieser Lebenszyklus variiert häufig. Manchmal wird ein Ticket frühzeitig nach seiner Meldung geschlossen, da sich herausstellt, dass es sich nicht um einen Fehler handelt, sondern um ein Missverständnis seitens des Anwenders. Sowie ein Projekt immer mehr Benutzer aufnimmt, werden immer mehr dieser ungültigen Tickets aufkommen und Entwickler werden sie mit zunehmend gereizt schließen. Versuchen Sie der letzteren Neigung entgegenzuwirken. Sie hilft keinem, da der einzelne Nutzer in jedem Einzelfall nicht für alle vorhergehenden ungültigen Tickets verantwortlich ist; die statistische Zunahmen ist lediglich für die Entwickler sichtbar nicht für die Nutzer. (In „Ticket Filterung“ später in diesem Kapitel, werden wir die Methoden untersuchen, um die Anzahl der ungültigen Tickets zu verringern). Wenn verschiedene Nutzer immer wieder dasselbe Missverständnis haben, kann das ein Hinweis sein, dass ein bestimmter Bereich der Software überdacht werden muss. Diese Muster können am einfachsten von einem Ticket-Verwalter bemerkt werden, der die Bug-Datenbank überwacht; siehe „Ticket Verwalter“ im Kapitel Kapitel 8, Leitung von Freiwilligen.
Eine weitere häufige Abweichung zu diesem Lebenszyklus ist, dass der Ticket als Duplikat gleich nach dem ersten Schritt geschlossen wird. Ein Duplikat erscheint wenn jemand ein Ticket meldet der dem Projekt bereits bekannt ist. Duplikate beschränken sich nicht auf offene Tickets: Es ist auch möglich, dass ein Bug wiederkehrt, nachdem er behoben wurde (auch als Regression bekannt). In solchen Fällen öffnet man Vorzugsweise wieder den ursprünglichen Ticket und alle neuen Meldungen werden als Duplikate des Originals geschlossen. Der Bug-Tracker sollte diese Beziehung in beiden Richtungen verfolgen können, um Informationen wie man ihn Reproduziert dem ursprünglichen Ticket verfügbar zu machen und umgekehrt.
Eine dritte Variante ist, dass Entwickler einen Ticket schließen, in der Annahme, der Fehler wurde bereits behoben, was der Meldendende allerdings abgewiest und ihn erneut öffnet. Meistens geschieht das, wenn die Entwickler nicht die nötige Umgebung haben, um den Fehler zu reproduzieren oder da nicht mit genau dieselbe Anleitung zur Reproduktion beim testen genutzt haben wie der Meldende.
Abgesehen von diesen Abweichungen, kann es andere kleine Details im Lebenszyklus geben, die sich abhängig von der Software des Bug-Trackers unterscheiden. Die grundsätzliche Form ist jedoch bei allen die gleiche, und obwohl der Lebenszyklus nicht eigen zu Open-Source Software ist, hat es Auswirkungen darauf wie Open-Source Projekte ihre Bug-Tracker benutzen.
Wie der erste Schritt andeutet, bietet ein Bug-Tracker der Öffentlichkeit genau so sehr ein Bild des Projekts wie seine E-Mail Verteiler oder seine Webseite. Jeder kann Ticket aufmachen, jeder kann sich ein Ticket anschauen und jeder kann die Liste der offenen Tickets anschauen. Daraus folgt, dass Sie niemals wissen können wieviele Leute darauf warten, Fortschritte für bei einem bestimmten Ticket zu sehen. Auch wenn die Größe und Erfahrung der Entwicklergemeinschaft die Geschwindigkeit einschränken kann, mit der Tickets Issues gelöst werden, sollte das Projekt zumindest versuchen jeden Ticket, gleich nach seiner Meldung zu bestätigen. Selbst wenn er eine weile lang liegen bleibt, ermutigt eine Reaktion dem Meldenden sich weiterhin an seiner Lösung zu beteiligen, da sie das Gefühl bekommt, dass ein Mensch sich ihrer Mühe bewust ist (bedenken Sie, dass eine Ticket aufzumachen für gewöhnlich einen größeren Aufwand bedeutet, als sagen wir eine E-Mail zu schreiben). Desweiteren tritt der Ticket, sobald es von einem Entwickler bemerkt wird, in das Bewusstsein des Projekts, womit gemeint ist, dass dieser Entwickler darauf achten kann, ob der Ticket an anderer Stelle irgendwo auftaucht, mit anderen Entwicklern darüber reden kann, usw.
Das eine zeitige Reaktionen unabdingbar ist, impliziert zweierlei:
Der Tracker muss mit einem E-Mail Verteiler verbunden sein, damit jede Änderung an einem Ticket, inklusive seine erste Meldung, eine E-Mail erzeugt die beschreibt was passiert ist. Dieser Verteiler ist normalerweise ein anderer als der gewöhnliche Entwickler Verteiler, da nicht alle Entwickler automatisierte Bug E-Mails empfangen wollen, der Reply-to Header sollte aber (genau wie bei Commit E-Mails) auf den Entwicklunger Verteiler weisen.
Das Formular um Tickets zu melden, sollte die E-Mail Adresse des Meldenden erfassen, damit sie für weitere Informationen erreicht werden kann. (Die E-Mail Adresse sollte jedoch nicht erforderlich sein, da manche Leute es vorziehen anonym Fehler zu melden. Siehe „Anonymität und Beteiligung“ später in diesem Kapitel indem die Wichtigkeit der Anonymität behandelt wird.)
Sorgen Sie dafür, dass der Bug-Tracker nicht zu einem Diskussionsforum wird. Obwohl menschliche Anwesenheit auf dem Bug-Tracker wichtig ist, eignet er sich nicht grundsätzlich für Diskussionen. Betrachten Sie es eher als ein Archiv, eine Möglichkeit Tatsachen und Verweise auf andere Diskussionen zu organisieren, die hauptsächlich auf Verteiler stattfinden.
Es gibt Zwei Gründe diese Unterscheidung zu machen. Erstens ist die Bedienung des Bug-Trackers umständlicher als ein E-Mail Verteiler (oder wenn wir dabei sind IRC oder andere Echtzeit Foren). Das liegt nicht an der schlechten Benutzeroberflöche im Bug-Tracker, sondern an seine Ausrichtung auf die Erfassung und Darstellung getrennter Zustände und nicht auf offene Diskussionen. Zweitens beobachtet nicht jeder den Bug-Tracker der auch an der Diskussion eines Tickets beteiligt sein sollte. Ein Teil guter Ticker Verwaltung (siehe „Teilen Sie Sowohl Verwaltungsaufgaben Als Auch Technische Aufgaben“ im Kapitel Kapitel 8, Leitung von Freiwilligen) besteht darin sicherzustellen, dass jeder Ticket eher die Aufmerksamkeit der richtigen Leute bekommt, als dass jeder Entwickler über jeden Ticket beischeid wissen muss. In „Keine Unterhaltungen auf dem Bug Tracker“ im Kapitel Kapitel 6, Kommunikation, werden wir Wege untersuchen, Leute daran zu hindern versehentlich Diskussionen von ihren angemessenen Foren auf den Bug-Tracker auszulagern.
Manch Bug-Tracker können E-Mail Verteiler überwachen und automatisch alle E-Mails protokollieren, die sich um einen bekannten Ticket drehen. Typischerweise erkennen sie das anhand der Identifikationsnummer des Tickets in der Betreffzeile der E-Mail, als Teil einer bestimmten Zeichenfolge; Entwickler lernen diese Zeichenfolgen in ihrer E-Mails zu benutzen, um die Aufmerksamkeit des Bug-Trackers anzulocken. Der Tracker kann entweder die E-Mail als ganzes speichern oder (besser noch) einen Link zu dem Archiv des Verteilers. So oder so ist diese Funktion sehr nützlich; wenn Ihr Tracker sie hat, sollten Sie sie unbedingt einschalten und Teilnehmer erinnern sie zu nutzen.
Die meiste Ticket Datenbanken leiden irgendwann an dem gleichen Problem: Eine erstickende Anzahl doppelter oder ungültiger Tickets die mit guter Absicht aber von unerfahrenen oder schlecht informierten Nutzern gemeldet werden. Der erste Schritt dieser Entwicklung entgegenzuwirken ist gewöhnlicherweise, einen prominenten Hinweis auf der Hauptseite des Trackers anzubringen, die erklärt woran man erkennen kann ob ein Bug wirklich ein Bug ist, wie man nach bereits gemeldete Fehler suchen kann und letztendlich wie man eine effektive Meldung machen kann, wenn man immer noch der Meinung ist, dass es ein neuer Bug ist.
Der Geräuschpegel sollte danach eine Weile reduziert sein, sowie die Anzahl der Nutzer zunimmt, wird das Problem jedoch wiederkehren. Kein einzelner Nutzer ist daran Schuld. Jeder versucht nur zum Wohl des Projekts beizutragen und auch wenn ihre erste Meldung nicht hilfreich ist, sollten Sie dennoch dazu ermutigen sich weiterhin zu beteiligen und zukünftig bessere Tickets zu schreiben. In der Zwischenzeit muss das Projekt die Ticket-Datenbank so frei von Müll halten wie möglich.
Die zwei größten Abhilfen sind: Sicherzustellen, dass Leute den Bug-Tracker beobachten, die genügend wissen um ungültige oder doppelte Tickets gleich nach ihrer Meldung zu schließen und von Nutzern erfordern (oder nachdrücklich dazu anregen) ihre Bugs von andere bestätigen zu lassen vor sie eine Meldung im Tracker eintragen.
Die erste Methode scheint universelle Anwendung zu finden. Selbst Projekte mit riesigen Ticket Datenbanken (wie der Debian Bug-Tracker bei http://bugs.debian.org/, mit 315,929 Tickets zum Zeitpunkt dieses Schreibens hatte) organisieren sich so, dass irgendjemand jeden eintreffenden Ticket sieht. Es können verschiedene Personen sein, abhängig von der Kategorie des Tickets. Das Debian Projekt ist z.B. eine Sammlung verschiedener Software Pakete, also leitet Debian automatisch jeden Ticket an die entsprechend Zuständigen für das Packet. Natürlich, kann es manchmal vorkommen, dass Nutzer ein Ticket falsch einordnen mit dem Ergebnis, dass der Ticket zunächst an die falsche Person geleitet wird die ihn dann möglicherweise wieder umleiten muss. Wichtige dabei ist, dass diese Last trotzdem verteilt wird—ob der Nutzer beim Ausfüllen des Formulars richtig oder falsch rät, die Beobachtung der Tickets sollte dennoch mehr oder weniger gleichmäßig auf die Entwickler aufgeteilt sein, damit jedes Ticket eine zeitige Antwort erhalten kann.
Die zweite Technik ist weniger verbreitet, wahrscheinlich, da sie sich schwerer automatisieren lässt. Der Grundgedanke ist jeden Ticket einen "Buddy" zuzuordnen. Wenn ein Nutzer denkt er, hat ein Problem gefunden, wird er darum gebeten es auf einem der E-Mail Verteiler oder im IRC zu beschreiben und sich von jemandem bestätigen zu lassen, dass es sich auch wirklich um einen Bug handelt. Ein zweites Augenpaar frühzeitig einzubeziehen, kann viele störende Meldungen verhindern. Manchmal kann die zweite Partei erkennen, dass das Verhalten kein Fehler ist, oder dass er in einer neuern Version behoben wurde. Sie kann auch mit den Symptomen aus einem früheren Ticket vertraut sein und einen doppelten Eintrag verhindern, indem sie den Nutzer auf das ältere Ticket Issue hinweist. Oftmals reicht es auch den Nutzer zu fragen, "Hast du im Bug-Tracker geschaut ob er bereits gemeldet wurde?" Viele denken einfach nicht daran, haben jedoch kein Problem es zu tun wenn sie wissen, dass jemand es von ihnen erwartet.
Das Buddy-System kann die Ticket-Datenbank wirklich sauber halten, hat aber auch einige Nachteile. Viele machen trotzdem alleine Meldungen, weil sie entweder die Anweisungen sich für neue Tickets einen Buddy zu suchen entweder nicht sehen oder ignorieren. Von daher ist es immer noch nötig die Ticket-Datenbank von freiwilligen überwachen zu lassen. Desweiteren ist es nicht gerechtfertigt sie für ihre Ignoranz gegenüber den Richtlinien allzusehr zurechtzuweisen, da die meisten die ihre erste Meldung machen, nicht verstehen wie schwer es ist, die Ticket-Datenbank in Stand zu halten. Die Freiwilligen müssen deshalb wachsam sein und dennoch Zurückhaltung üben wenn sie Tickets ohne einen Buddy wieder an seinen Author zurückweisen. Das Ziel ist jeden beizubringen, dass sie zukünftig das Buddy System verwenden sollen, um eine wachsende Gemeinschaft entstehen zu lassen, die das Filter-System für die Tickets verstehen. Bei der Sichtung eines Tickets ohne einen Buddy sind die optimalen Schritte:
Antworten Sie sofort auf das Ticket, bedanken Sie den Nutzer für die Meldung weise sie dabei aber auf die Buddy Richtlinien(die natürlich auf der Webseite herausragen sollten).
Wenn dat Ticket ansonsten nicht eindeutig berechtigt ist, schließen Sie es, bitten Sie dem Author aber darum, ihn wieder aufzumachen, sollte es von einem Buddy bestätigt werden. Danach sollten Sie einen Verweis auf den Thread mit der Bestätigung geben (z.B. eine URL aus dem Archiv des Verteilers).
Denken Sie daran, dass obwohl dieses System, mit der Zeit das Signal/Rausch Verhältnis in der Ticket-Datenbank verbessern wird, es niemals alle Falschmeldungen unterbinden kann. Der einzige Weg Falschmeldungen komplett zu verhindern, ist den Bug-Tracker komplett, für alle außer die Entwickler abzuschalten—eine Medizin die meistens schlimmer ist als die Krankheit. Es ist besser sich damit abzufinden, dass die Entfernung ungültiger Tickets immer ein Teil der üblichen Wartungsarbeiten am Projekt bleiben wird und so viele Leute wie möglich zu überreden dazu dabei zu helfen.
Siehe auch „Ticket Verwalter“ im Kapitel Kapitel 8, Leitung von Freiwilligen.