Wer zu spät testet, verschleudert Geld

08.09.2006
Von Stefan Ueberhorst

Solche Proofpoints geben dem Entwickler äußerst wichtige Informationen an die Hand. Er kann jetzt sofort nachfassen, wenn zum Beispiel der Verdacht aufkommt, dass ein Requirement-Detail nicht eindeutig definiert ist und deshalb folgenschwere Interpretationen in der Programmierung zulässt. Gleichzeitig stellt sich ein anderer positiver Effekt ein: Die frühe Verfügbarkeit von Akzeptanzregeln für den User-Acceptance-Test gibt dem Entwickler die Zeit, sich mit dem Thema Testautomatisierung zu beschäftigen. "Es ist schon schwierig genug, den User-Acceptance-Test manuell vorzunehmen. Noch weiter ist man davon entfernt, sich zusätzlich Gedanken über eine Automatisierung dieses Tests mit entsprechenden Skripten zu machen", schildert Golze die Praxis. SQS-Chef van Megen belegt dies mit Zahlen: Die von den meisten Entwicklern vorgenommenen Funktionstests erfolgen derzeit noch zu 60 bis 80 Prozent manuell. Etwa 80 Prozent dieser Tests ließen sich jedoch automatisieren.

Im Resümee ist es für Golze entscheidend, dass das Referenzmodell auf der Sprachbasis der Fachabteilung entsteht und sich zunächst nicht an den technischen Möglichkeiten der IT orientiert. Erst in einem Folgeschritt sollen Entwickler ihre Sicht auf das Modell legen, indem sie beispielsweise an einen in Word geschriebenen Funktionsbaum ihre technischen Spezifikationen an jedes Requirement anhängen.

Für Anbieter von Requirement-Management-Lösungen gibt es damit noch einiges zu tun. Zum einen gilt es, ein durchgängig prozessorientiertes Vorgehen mit entsprechenden Vorlagen und Workflows in die Testpraxis zu bringen. Insbesondere die großen Suitenanbieter wie IBM/Rational, Compuware, HP/Mercury und Borland/Seque sind in diesem Bereich mit ihren Produkten schon sehr weit fortgeschritten. Die zweite große Aufgabe, die noch alle vor sich haben, besteht darin, die bislang IT-lastigen Lösungen für die Nutzung durch den Fachanwender aufzubereiten, zumindest bezüglich der Requirement-Module. Eine Option dafür ist die Anbindung der Produkte an klassische Prozessmodellierungs-Werkzeuge, die sich wie das Aris Toolset ohnehin schon der Sprachbarriere zwischen Fachabteilung und IT angenommen haben.

Automatisierung

Die von den meisten Entwicklern vorgenommenen Funktionstests erfolgen derzeit noch zu 60 bis 80 Prozent manuell. Vier von fünf Tests ließen sich jedoch automatisieren.

Welcher Spagat dabei zu bewältigen ist, beschreibt Stephan Faßbender vom Beratungsunternehmen C1 SetCon GmbH. Die Herausforderung besteht dem Testexperten zufolge darin, dass eine gemeinsame Beschreibungssprache für die Anforderungsspezifikation so konkret und geschäftsbezogen sein muss, dass sich der Fachspezialist darin wiederfindet. Andererseits muss sie abstrakt und standardisiert genug sein, damit sie branchen- und technikneutral angewendet werden kann. Und schließlich sollte sie dann auch möglichst noch so formalisiert sein, dass sich daraus regelbasierende Tests ableiten lassen. An dieser Herausforderung arbeiten Tool-, Prozess- und Modellspezialisten schon seit Jahren, aber bislang ist ein Durchbruch in der Praxis der Entwicklung von Geschäftssoftware nicht gelungen. Test-Tools leisten heute bei konsequentem Einsatz eine Nachverfolgbarkeit von der Aufnahme der Anforderungen bis zu deren Implementierung und Test sowie die Abbildung etablierter methodischer Ansätze zur Testfallfindung, wie zum Beispiel dem risikobasierenden Testen. Die fachliche Komplexität und ihre Dynamik im Laufe eines Entwicklungsprojekts lassen bislang jedoch Versuche scheitern, mit durchgängigen Beschreibungsmodellen zu arbeiten, so Faßbender.