Test Driven Development – unterschätzt und oft missverstanden

Man muss auch die Testpläne und die Testfälle testen, ob sie nämlich überhaupt geeignet sind, die Eignung der Endprodukte zur Erfüllung der Anforderungen zu beurteilen. So Tom deMarco u.a. in ihrem Muster 35 („Testen vor dem Testen“) des legendären Buchs „Adrenalin Junkies & Formular Zombies“.

Testen ist viel mehr als nur „Testen“

Jedes Zwischenergebnis in einem Projekt, ob es ein Projektplan, eine Schnittstellenfestlegung, eine Prozessdefinition oder was immer ist, kann gegen die Anforderung getestet werden, die durch dieses Ergebnis erfüllt werden soll.

Bei jeder Verfeinerung oder Konkretisierung einer Anforderung oder einer Lösungsbeschreibung muss geprüft werden, ob diese mit der abstrakteren Version noch übereinstimmt bzw. deren sinnvolle Konkretisierung ist.

Ein Beispiel aus der Versicherungsbranche:

Anforderung: Die Freigabe von Zahlungen aufgrund von Leistungsansprüchen von Kunden soll in definierten Fällen nur nach einem 4-Augen-Prinzip erfolgen können.

Das kann durch folgende User-Stories konkretisiert werden, wobei jede User-Story eine Reihe von Fragen aufwirft, einige sind jeweils in der rechten Spalte ohne Anspruch auf Vollständigkeit angeführt:

Bei jeder Konkretisierung der User-Story muss also geklärt werden, welche Person bzw. welche Personen verbindlich beurteilen können, ob die Antwort auf die jeweilige Frage eine korrekte Detaillierung der ursprünglichen Anforderung ist. Es muss auch geklärt werden, ob die Konkretisierungen und Detaillierungen alle Aspekte abdecken oder noch Lücken bestehen, die gefüllt werden müssen. Man muss damit rechnen, dass trotz dieses Vorgehens immer wieder Erkenntnisse erst auftreten, wenn man weitere Konkretisierungsstufen hinter sich hat. Je früher man solche Lücken entdeckt, umso weniger Aufwand und damit auch Durchlaufzeit ist verloren. Trotz allem Bemühen werden manche Erkenntnisse erst erzielt, wenn konkrete Software vorliegt. Daher ist es sinnvoll, möglichst schnell von verbalen Beschreibungen zu anschaulichen Darstellungen überzugehen.

User-Stories mit Testfällen präzisieren

Völlig unterschätzt wird die Möglichkeit, diese Konkretisierung durch die frühzeitige Formulierung von Testfällen vorzunehmen. Oft habe ich schon gehört, man könne die Testfälle erst formulieren, wenn die Software erstellt ist. Natürlich ist es dann leichter, aber möglich ist es viel früher, eigentlich jederzeit.

Jede der oben angeführten User-Stories kann auch in Form von Testfällen formuliert werden.

Nehmen wir beispielhaft zwei solcher Anforderungen:

a. Nach welchen Regeln entscheidet das System, ob eine zweite Person notwendig ist?

Mögliche Kriterien: Betragshöhe der Zahlung, Art des Schadens (Personenschaden, Sachschaden), geschädigte Person im Nahverhältnis zum Schädiger J/N.

Mögliche Testfallbeschreibungen: Es werden verschiedene Merkmalsausprägungen in einer Matrix angeordnet und es wird jeweils angegeben, ob eine zweite Person die Zahlung freigeben muss. Diese Beschreibung wird den Entwicklern als Anforderungsbeschreibung zur Verfügung gestellt. Diese können bei Unklarheiten rückfragen, die Testfälle werden dann überarbeitet bzw. erweitert. Es ist wichtig, dass sowohl Fälle beschrieben werden, in denen das 4-Augen-Prinzip gilt als auch solche, wo kein 4-Augen-Prinzip erforderlich ist.

Wenn Software geliefert wird, kann anhand dieser Testfälle geprüft werden, ob die Anforderungen richtig verstanden wurden und ob die Software so funktioniert. Wird dabei festgestellt, dass nicht an alle Varianten gedacht wurde, werden die Testfälle erweitert und diese ebenfalls als Anforderungsdefinition den Entwicklern zur Verfügung gestellt. Dieser Zyklus kann mehrfach durchlaufen. Auch eine Reduktion der Anforderungen kann auf diese Weise entschieden und kommuniziert werden.

b. Welche Kriterien muss die zweite Person erfüllen, um eine Freigabe durchführen zu können (Rolle, Hierarchiestufe, Zugehörigkeit zu einer Organisationseinheit, …)?

Mögliche Regeln: Sie muss der gleichen Abteilung angehören. Sie muss die gleiche Rolle wie der SB haben (oder muss eine andere Rolle, z.B. Supervisor haben). Sie darf in diesem konkreten Schadensfall noch nicht als SB tätig gewesen sein (z.B. bei einer bereits erfolgten Teilzahlung).

Mögliche Testfälle: Die in Frage kommenden Merkmale werden als Checkliste dargestellt, es wird angegeben, bei welcher Merkmalskombination ein Rolleninhaber als Zweitprüfer in Frage kommt und in welchen Fällen dies ausdrücklich ausgeschlossen ist.

Resümée

Man erkennt schnell, wie komplex selbst diese einfache Anforderungsbeschreibung wird. Wenn diese schon von Anfang an in eine Liste von Testfällen herunter gebrochen werden kann, ist dies für alle Beteiligten leichter nachzuvollziehen als eine noch so detaillierte verbale Beschreibung oder grafische Darstellung.

Daher kann ich die Forderung von Tom deMarco u.a. nur unterstützen: „Der Sinn des frühzeitigen Testens besteht darin, möglichst viele Fehlannahmen, Missverständnisse, Widersprüche, unrealistische Erwartungen usw. so früh wie möglich aufzudecken – bevor sie fest verankert und nur noch schwer zu beseitigen sind“ (a.a.O. S. 91).

Die beste und detaillierteste Beschreibung eines solchen Vorgehens stammt von Gojko Adzic. Sein Buch „Specification by Example“ kann ich ohne Vorbehalt empfehlen.