Ein gut dosierter Test

Klar dosiertAls der Holländer Edsger W. Dijkstra im Jahr 1957 in Amsterdam das Aufgebot für seine Hochzeit bestellte, gab er als Beruf „Programmierer“ an. Allerdings wiesen die Behörden das Aufgebot zurück, mit der Begründung es gäbe keinen derartigen Beruf. Schließlich durfte Dijkstra, der Mathematik und Physik studiert hatte, nach Änderung der Berufsangabe in „theoretischer Physiker“ doch noch heiraten. Später veröffentlichte er eine Vielzahl von Fachartikeln und Büchern zum Themenbereich der strukturierten Programmierung sowie des Software Engineerings und lehrte an der Technische Universiteit in Eindhoven sowie an der University of Texas in Austin.

Im Jahre 1972 erhielt Dijkstra das ACM A.M. Turing Award für seine Arbeiten bei der Entwicklung von Programmiersprachen. Im Rahmen der feierlichen Übergabe des Preises hielt er eine Vorlesung mit dem Titel „The humble programmer“, nachzulesen im Archiv der University of Texas. Diese Vorlesung beinhaltete die für das Softwaretesten zentrale Aussage: “Program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence.

Das Dilemma des Testers

Die Dijkstra’sche Erkenntnis gilt bis heute: Mit Testen lässt sich nicht die Fehlerfreiheit einer Software nachweisen. Auch wenn eine Software sehr lange getestet wird, ohne einen weiteren Fehler zu finden, kann man daraus nicht ableiten, dass sie fehlerfrei ist. Nun steht der Tester vor einem Dilemma: Wie lange soll getestet werden? Wann kann man guten Gewissens das Testen beenden? Bei „zu wenig Test“ besteht die Gefahr, dass Fehler vor der Auslieferung einer Lösung nicht gefunden werden und erst im späteren Wirkbetrieb auffallen. Bei „zu viel Test“ werden unnötig Ressourcen gebunden, Geld verbrannt, und die Lösung kommt außerdem noch zu spät auf den Markt.

Das richtige Kriterium

Das Schlagwort in diesem Kontext lautet „Testendekriterium“, d.h. der Test ist abgeschlossen, wenn dieses Kriterium (i.d.R. handelt es sich um multiple Kriterien) erfüllt ist.

Häufig besteht das Testendekriterium einfach darin, dass ein lange vorher definierter Ausliefertermin für die Lösung naht oder schlichtweg das für den Test allokierte Budget aufgebraucht ist. Solche Kriterien sind an der Tagesordnung und machen (auch wenn mancher Tester damit nicht glücklich sein mag) in der betriebswirtschaftlichen Betrachtung durchaus Sinn. Dies gilt insbesondere dann, wenn „Time to Market“ für eine Lösung einen hohen Stellenwert hat und/oder das Risiko latenter Fehler tragbar ist.

Andere Testendekriterien basieren eher auf Metriken, KPIs und statistischen Verfahren wie

  • Anzahl erfolgreich durchgeführter Testcases
  • Anzahl gefundener / behobener / noch offener Fehler, inkl. Zuordnung zu einer Fehlerkritikalität
  • Erreichte Testabdeckung des Codes
  • Fehlerfindungsrate im Testprozess über die Zeit
  • ….

Wichtig: Testendekriterien sollten zu Projektbeginn fixiert und nur bei Vorliegen stichhaltiger Gründe verändert werden.

Optimierungsanätze

Allerdings startet in vielen Projekten die Erhebung der Metriken, die für eine Entscheidung über das Testende herangezogen werden, erst in späteren Testphasen, häufig erst mit dem Systemtest. Mit der konsequenten Erfassung gefundener bzw. behobener Fehler kann jedoch schon deutlich früher begonnen werden, beispielsweise schon im Unittest, auch wenn dieser durch die Entwickler und ggf. noch ohne Beteiligung eines Testers ausgeführt wird. Ein solches Vorgehen erfordert Disziplin von Anfang an, kann aber andererseits die Transparenz bezüglich der Qualität einer Softwareproduktion deutlich steigern.

Darüber hinaus bietet es sich an, nicht nur die Zahl der aufgedeckten Fehler festzuhalten, sondern zu jedem Fehler im Rahmen eines „Fehlerreviews“ auch zu ermitteln, in welcher Phase und weshalb dieser entstanden ist und wie hoch der Aufwand zu seiner Beseitigung war. Hier wird nun ein Aufschrei des “humble programmers“ ertönen, der in einem solchen Vorgehen lediglich wieder ein „Fingerpointing“ in seine Richtung befürchtet. Das ist aber überhaupt nicht die Intention. Und die teuersten Fehler haben – soweit sie nicht früh genug aufgedeckt werden – ihre Ursache in falschen oder unvollständigen Requirements.

Wie also schon Dijkstra in frühen Tagen der Softwareentwicklung formulierte…Testen ist ein sehr effizienter Weg Fehler aufzuzeigen. Gerne unterstützen wir Sie dabei, passende Kriterien und Metriken zu finden, um das Testen gut zu dosieren.

 

Photo by Jesus Kiteque on Unsplash

Leave a Reply

Your email address will not be published.