Lightweight Bug Tracking

Dank Joel Spolsky weiß heutzutage die Mehrheit der Softwareentwicklungsteams, wie man Bugs verwaltet. “Painless Bug Tracking” wie Spolsky das nennt, beinhaltet das sorgsame Reporting von Bugs und die Zuweisung von Kategorien, Schweregrad, Schritte zur Reproduktion und mehr. Diese Sorgfalt verursacht aber Zeitaufwand. Was nicht im Allgemeinen schlecht ist, denn für manche Phasen in der Softwareentwicklung ist dies gut und gerechtfertigt – aber nicht für alle.

Frühe Phasen

In einer frühen Phase der Entwicklung sind Produkte tendenziell voll von Bugs, nicht implementierten Funktionen, inkonsistentem Design usw. Was man hier am dringendsten braucht, ist gutes Feedback. Macht der Workflow Sinn? Ist die UI ansprechend? Ist das Programm grundsätzlich stabil? Nicht jedes Feedback muss umgesetzt, nicht jeder Bug reproduziert werden, weil das Issue durch andere Änderungen schnell irrelevant wird.

Späte Phasen

Wenn ein Produkt oder ein neues Feature gesetzter wird, ist weniger Feedback nötig. Jetzt ist die Zeit für das “Hardening” gekommen, in der Detailfehler im Programm zu finden und zu beseitigen sind.

Maintainance

Wenn ein Produkt veröffentlicht ist und ein Bug auftritt, ist je Bug viel mehr Zeit in Reproduktion und Fehlerbehebung zu investieren als in früheren Phasen. Das macht Sinn, weil Fehler wahrscheinlich komplexer sind (sonst wären sie ja schon eher aufgefallen) und Fixes andere Programmteile evtl. beeinträchtigen können.

Wie klassisches Bug Tracking funktioniert

Die meisten Bug Tracker sehen jeden einzelnen Bug als Solitär, d.h. als Einzelobjekt. Je nach Bug Tracking System existiert eine enorme Menge an Feldern, die man ausfüllen kann/muss, um Fehler genau einzuordnen. Beispielsweise wird man das Betriebssystem oder den Browser angeben, in dem ein Fehler aufgetreten ist. Dies ist extrem wichtig, denn in einem Projekt wo Hunderte oder Tausende von Bugs auftreten, muss man diesen Massen irgendwie Herr werden.

Sehr wahrscheinlich gibt es Workflows um Bugs zu akzeptieren und zuzuweisen. Klassisches Bug Tracking denkt allerdings nicht darüber nach, wie Bugs eigentlich entdeckt worden sind. Es trennt nicht die Fehler, die von einem Tester in einem Testlauf gefunden wurden, von einem einzelnen Fehler der im Produktivbetrieb gefunden wurde.

Wie Lightweight Bug Tracking funktioniert

Lightweight Bug Tracking arbeitet auf der Ebene von Testläufen. Zunächst sollte ein Testlauf auf ein Arbeitspaket von 1-10 Personentagen ausgeführt werden. Größere und kleinere Pakete sind meiner Erfahrung nach nicht effektiv.

Im Testlauf wird ein Protokoll mit Protokolleinträgen erstellt, die den Issues in einem Bug Tracking System ähneln. Der Unterschied liegt darin, dass hier nicht so viele Details erfasst werden müssen. Ein kurzer beschreibender Text, evtl. einige Screenshots und eine Schwere-Klassifikation ist völlig ausreichend.

Somit ist die Erfassung sehr schnell und einfach realisierbar. Die Behebung aller gefundenen Fehler sollte dann durch den Entwickler passieren, der das Feature auch entwickelt hat. Die Bugs werden quasi in einem Rutsch behoben und nur die wenigen Fehler, die nicht sofort zu beheben sind, sollte man dann in einen Bug Tracker einfüllen.

Testprotokolle in Quality Spy

Die Farbkodierung repräsentiert die Schwere des Eintrages. Rot steht für einen Fehler, der behoben werden muss. Orange steht für eine Schwäche, die verbessert werden kann/sollte.

Bilder spielen eine wichtige Rolle, da die meisten Bugs über den Bildschirm sichtbar sind. Die Bilder können direkt aus der Zwischenablage eingefügt werden, das spart viel Zeit gegenüber dem Prozedere in einem Bug Tracker, wo man den Screenshot zunächst in einer Datei speichern und dann ins System hochladen muss.

Wenn ein Testlauf abgeschlossen ist, werden die Ergebnisse an den verantwortlichen Entwickler weitergegeben (z.B. direkt in der Versionsverwaltung eingecheckt), so dass dieser die Probleme fixen und den Fortschritt direkt im Testprotokoll markieren kann. Zum Fixen kann das Protokoll nach Fehler-Schwere und Status gefiltert werden, somit steht das Testprotokoll-”Dokument” einem Bug Tracker oder einer Excel Tabelle in Sachen Filterung in nichts nach.

Da stellt sich natürlich die Frage, warum dies besser als ein Bug Tracker sein soll. Es gibt nicht einmal eine Bug Statistik und was mit einem Fehlerarchiv? Meiner Meinung nach ist es aber einfach nicht besonders nützlich, Bugs dauerhaft zu archivieren, falls diese in einer frühen Phase der Entwicklung aufgetreten sind. Bugs sollten früh entdeckt und früh gefixt werden. Das war’s schon.

Einsatzfeld

Letztendlich ist Lightweight Bug Tracking gut für das Testen und Fixen während der frühen Entwicklungsphasen, also in 70% der Projektdauer geeignet. Auf der Projektzielgerade und natürlich für Maintainance ist der klassische Bug Tracking Prozess gut und erstrebenswert, so wie er von Spolsky beschrieben wird.

Es gibt eine extrem wichtige Vorbedingung für das gute Gelingen des Lightweight Bug Tracking Ansatzes. Das zu testende Feature muss von einem Entwickler umgesetzt werden, was für mich persönlich aber auch die naheliegendste Methodik ist. Es gibt aus meiner Sicht nur wenige Situationen wo z.B. mehrere Experten für sehr unterschiedliche Technologien wirklich an dem gleichen Arbeitspaket arbeiten müssen.

Die konsequente Verwendung von Lightweight Bug Tracking ist also durchaus recht einschneidend für den gesamten Entwicklungsworkflow. Richtig eingesetzt wird es aber Zeit und Geld sparen und – das ist vielleicht noch viel wichtiger – Tester und Entwickler werden sich viel produktiver fühlen, weniger nervige Arbeiten im Bug Tracking System durchführen und sich somit auf die wichtigen Sachen konzentrieren können – nämlich das Projekt und die Fehlerbehebung – und nicht die Bug Verwaltung.