Softwarequalitätssicherung ist durch zwei wesentliche Aspekte geprägt. Auf der einen Seite wird ein klar strukturierter und definierter Prozess benötigt und auf der anderen Seite müssen die entsprechenden Werkzeuge vorhanden sein, die diesen Prozess unterstützen. Neben Black und White Box, Performance, Codeabdeckungswerkzeugen usw. spielen Bug Tracking-Werkzeuge (auch bekannt unter dem Namen Defect Tracking) eine wesentliche Rolle innerhalb des Qualitätssicherungsprozesses. Doch wie hilft eine gute Bug Tracking-Software im Qualitätssicherungsprozess weiter? Unter anderem gibt sie Antworten auf die folgenden Fragen:

• Welche Fehler sind aufgetreten?
• Welche Software-Releases sind von diesen Fehlern betroffen?
• Welches Release enthält den Fix des Fehlers?
• Welcher Entwickler ist für die Fehlerbehebung zuständig?
• Was wurde unternommen, um den Fehler zu beseitigen?
• Wurde der behobene Programmfehler nachgetestet?
• Wurde der behobene Programmfehler vom Kunden freigegeben?
• Welche Trends sind feststellbar, also Statistiken zur Qualitätskontrolle?

Fehler sind in jeder Software enthalten, schließlich wird Software von Menschen erstellt und Menschen machen nun mal Fehler. Bug Tracking-Werkzeuge dienen nicht der Fehlervermeidung, sondern der schnellen, nachvollziehbaren und vor allem vollständigen Fehleridentifizierung und -behebung. In der Theorie gibt es unterschiedliche Ansätze, wie ein Bug Tracking-Werkzeug dabei vorgeht. Generell gilt, dass ein Fehler, nachdem er identifiziert wurde, verschiedene Stati erhält, bis er letztendlich behoben worden ist. Gängige Stati sind:

• Identifiziert: Ein abnormales Verhalten der Software wurde festgestellt und entsprechend in das Bug Tracking-Tool eingestellt. Diese Fehleridentifizierung kann entweder vom Kunden kommen oder von der internen Qualitätssicherung.
• Fehler: Das abnormale Verhalten wurde als Fehler, der zu beheben ist, eingestuft. (Es kann sich auch um einen Bedienfehler gehandelt haben, dann wird der Eintrag aus dem Bug Tracking-Tool wieder herausgenommen).
• Zugeordnet: Der Fehler wurde einem bestimmten Entwickler zur Behebung zugeordnet. Dieser wird davon zum Beispiel per eMail in Kenntnis gesetzt. Durch diese konkrete Zuordnung wird sichergestellt, dass der Fehler auch wirklich nur einmal behoben wird (siehe Abb. 5).
• Behoben: Der Entwickler hat den Fehler korrigiert.
• Getestet: Die Software wurde darauf getestet, ob einerseits der Fehler auch wirklich behoben wurde und andererseits durch die Behebung nicht andere Fehler aufgetreten sind.
• Freigegeben: Nach erfolgreichem Test wird die offizielle Freigabe erteilt und es erfolgt eine Mitteilung an den Kunden bzw. die betroffenen Entwickler, dass der Status geändert wurde bzw. das Produkt nun gefixt wurde und somit zum Einsatz kommen kann.

Abbildung 1 gibt ein Beispiel für einen als Workflow innerhalb eines Bug Tracking-Werkzeugs umgesetzten Prozess. Natürlich könnte man hier zusätzlich noch den ein oder anderen weiteren Status einführen, es muss jedoch berücksichtigt werden, dass dieses Prozessmodell praktikabel sein muss. Wichtig sind die Attribute, die einem Fehler mit auf den Weg gegeben werden, zum Beispiel die Schwere des Fehlers, bis wann er behoben sein muss usw. Solche Attribute sollten jedoch nicht fest vorgeschrieben sein, sondern müssen (abhängig vom Software-Entwicklungsprozess) frei definierbar sein.

Abb. 1: Beispiel für einen Workflow innerhalb eines Bug Tracking-Werkzeugs.

Statistiken
Es ist eine alte Weisheit, dass man aus Fehlern lernen kann. Als wertvolles Hilfsmittel bieten sich hier Statistiken an, welche u.a. Aussagen geben über:

• Wer liefert die meisten Fehlermeldungen?
• Wie viele Fehler sind gerade in Bearbeitung?
• Wie lange muss ein Anwender im Schnitt auf die Behebung seines gemeldeten Fehlers warten?

Ebenso ist es möglich, jede Fehlerbehebung detailliert nachzuzeichnen: Wer hat den Fehler gemeldet, wer hat ihn lokalisiert, wer hat ihn behoben? Auf Basis dieser Statistiken können Qualitätsberichte schnell und einfach generiert werden. Diese Qualitätsberichte sind sowohl für den Kunden, für den die Software entwickelt wird, als auch für die eigene Entwicklungsabteilung von großem Wert.

Die Abbildungen 2 und 3 geben hier aussagekräftige Beispiele. Abbildung 2 visualisiert die vorgenommene Zuordnung von identifizierten Fehlern. Die Grafik bringt zum Ausdruck, dass die meisten Fehler noch nicht zugeordnet worden sind. Hier liegt also ein Handlungsbedarf seitens des Leiters der Qualitätssicherung vor. In Abbildung 3 wird eine grafische Gegenüberstellung der Prioritäten vorgenommen, anhand derer die Fehler von den Entwicklern behoben werden müssen. Hier wird ersichtlich, dass die meisten Fehler dringlicher Natur sind, also nicht bis zum nächsten Zwischenrelease warten können. Sie müssen sofort behoben werden.

Abb. 2: Reportgenerierung - die Zuordnung von Fehlern wird verdeutlicht.

Abb. 3: Reportgenerierung - die Prioritäten der Fehlerbehebung werden darstellt.

Unterschiedliche Sichten
Innerhalb eines Projektes existieren unterschiedliche Sichten auf ein Bug Tracking-Tool bzw. auf die Fehlerdatenbank des Werkzeugs. Zu unterscheiden sind dabei die folgenden Rollen:

• Der Projektleiter, ihn betreffen alle in der Datenbank enthaltenen Fehlermeldungen. Um hier den Überblick zu haben, arbeitet der Projektleiter in der Regel mit frei definierbaren Filtern (zum Beispiel Auflistung aller Einträge, die in der letzten Woche neu hinzugefügt wurden).
• Der Entwicklungsleiter arbeitet ebenfalls mit Filtern. Für ihn ist es zum Beispiel interessant zu sehen, welche Einträge der letzten Woche noch nicht zugewiesen wurden, um die entsprechenden Fehlerbehebungsaufträge an seine Entwickler zu verteilen.
• Der Entwickler, für ihn sind die ihm zugeordneten Fehlerbehebungsaufträge von Bedeutung.
• Der Leiter der Qualitätssicherung interessiert sich in erster Linie für alle bereits behobenen Fehler, die nun getestet werden müssen. Auch für diese Übersicht kann mit Filtern gearbeitet werden.
• Ein Mitarbeiter aus der Qualitätssicherung, der zum Beispiel neu gefundene Fehler in die Fehlerdatenbank einträgt.

Abbildung 4 zeigt ein Beispiel, wie eine typische Fehlerdatenbank sich für den Anwender darstellt. In Form einer Liste werden alle Fehler aufgeführt. Dabei werden die jeweiligen Attribute eines Fehlers mit angegeben. Zur besseren Übersicht sind alle Fehler mit Icons versehen, die sofort erkennen lassen, um was für einen Fehler es sich handelt bzw. in welchem Status der Fehler sich befindet. Ein Häkchen bedeutet, dass der Fehler bereits abgearbeitet ist, der blaue Kreis stellt dar, dass der Fehler bereits zugeordnet wurde. Eine solche in Abbildung 4 dargestellte Fehlerliste wird je nach Projektgröße sehr schnell unübersichtlich, daher sind die oben referenzierten Filter unabdingbar.

Abb. 4: Listendarstellung einer Fehlerdatenbank.

Intelligente Fehlerbehandlung
Fehler (Bugs, Defects) in Software haben eine Eigenart: Sie sind oft unberechenbar, denn sie kommen in den unterschiedlichsten Ausprägungen vor und können untereinander Abhängigkeiten aufweisen. Hier ist eine der größten Herausforderungen für ein gutes Bug Tracking zu sehen. Dies soll anhand eines Beispiels verdeutlicht werden: Angenommen ein Qualitätssicherer findet einen Fehler und trägt diesen in die Fehlerdatenbank ein. Sein Kollege findet ebenfalls einen Fehler, der dasselbe Problem betrifft (aber nicht den gleichen Fehler darstellt) und trägt diesen ebenfalls in die Datenbank ein. Bei der späteren Zuordnung der Fehlerbehebung werden diese Fehler dann zwei unterschiedlichen Personen (Entwicklern) zugeordnet. Diese wissen dann in der Regel nicht voneinander. Um hier Verwirrungen zu vermeiden und gleichzeitig eine gewisse Struktur in die Fehlerdatenbank zu integrieren, können Fehler zusammengeführt werden (Merging). Dieses Merging bewirkt, dass die einzelnen Fehler aus der Datenbank gelöscht werden und zu einem einzelnen großen Fehler zusammengefasst werden. Ein weiterer Aspekt im intelligenten Bug Tracking ist die Duplizierung von Fehlern. Oft basieren Fehler auf denselben Grundlagen und es spart viel Zeit, wenn man hier mit Duplizierungsmechanismen arbeiten kann. Dabei ist jedoch zu beachten, dass die Duplizierung nur von erfahrenen Anwendern durchgeführt werden sollte. Ebenso hilfreich wie die Duplizierung ist das Hinzufügen ergänzender Informationen. Bewirkt zum Beispiel ein gefundener Bug eine fehlerhafte Dateiausgabe, so ist es wesentlich sinnvoller, die korrupte Datei dem Fehler als Attachment beizufügen, als wenn man versucht, hier eine textuelle Beschreibung beizufügen. Besonders wenn die Fehlermeldung vom Kunden stammt, wird häufig auf das Hilfsmittel Attachment zurückgegriffen.

Besonderheit Produktentwicklung
Bug Tracking-Werkzeuge lassen sich sowohl zur Projektentwicklung als auch zur Produktentwicklung einsetzen. Die Besonderheit der Produktentwicklung aus Sicht des Bug Trackings ist darin zu sehen, dass im Gegensatz zur Projektentwicklung hier mehrere Kunden Fehlermeldungen absetzen. Daher ist es notwendig, dass jedem Fehler auch der meldende Kunde als Attribut mitgegeben wird. Das hat den Vorteil, dass man auch eine kundenspezifische Auswertung erzeugen kann. Ferner kann man feststellen, ob ein Fehler eventuell nur bei einem bestimmten Kunden auftritt. In diesem Fall liegt der Verdacht nahe, dass es sich gar nicht um einen Fehler in der Software, sondern eventuell um einen Bedienfehler oder einen Fehler in der erweiterten Software-Ungebung des Kunden handelt.

Toolunterstützung
Auf dem Markt existieren unterschiedliche (und zwar sowohl hinsichtlich der Funktionalität als auch der Preisgestaltung) Bug Tracking-Werkzeuge. Im Kasten gibt einen Überblick, welche Anforderungen an ein gutes Bug Tracking-Werkzeug zu stellen sind. Diese sind bei der Auswahl eines geeigneten Kandidaten zu berücksichtigen, will man nicht in eine Kostenfalle laufen. Dass Bug Tracking-Werkzeuge ein unverzichtbarer Bestandteil eines professionellen Software Entwicklungsprozesses sind (insbesondere bei größeren Projekten, in denen mehrere Entwickler involviert sind), ist unumstritten. Oft stellt sich die Frage, ob es Sinn macht, auf eine Open Source-Lösung zurück zu greifen, oder ob man lieber ein kommerzielles Werkzeug zum Einsatz bringt. Im Folgenden soll eine Gegenüberstellung dieser beiden Ansätze vorgenommen werden.

Open Source-Lösungen haben den generellen Vorteil, dass weder Lizenz- noch Wartungskosten anfallen. Das heißt aber noch lange nicht, dass der Einsatz des Werkzeugs keine Kosten verursacht bzw. dass nicht andere Kosten anfallen. Der erste Knackpunkt ist die Fehlerdatenbank: So ist diese in kommerziellen Produkten meist enthalten, Open Source-Produkte setzen oft auf externen Datenbanken auf. Hier ist genau zu prüfen, welche Kosten hierdurch verursacht werden.

Ein weiterer Aspekt ist die Pflege und Weiterentwicklung des Werkzeugs. Hier ist man sicherlich bei einem kommerziellen Anbieter auf der sichereren Seite. Dies gilt besonders dann, wenn individuelle Anpassungen an dem Testprodukt vorgenommen werden müssen, die man nicht gewillt ist selber durchzuführen. In diesem Zusammenhang ist auch der Schulungsaspekt zu sehen, auch wenn Bug Tracking-Werkzeuge sehr intuitiv sind und nur ein minimaler Schulungsaufwand erforderlich ist. So ist es allemal günstiger, eine Herstellerschulung (insbesondere für die Administratoren) in Anspruch zu nehmen, als sich der zeitaufwändigen und auch fehleranfälligen Learning-by-doing-Methode auszusetzen. Ab einer gewissen Projektgröße oder auch Kritikalität des Projektes ist auf alle Fälle von Open Source-Lösungen abzuraten. So sind Feautures wie zum Beispiel die elektronische Signatur meist nur in kommerziellen Produkten enthalten.

Die in diesem Artikel dargestellten Screenshots stammen von dem Bug Tracking Werkzeug-Test TrackPro, das hierzulande von QA Systems aus Stuttgart vertrieben wird. Dieses Produkt wird bereits seit 1996 entwickelt und erfreut sich einer großen Verbreitung.

Anforderungen an Bug Tracking-Tools
Welche Anforderungen muss ein gutes Bug Tracking-Tool erfüllen?

• Jeder Nutzer muss auf einen Blick erkennen können, welche der gefundenen Fehler für ihn relevant sind. Muss er hier erst lange suchen, leidet die Akzeptanz des Werkzeugs. Ebenso wichtig ist, dass keine umfangreichen und zeitaufwändigen Angaben beim Identifizieren eines Fehlers getätigt werden müssen.
• Ein gutes Bug Tracking-Tool unterstützt mehrere Betriebssysteme, da die Entwicklung in vielen Unternehmen auf heterogenen, generisch gewachsenen Plattformen durchgeführt werden muss. Aufzuführen wären hier neben Windows insbesondere Linux, Solaris und Mac OS.
• Das Produkt muss einen auf den eigenen Entwicklungsprozess anpassbaren Workflow zur Fehlerbehebung besitzen. Diese Anpassung muss ohne größere Programmieraufwendungen vorgenommen werden können.
• Eine Integration in alle gängigen Konfigurationsmanagementwerkzeuge ist eine unverzichtbare Anforderung, will man hier nicht mit zusätzlichen Kosten konfrontiert werden.
• Nahezu alle Bug Tracking-Werkzeuge arbeiten mit einer Datenbank. Hier ist darauf zu achten, dass ein größer werdender Einsatz des Testwerkzeuges letztendlich nicht die Kosten hinsichtlich der erforderlichen Datenbanklizenzen sprengt. Im Idealfall verfügt das Produkt über eine eigene Datenbank, die durch einen ODBC-Support einen SQL-Zugriff sicherstellt.
• Das Produkt muss über eine XMI-Schnittstelle verfügen, um aus alten Fehlerdatenbanken, die zum Beispiel durch Open Source-Produkte erzeugt wurden, die nun an die Grenzen ihrer Leistungsfähigkeit geraten sind, die entsprechenden Daten zu übernehmen.
• Im Idealfall lässt sich das Bug Tracking-Tool in eine IDE wie zum Beispiel .NET integrieren.
• Gute Bug Tracking-Werkzeuge verfügen über ein automatisiertes eMail-Benachrichtigungssystem. Somit wird der zuständige Entwickler schnell und mit konkreten Inhalten informiert (vgl. Abb. 5).
• Auch ein Blick auf den Hersteller kann sich lohnen, so ist es wichtig, dass das angebotene Produkt über mehrere Jahre bereits auf dem Markt verfügbar (und im Einsatz) ist. Nur so können wertvolle Erfahrungen von Kunden Einzug in das Produkt erhalten. Der theoretische Ansatz hinter einem solchen Werkzeug ist zwar wichtig, doch letztendlich kommt die wirkliche Qualität und Anwendbarkeit durch integrierte Praxiserfahrungen der Kunden.
• Hinzu kommen Anforderungen hinsichtlich der schnellen und leichten Installierbarkeit (Out-of-the-Box) und der intuitiven Bedienbarkeit.

Abb. 5: Moderne Bug Tracking-Werkzeuge verfügen über ein konfigurierbares eMail-Benachrichtigungssystem.