Testen

Testen ist ein wesentlicher Bestandteil der Softwareentwicklung unabhängig davon welche Entwicklungsmethode verwendet wird. Innerhalb von XP hat das Testen eine besondere Aufgabe, da man XP auch als validierungszentrierte Softwareentwicklung auffassen kann. Alle Artefakte, die im Verlauf von XP entstehen, werden getestet.

Auf den ersten Blick sieht XP zwei wesentliche Arten von Tests vor: Akzeptanztests sowie Komponententests für Aufgaben. Erstere spezifiziert der Kunde vor Ort, um sicherzustellen, daß die Benutzergeschichten richtig implementiert werden. Komponententests wiederum werden beim paarweisen Programmieren erstellt, die damit einzelne Teile des Systems prüfen.

In allen Fällen ist die Vorgehensweise so, daß immer zuerst der Test erstellt wird. Dabei muß darauf geachtet werden, daß die Tests nichts über die Art der Implementierung vorgeben. Anders ausgedrückt: Es wird vorgegeben, wie mit dem System umgegangen wird (welche Funktionen aufgerufen werden), und welches Ergebnis dabei herauskommen soll. Wie das System von den Eingaben zum Ergebnis kommt, bleibt offen.

Validierungszentrierte Softwareentwicklung

Neben diesen offensichtlichen Tests (Akzeptanztests, Testfälle) gibt es noch weitere Bereiche, wo XP besonderes Merkmal auf die Validierung legt.

Programmieren in Paaren wirkt auch wie eine fortlaufende Überprüfung des Quelltextes.

Da dem Kunden relativ kurzfristig erste Prototypen zur Verfügung stehen, kann er sofort überprüfen, ob das, was implementiert wurde, mit dem übereinstimmt, was er eigentlich haben wollte. Dieser Abgleich findet dabei nicht erst am Ende des Releasezyklus statt, sondern sehr viel früher. Der Kunde kann daher auch viel früher auf Fehlentwicklungen reagieren.

Was wird getestet?

Getestet wird alles, was kaputt gehen kann. Anders ausgedrückt: Wenn nach dem Release keine Fehler entdeckt werden, hat man genügend Tests. Treten Fehler auf, so sind nicht genügend Tests vorhanden, zumindest nicht die richtigen.

Nachdem nahezu kein System mehr entwickelt wird, ohne auf existierende Produkte wie z.B. Bibliotheken zurückzugreifen, stellt sich auch die Frage, ob man diese Drittanbieterprodukte ebenfalls testet. Hier ein Beispiel aus der Praxis:

Ein Ticketsystem für den Servicebereich verwendet ein Datenbanksystem. Sollen für dieses Datenbanksystem ebenfalls Testfälle geschrieben werden?

Man kann hier eine Analogie zur verarbeitenden Industrie aufzeigen. In den letzten zwei Jahrzehnten wurde die Wareneingangsprüfung sukzessive abgeschafft, und statt dessen Qualitätsmanagementprozesse bei den Lieferanten eingeführt. Der Lieferant muß also nachweisen, daß die von ihm gelieferte Ware die geforderte Qualität hat. Der Abnehmer kann im Normalfall davon ausgehen, daß dies auch so ist. Auf diese Weise wird nicht auf jeder Herstellungsstufe sowohl eine Wareneingangs- als auch eine Warenausgangsprüfung vorgenommen. Betrachtet man die gesamte Wertschöpfungskette, so ergeben sich durch die Vermeidung der Doppelprüfungen Verbesserungen in der Kostenstruktur.

Das gleiche läßt sich auf die Softwareentwicklung übertragen. Es wird nicht geprüft, ob eine zugelieferte Ware tatsächlich in allen Teilen funktional einwandfrei arbeitet. Egal welchen Test der Abnehmer im Rahmen seiner "Warenausgangsprüfung" ausführt, es ist unmöglich zu vermeiden, daß nicht auch Teile der zugelieferten Software geprüft werden.

Im Falle des Ticketsystems führt die Eingabe eines neuen Tickets unweigerlich zu einer Transaktion im Datenbanksystem (DBMS). Sollte das DBMS einen Fehler in diesem Bereich aufweisen, so wird er zu Tage treten. Und da die Tests zeitgleich mit den Benutzergeschichten bzw. mit den Aufgaben implementiert werden, werden solche Fehler auch nicht erst am Ende des Releasezyklus entdeckt, sondern sehr viel früher. (Bem.: Diese Vorgehensweise ist nicht geeignet für Systeme, die a) sehr lange im Einsatz sein werden und b) sehr teuer in der Anschaffung sind. Ich habe keine gute Lösung für dieses Scenario.)

Tipps

• Auch Tests und Testcode werden refaktoriert.
• Wer sich den Wolf testen möchte, ist mit den Standardwerken über Testen von Boris Beizer und Robert V. Binder bestens bedient.
• Test dienen nicht nur dem Auffinden von Fehlern, sondern auch dem Vermeiden derselben. Letzteres ist nicht unumstritten.