"Bugtracking" ist ein weites Thema von dem viele Aspekte im Verlauf dieses Buchs besprochen werden. Ich werde versuchen, mich hier auf die Einrichtung und die technischen Erwägungen zu konzentrieren. Vorher müssen wir aber mit einer grundsätzlichen Frage anfangen: Welche Informationen genau sollten im Bugtracker gehalten werden?
Der Begriff Bugtracker 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 hat und dessen Lebenszyklus Informationen anfallen. Aus diesem Grund haben Bugtracker auch häfig Namen[31] wie Issue Tracker, Defect Tracker, Artifact Tracker, Request Tracker, Trouble Ticket System, usw. Eine Liste verfügbarer Software finden Sie im Anhang Anhang B, Freie Bugtracker.
In diesem Buch werde ich weiterhin "Bugtracker" 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 Bugtracker 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 das Ticket ein. Sie machen eine Zusammenfassung, eine anfängliche Beschreibung (einschließlich dessen 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: Das 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 „Ticketverwalter“ 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 Bugtracker 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 Bugtrackers 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 Bugtracker benutzen.
Wie der erste Schritt andeutet, bietet ein Bugtracker der Öffentlichkeit genau so sehr ein Bild des Projekts wie seine Mailinglisten oder seine Webseite. Jeder kann ein 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 ein bestimmtes Ticket zu sehen. Auch wenn die Größe und Erfahrung der Entwicklergemeinschaft die Geschwindigkeit einschränken kann, mit der Tickets abgearbeitet werden, sollte das Projekt zumindest versuchen, jedes Ticket gleich nach seiner Meldung zu bestätigen. Selbst wenn er eine Weile lang liegen bleibt, ermutigt eine Reaktion dem Melder gegenüber, sich weiterhin an seiner Lösung zu beteiligen, da er das Gefühl bekommt, dass ein Mensch sich seiner Mühe bewust ist (bedenken Sie, dass ein Ticket aufzumachen für gewöhnlich einen größeren Aufwand bedeutet, als sagen wir eine E-Mail zu schreiben). Desweiteren tritt das Ticket, sobald es von einem Entwickler bemerkt wird, in das Bewusstsein des Projekts, womit gemeint ist, dass dieser Entwickler darauf achten kann, ob das 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 einer Mailingliste verbunden sein, damit jede Änderung an einem Ticket, inklusive seine erste Meldung, eine E-Mail erzeugt die beschreibt was passiert ist. Diese Liste ist normalerweise ein anderer als der gewöhnliche Entwickler-Liste, da nicht alle Entwickler automatisierte Bug-Mails empfangen wollen, der Reply-to-Header sollte aber (genau wie bei Commit-Mails) auf die Entwicklunger-Liste 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 Bugtracker nicht zu einem Diskussionsforum wird. Obwohl menschliche Anwesenheit auf dem Bugtracker 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 Listen stattfinden.
Es gibt Zwei Gründe diese Unterscheidung zu machen. Erstens ist die Bedienung des Bugtrackers umständlicher als die einer Mailingliste (oder, wo wir gerade dabei sind, IRC oder andere Echtzeit-Foren). Das liegt nicht an der schlechten Benutzeroberflöche im Bugtracker, sondern an seine Ausrichtung auf die Erfassung und Darstellung getrennter Zustände und nicht auf offene Diskussionen. Zweitens beobachtet nicht jeder den Bugtracker 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 im Bugtracker“ im Kapitel Kapitel 6, Kommunikation, werden wir Wege untersuchen, Leute daran zu hindern versehentlich Diskussionen von ihren angemessenen Foren auf den Bugtracker auszulagern.
Manch Bugtracker können Mailinglisten ü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 Bugtrackers anzulocken. Der Tracker kann entweder die E-Mail als ganzes speichern oder (besser noch) einen Link zu dem Archiv der Liste. 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 meisten 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 Bugtracker 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-Bugtracker 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 einer der Mailinglisten 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 hinweist. Oftmals reicht es auch den Nutzer zu fragen, "Hast du im Bugtracker 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 Autor 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 Autor 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 der Mailingliste).
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 Bugtracker 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 dazu zu überreden, dabei zu helfen.
Siehe auch „Ticketverwalter“ im Kapitel Kapitel 8, Leitung von Freiwilligen.