Software-Entwicklung und die Fehler-Datenbank

Durch | 20. Dezember 2007

Zur Erinnerung hier die 10 Regeln zur Software-Entwicklung.

Heute soll es um ein heikles Thema gehen: Die Fehlerdatenbank. Schon der Begriff impliziert widersprüchliches. In einer Datenbank werden normalerweise Daten gespeichert, die im positiven Sinne verwendet werden sollen. Ein Fehler hingegen hört sich alles andere als positiv an und wer will schon an seine Fehler erinnert werden. Genau das leistet aber eine Fehlerdatenbank – oder auf Neudeutsch ein Bugtracking-System – sie erinnert uns an die Fehler in der Software. Sie ist damit ein Mittel gegen die natürliche Vergesslichkeit der Programmierer ;).

Das allein würde den Einsatz einer Fehlerdatenbank schon rechtfertigen, es lohnt sich aber noch weitere Fragen zu stellen.

Was ist eigentlich ein Fehler? Ganz allgemein gefasst ist es ein unerwartetes Verhalten der Software. Der Anwender löst eine Aktion aus und die Software verhält sich anders als erwartet. Das Ergebnis kann vom schwarzen bzw. blauen Bildschirm des Totalabsturzes bis zur Nichtigkeit eines Tippfehlers in einer Systemmeldung reichen. Solche Extrem-Fälle lassen sich mit einer kurzen Beschreibung der Benutzeraktion und des Systemverhaltens gut beschreiben. Schwieriger wird es, wenn die Erwartungshaltung an die Software nicht ganz klar ist. Das führt uns zu der Frage „Bug oder Feature?“. Ein Beispiel: Der Anwender markiert in einer Tabellenkalkulation mehrere Zellen um sie zu verbinden. Dabei werden die Inhalte der ursprünglichen Zellen gelöscht: Das ist ein Fehler. Oder doch nicht? Wie soll es denn richtig funktionieren? Soll automatisch der Inhalt der ersten Zelle übernommen werden, oder der Inhalt der letzten, soll die Software nachfragen welche Zelle genommen wird oder soll ein Mittelwert berechnet werden falls es sich um numerische Werte handelt.

Wenn ein vermeintlicher Fehler gefunden wird, sollte die Fehlerbeschreibung daher zwingend folgendes enthalten:

  • Was muss der Anwender tun um den „Fehler“ zu erhalten?
  • Wie verhält sich das System im Fehlerfall?
  • Wie soll sich das System „richtig“ verhalten?

Interessanterweise kommt es recht häufig vor, dass unterschiedliche Anwender den gleichen Fehler entdecken aber unterschiedliche „Soll-Vehalten“ formulieren. Das heißt eine Fehlerdatenbank ist nicht nur ein Mittel gegen das Vergessen sondern spürt auch Unstimmigkeiten in der Spezifikation auf. Wenn die Sollbeschreibung eindeutig ist, hilft sie unmittelbar dem Programmier, der dann weiß was er zu tun hat.

Neben den genannten Punkten sollte eine Fehlerbeschreibung noch weitere Daten enthalten:

  • Wie schwer wiegt der Fehler?
  • Wer ist für den Fehler zuständig?

Der Schweregrad des Fehlers ist unverzichtbar für eine Festlegung der Reihenfolge der Fehlerbehebung – das ist einsichtig. Schwieriger wird es beim letzten Punkt, der den oben schon angedeuteten heiklen Punkt darstellt. Arbeitet ein Team an der Software, ist die Frage „Wer ist zuständig?“ ganz eng verwandt mit der Frage „Wer hat den Fehler gemacht?“.

Wie kann ggf. verhindert werden, dass die Zuständigkeit für Fehler nicht zum Argument von Auseinandersetzungen verkommt? Bei schwerwiegenden Fehlern sollten daher Zuständigkeiten und Lösungsoptionen so offen wie möglich verhandelt werden. Schwerwiegende Fehler treten selten isoliert auf, die Abhängigkeiten von Fehlern sollten zudem analysiert und dokumentiert werden. Damit entsteht ein Netzwerk von Zuständigkeiten in dem das „Schwarze-Peter-Fehler-Spiel“ verhindert wird. Manch echter Fehler hat auch eine Abhängigkeit zu einer Spezifikationslücke, damit können die Zuständigkeiten auch zwischen Auftraggeber und Auftragnehmer verteit werden.

Dieses Netz an Zuständigkeiten kann letztendlich nur von der Projektleitung überblickt und verwaltet werden. Da Fehler ganz nebenbei auch den Kunden verärgern 😉 bleibt nur das Fazit zu ziehen:

Fehler sind keine Neben- sondern Chefsache!

Ein Gedanke zu “Software-Entwicklung und die Fehler-Datenbank

  1. Pingback: p r o j e k t e » Blog Archiv » 10 Regeln für gute Software(projekte)

Kommentarfunktion ist geschlossen.