Wer Software entwickelt verbringt viel Zeit und Energie mit Jagd auf Fehler im Code. Die Systematisierung dieser Käferjagd spart Zeit und Nerven.

Von Eric Fischer, Syndc.

Startwerk.ch Startup-Diary.

In der Rubrik Startup-Diary schildern Jungunternehmer wöchentlich, mit welchen praktischen Problemen sie in der vergangenen Woche konfrontiert wurden und welche Lösungsansätze sie gefunden haben.
 Während der Entwicklung einer komplexen Anwendung wie Syndc.com treten immer wieder Probleme und Bugs auf. Daher sind Bugtracking und -fixing zentrale Tätigkeiten des Entwicklungsteams. Um Bugs systematisch zu begegnen und zu beheben, benötigen wir ein System, mit dem sich die Bugs tracken und und deren Ursachen und Behebung dokumentieren lassen. Für uns gab es dabei mehrere Elemente, die ein Bugtracking-System erfüllen muss: Erstens muss es für alle Nutzer des Bugtrackings geeignet sein, d.h. zum einen muss es die Bedürfnisse des Entwicklers/Testers erfüllen und zum anderen die eines Anwenders. Insbesondere der erste Punkt hat seit der Erweiterung unseres Entwicklungsteams auf nun fünf Personen an Bedeutung gewonnen, da sich die Mitglieder des Teams nicht jederzeit am gleichen Ort befinden und dennoch jederzeit auf dem aktuellen Stand der Bearbeitung durch die anderen Teammitglieder sein müssen. Ausserdem sollte das System natürlich möglichst schlank und einfach zu bedienen sein und so gut wie keine Einarbeitungszeit benötigen.

Google Apps als Lösung – vorläufig

Als erstes haben wir uns Bugzilla (Wikipedia-Eintrag) angeschaut. Wir kamen jedoch zum Schluss, dass dieses Tool uns im Moment zu viele Möglichkeiten bietet, dass Pflege und Anwendung mehr Zeit in Anspruch nehmen würden als es uns Nutzen bringt.

Schliesslich haben wir in unsere Anwendung einen „Button“ integriert (Report Bug), den der User klicken kann, um einen Datenbankeintrag über den Ort des Fehlers (url) zu erzeugen. Auf Ebene der Entwickler und Tester haben wir zuerst mit einem Bereich in unserem Dokuwiki gearbeitet, in dem wir Bugs detailliert (Ort, Funktion, Fehler, zusätzliche Info, Datum und Name) beschrieben haben. Dies wurde allerdings schnell unübersichtlich und wir sind jetzt dazu übergegangen, die Bugs in Google Spreadsheets (Wikipedia-Eintrag) zu erfassen und werden beobachten, ob sich das bewährt.

Fazit: Bei jeder Einführung eines neuen Tools stellen Einarbeitung und Umstellung eine nicht zu unterschätzende Hürde dar. Entweder gibt man ein Tool zwingend vor oder man verwendet eine Variante, die vielleicht weniger Funktionen besitzt, dafür selbsterklärend ist – Wir haben uns vorderhand für Einfachheit entschieden.