Wohin mit den Testfällen?

Oct 22
2009

Am Ende jedes Testzyklus stellt sich die entscheidende Frage: Ist das Produkt in Ordnung?

Diese Frage kommt manchmal auch mit einem entsprechend vorwurfsvollen Unterton, wenn gerade ein Fehler entdeckt wurde, der in den internen Tests nicht gefunden wurde. Wie kann ich also meine eigene Einschätzung über ein Software Produkt plausibel darlegen?

Dafür brauche ich Anworten auf drei Fragen:

  • Welche Testfälle gibt es?
  • Was decken diese Testfälle ab?
  • Was sind die Durchführungsresultate dieser Tests?

Um diese Fragen beantworten zu können, brauche ich die entsprechenden Daten, um das zu belegen.

Welche Testfälle gibt es?

Die Testfälle müssen abgelegt werden. Ein Testfall, der nicht dokumentiert ist, ist wenig wert. Allfällig gefundene Probleme sind häufig nicht reproduzierbar. Er kann kein zweites Mal ausgeführt werden. Da aber gerade in iterativ inkrementellen Entwicklungsprozessen die Aufwände und Überlegungen zur Erstellung eines Testfalls sich erst bei einer wiederholten Ausführung auszahlen – am Ende jeder Iteration oder vielleicht noch häufiger – ist das eine schlechte Investition.

Die Testfälle sollen in einem definierten Format mit bestimmten Attributen dokumentiert und abgelegt werden. Je nach Kontext des Projekts gibt es für diese Ablage verschiedene Varianten – von einer Sammlung von Word Dokumenten über eine einfache Datenbank bis zu schwergewichtigen Testingwerkzeugen, in denen der gesamte Testingablauf abgebildet ist. Aus meiner Sicht muss eine solche Ablage einige Kriterien erfüllen:

  • Gut durchsuchbar: Gibt es zu dieser Thematik bereits Testfälle? Welche? Was für Testfälle sind in dieser Iteration neu dazugekommen?
  • Versionierbar: Was hat sich an diesem Testfall geändert? Wer hat die Änderung vorgenommen? Wann wurde der Testfall das letzte Mal angepasst? Wie kann ich mir eine alte Version besorgen?
  • Anpassungsfähig: Kann ich zusätzliche Attribute hinzufügen, die bei einem Testfall ausgefüllt werden müssen oder unnötige entfernen?
  • Navigierbar: Was sind die konkreten Testfälle zu diesem logischen Testfall? Welche logischen Testfälle haben noch keine konkreten Instanzierungen.

Wenn diese Eigenschaften gegeben sind, bin ich in der Lage, auf die erste dieser kritischen Fragen, “Welche Tests gibt es?”, eine differenzierte Antwort zu geben.

Was decken die Tests ab?

Abdeckung wird im Software Testing Umfeld meist technisch verstanden: Wieviel Prozent der Sourcecodeinstruktionen, Abzweigungen, etc. werden bei einem Test durchlaufen? Auch Wikipedia beschränkt sich unter dem Stichwort “Testabdeckung in der Softwaretechnik” auf dieses technische Mass. Die nackte gemessene Coveragezahl sagt aber wenig aus und ist nicht leicht zu interpretieren.

Abdeckung kann aber auch ganz anders verstanden werden. Ich betrachte die fachliche Abdeckung hier als erheblich hilfreicher. Wieviel Prozent der Abnahmekriterien sind abgedeckt? Zu welcher Businessrule hat es wieviele Testfälle?

Um Antworten auf diese Fragen geben zu können, müssen die Testfälle auf die Anforderungen gemappt werden. Es braucht die entsprechenden Attribute und sie müssen ausgefüllt und gepflegt werden. Diese Zusatzinformationen sind über die oben gestellte Frage hinaus auch extrem hilfreich bei Änderungen an den Anforderungen. Eine geänderte Regel muss Auswirkungen auf die Testfälle haben. Aber auf welche? Nur mit dieser Verknüpfung zwischen Testfällen und den Anforderungen, welche der Testfall überprüft, kann können diese Auswirkungen in die richtigen Testfälle eingearbeitet werden.

Was sind die Durchführungsresultate dieser Tests?

Die Information, welche Testfälle es gibt, kann noch keine Aussage über die Qualität des Produkts geben. Entscheidend ist die Frage, welche Tests wann, wie und mit welchem Resultat durchgeführt wurden. Erst die Testresultate geben Aufschluss darüber, wie der Zustand des Systems ist.

Jede Durchführung eines Testfalles muss unbedingt protokolliert werden. Neben den offensichtlichen Resultaten – success oder failure – ist gerade auch die Aussage, dass ein Testfall nicht durchgeführt werden konnte, ebenfalls interessant. Es muss also auch möglich sein, eine Ausführung als “nicht durchführbar” zu protokollieren, analog zum “Ignored” Flag bei JUnit.

Um nicht nur die manuellen Ausführungen zu protokollieren, sondern auch die automatische ausgeführten Tests, brauche ich hier eine geeignete Schnittstelle, an die ich meine TestDriver anbinden kann.

Auch bei den Ausführungsresultaten ist es hilfreich, wenn diese Informationen in einer Form abgelegt werden, die eine Suche gut unterstützt. Welche Tests sind in dieser Woche fehlgeschlagen? Zu welchen Tests existiert noch keine erfolgreiche Durchführung? Welche Testfälle haben bereits mehrmals von “success” auf “failure” und wieder zurück gewechselt? Solche Auswertungen sollten je nach Bedarf definiert werden können.

Wenn ich zu diesen drei Fragen eine fundierte Antwort bereit habe und sie mit den entsprechenden Daten belegen kann, bin ich in der Lage zu argumentieren. Ich kann dann sagen, dass das Produkt mit grosser Wahrscheinlichkeit in einem guten Zustand ist, oder ich kann mich erklären, wieso die ins Testing investierten Resourcen eben doch sinnvoll eingesetzt sind, auch wenn ein Fehler nicht gefunden wurde und dann erst beim Kunden für entsprechenden Aufruhr sorgt…

Leave a Reply

Categories