Testplan oder Checkliste?

Wen man den coolen Test-Kids glaubt, haben Testpläne wenig Gutes an sich. Nur mit explorativen Tests, Session Based Tests oder Context Based Tests lassen sich wirklich viele Fehler finden und die Qualität richtig verbessern.

Sie müssen nicht jeden dieser Stile kennen, jedoch nur so viel: Sie kritisieren alle den klassischen Test Management Ansatz, in dem up-front ein umfassender Testplan erstellt wird, der dann mehr oder weniger von “Testsklaven” abgearbeitet wird. Der Testplan zerstört die analytischen und kreativen Fähigkeiten des Testers.

Mit üblichen Tools ist es aber sehr leicht Testpläne zu entwerfen, die eben diese negativen Aspekte mit sich führen.

So sieht z.B. ein Testplan in TestLink aus. Schon auf den ersten Blick erst mal recht einschüchternd:

Für einen Testfall kann man Testschritte hinterlegen. Das gibt ein enges Korsett für den Tester vor. Im Zweifel hält sich dieser an den Testplan, statt out-of-the-box zu denken und einen wichtigen Fehler zu finden.

Während die Test Case Definition äußerst ausgeklügelt ist, ist die Ausführung stumpf, man kann lediglich eine Textnotiz und ein Ergebnis hinterlegen.

Die UX dieser GUI erzwingt ja gerade zu das Handeln “ja keine Randnotizen und nicht abschweifen, nur schauen ob Testfall korrekt ist”.

Zwar kommt bei TestLink noch eine schlechte Usability hinzu, aber die grundsätzlichen Probleme teilen alle Test Management Tools. Überspitzt kann man sagen, ein Testwerkzeug welches “Testschritte” als Feature besitzt, ist zu 90% Schrott!

Trotzdem denke ich, dass Testpläne einen gewissen Wert haben. Genauso wie Unit Tests das für Programmierer tun, beschreiben sie das System und dokumentieren Verhalten und Wissen.

Anhand eines Test Planes kann man Auswertungen fahren. Irgendwie schafft es Vertrauen in die Software, wenn man sieht, dass viele Testfälle ausgeführt und bestanden wurden.

Vor einiger Zeit bin ich auf das Tool “Testpad” gestoßen. Dieses arbeitet mit Checklisten, die schnell und einfach abzuarbeiten sind, somit das nötige Vertrauen liefern, aber einen nicht von einem eigentlichen Test “Off-Roads” abhalten. Als ich Quality Spy entworfen habe, war mir das noch nicht bewusst, aber im Endeffekt habe ich ebenso genau dieses Design-Ziel gehabt.

Die Checkliste ist nur ein grober Fahrplan, sie enthält keine genauen Instruktionen wie der Test durchzuführen ist, wie z.B. die Bildung von Äquivalenz-Klassen für einen Formularinput. Entweder hat ein Tester dieses Know-How oder er ist ein Anfänger und hat es nicht.

Beispielsweise sieht der Test Plan, pardon die Checkliste, für Quality Spy’s Undo-Redo Funktion wie folgt recht spartanisch aus:

Bei der Ausführung kann man dann entsprechend die Punkte “Checken”, sodass man während des Tests einen groben Überblick hat, welche Bereiche man bereits geprüft hat.

Übrigens, die typische Skala “Passed/Failed” mag ich für manuelle Tests nicht. Das ist eine Skala für Testrobotor. Menschen können sagen “Bestanden, aber mit kleineren Problemen”. Somit entsteht dann in der Zusammenfassung schnell ein aussagekräftiges Bild und nicht die Situation “100%” der Tests bestanden, aber 50 Fehler gefunden.

Eine Checkliste ersetzt aus meiner Sicht nie das Testprotokoll, denn hier lassen sich Probleme und Kommentare einfach erfassen:

Aber nochmal zurück zu den cool Test-Kids, zu denen ich z.B. die Leute im Software Testing Club zähle und wo die meisten wahrscheinlich um Längen bessere Tester sind, als ich es bin. Die haben schon Recht, dass Testpläne nicht so gut sind. Aber kurze, knackige Checklisten sind ein hilfreiches Tool mit einem guten Aufwand/Nutzen Verhältnis.