Die Zahlen des von der Standish Group alle zwei Jahre veröffentlichten Chaos Reports sind erschreckend: Im Jahr 2004 (für dieses Jahr liegen noch keine Ergebnisse vor) konnten von 100 IT-Projekten nur 29 erfolgreich abgeschlossen werden. Als gescheitert galten 18 Vorhaben, während 53 die Zeit- und Budgetvorgaben sprengten beziehungsweise, um das zu vermeiden, im Funktionsumfang gekappt wurden. Das Bild verdüstert sich nochmals, wenn man die Vergleichszahlen von 2002 heranzieht, als immerhin noch 34 Prozent der Projekte gelangen, nur 15 Prozent abgebrochen werden mussten und 51 Prozent aus dem Rahmen fielen. Die Hoffnung damals, dass sich in der IT eine durchgängige Testpraxis, wenn auch auf niedrigem Niveau, etablieren könnte, war mit der 2004-Ausgabe des Reports verflogen.

Was im Maschinenbau, der Automobil- und der Luftfahrtindustrie selbstverständlich ist, wird in der IT buchstäblich auf die lange Bank geschoben: ein im Produkt-Entwicklungszyklus möglichst früh einsetzender Testprozess. Softwareprojekte starten mit der Anforderungsspezifikation (Requirements) und werden mit dem Fachkonzept beziehungsweise den Spezifikationen fortgesetzt. Es folgen Implementierung und Coding, wo auch die ersten Funktionstests stattfinden. Der eigentliche Rückschlag erfolgt oft im anschließenden User-Acceptance-Test, also kurz vor dem Rollout. Wie das National Institute of Standards and Technology in einer 2001 veröffentlichten Studie ermittelt hat, entstehen die meisten Fehler (etwa 70 Prozent) in der Requirements-Phase, gefunden werden sie jedoch erst im User-Acceptance-Test. Die Folgen sind verheerend: Um einen Fehler schon sehr früh, das heißt während der Anforderungsspezifikation, zu beheben, müssen rund 100 Euro kalkuliert werden. Denselben Fehler nach einem fehlgeschlagenen User-Acceptance-Test auszubügeln kostet das 50- bis 100-fache, im Durchschnitt also 7500 Euro.

Wie schnell diese Praxis Millionenbeträge verschlingen kann, belegt ein Zahlenbeispiel der auf Softwaretest- und Qualitäts-Management-Beratung spezialisierten SQS-Gruppe aus Köln. Hier geht man davon aus, dass im Enterprise-Umfeld pro 4000 Euro Projektvolumen ein Testfall benötigt wird. Für ein zehn Millionen Euro umfassendes Vorhaben bedeutet das also 2500 Testfälle, in denen erfahrungsgemäß jeweils mindestens ein Fehler entdeckt wird. Spätestens hier wird deutlich, welchen Unterschied es ausmacht, eine Fehlerkorrektur mit 100 oder 7500 Euro zu veranschlagen.

Angesichts dieser Fehlentwicklungen stellt sich natürlich die Frage, weshalb die Firmen das Thema Software-Testing nicht konsequenter angehen. Rudolf van Megen, CEO der SQS AG, beobachtet in vielen Unternehmen, dass zwar Testwerkzeuge angeschafft werden, diese aber nur teilweise oder gar nicht zum Einsatz kommen. Ursache dafür sei, dass die Tools nur einen eingeschränkten Nutzen bringen, wenn nicht gleichzeitig eine Testorganisation mit entsprechendem Know-how aufgebaut wird. So würden die angebotenen Produkte zum Beispiel keine Auskunft darüber geben, welche Funktionen oder Business-Prozesse überhaupt getestet werden müssen. Die Lösungen der marktführenden Hersteller bieten die Möglichkeit, vor allem die mechanischen Aspekte des Testens zu automatisieren, so etwa die Ausführung von Testskripts oder die Dokumentation von Testergebnissen. Damit die Tests aber in Übereinstimmung mit den Geschäftsprozessen laufen, benötigt man zusätzliche Methoden, anhand derer die Mitarbeiter überhaupt Geschäftsfälle für den Test auswählen und priorisieren können. Erfolgskritischer als die Werkzeuge selbst sind deshalb laut van Megen das Verstehen und Implementieren des Testprozesses. Das erfordert jedoch eine Testorganisation, die über den Tellerrand der rein operativen und mechanischen Arbeitsschritte hinausschaut und einen übergreifenden Ansatz in Form eines Brückenschlags zur Fachseite und deren Vorgaben sicherstellt.

Doch genau darin scheint das Problem zu liegen. "Mit Testen ist kein Blumentopf zu gewinnen, deshalb reißt sich auch niemand um diese Aufgabe", beobachtet Andreas Golze, Director Global Practice für Application Delivery bei Mercury. Im Prinzip müssten die Fachanwender testen, denn die sollen später ja auch mit dem Programm arbeiten. Die Fachabteilung hat aber andere Aufgaben, vor allem andere Kompetenzen, über die sich jeder Einzelne profilieren will. Testen ist da eher ein Störfaktor. Schließlich bedeutet es nur nachzuweisen, dass etwas so funktioniert, wie man es ohnehin haben wollte.

Problematisch ist auch die Haltung der IT-Seite: In den Augen der Entwickler sind Tester nicht selten Handlanger, die das, was der kreative Informatiker geschaffen hat, noch mal überprüfen. Realistisch betrachtet sollten laut Golze etwa 30 bis 40 Prozent vom Entwicklungsaufwand in das Thema Testen investiert werden. Doch die Projektleiter seien oft geneigt, von diesem Anteil ein größeres Stück abzuzwacken und zusätzlich in die Programmierung zu stecken, im Glauben, dass sich so von vornherein Fehler vermeiden lassen.

Unter solchen Voraussetzungen fällt die Praxis ziemlich ernüchtern aus. Das erste Problem taucht bereits auf, wenn die Projektbeteiligten der IT die Anforderungen der Fachabteilung aufnehmen. Weil ihm die Routine seiner Arbeitsschritte selbstverständlich geworden ist, ist der Business-Kollege selten in der Lage, alle Anforderungen exakt zu formulieren, will diese aber sehr wohl in der späteren Anwendung abgebildet finden. Auf Basis dieser lückenhaften Beschreibung erstellen die IT-ler mit Hilfe von Requirement-Werkzeugen eine unter Umständen mehrere hundert Seiten umfassende Spezifikation, die zur Absegnung wiederum der Fachabteilung vorgelegt wird. Doch die kann mit der Dokumentation nur wenig anfangen, weil die "Sprache" der Tools weitgehend der von Softwarearchitekten entspricht. Die Fachabteilung selbst hat keine Chance, mit den Requirement-Werkzeugen zu arbeiten, so Golzes Urteil. Trotzdem wird die Spezifikation unterschrieben, denn vor der Live-Schaltung gibt es ja ohnehin noch den User-Acceptance-Test, wo man fehlende oder anders gewollte Funktionen reklamieren kann. Was an Fehlern später im reinen Entwicklungsprozess entsteht, ist eher marginal, so Golze.

Die fehlerträchtigste Schwachstelle im Verlauf eines Software-Entwicklungsprojekts liegt also in der Phase der Anforderungserhebung und damit an der Schnittstelle zwischen IT und Fachabteilung. Eine Lösung dieses Problems sieht Golze in einem methodischen Ansatz, zum Beispiel in einem Referenzmodell, das die Beteiligten für eine Anwendung bauen. Vereinfacht bedeutet dies, dass im Laufe eines Arbeitstags eine Liste sämtlicher Aktivitäten, die zur Bewältigung einer bestimmten Aufgabe nötig sind, erstellt und innerhalb einer Baumstruktur abgelegt wird. Als nächstes hängt man hinter jeden dieser Arbeitsschritte die entsprechenden Anforderungen an. Ein simples Beispiel wäre: Zur Aktivität "Kunde anlegen" gehören die Requirements "Name", "Ort", "Straße" etc.

Der eigentliche Clou kommt in einem dritten Schritt: Um die Qualität der Requirements zu erhöhen, schlägt man den Business-Anwendern vor, zusätzlich zur Anforderung zu formulieren, wann diese aus seiner Sicht erfüllt ist. Golze bezeichnet diesen Teil des Referenzmodells als Proof- oder Checkpoints beziehungsweise als Akzeptanzregeln. Eine Regel könnte im genannten Beispiel sein, dass der Vorname gegen die Anrede geprüft wird. Damit würden bereits in dieser frühen Phase die Kriterien für den späteren User-Acceptance-Test festgelegt.

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.

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.

Selbst wenn man sich dem Idealzustand eines konsistenten Design- und Testprozesses nähert: Ein in sich geschlossener Software-Entwicklungszyklus kommt in der Realität oft dann vom Kurs ab, wenn es darum geht, spätere Änderungen im Design auch in den Requirements nachzupflegen. Nicht selten stellt sich heraus, dass die eine oder andere Funktionsspezifikation anders als ursprünglich gedacht implementiert oder während des Lebenszyklus einer Applikation geändert werden muss, was dann gerne auf kurzen Wegen erfolgt. Ein vollständig ableitbares Testmodell würde jedoch erfordern, dass solche Modifikationen in der Anforderungsspezifikation hunderprozentig nachgeführt werden. "Diese Prozessqualität bekommt kaum eine Organisation konsequent und durchgängig hin", so die Praxiserfahrung von Faßbender. Ein geschlossener Modellansatz von der Anforderung bis zur Anwendung wird damit ausgehebelt.

Einen weiteren Versuch, die Kette zu schließen, sieht der Experte in dem jüngst aufgekommenen Ansatz des Model-driven Testing. Ihren Ausgangspunkt hat diese Entwicklung im Bereich technischer Softwaresysteme, etwa in der Telekommunikation, wo sich die Spezifikationen gut in abstrakten Modellen beschreiben lassen. Es bleibe abzuwarten, ob sich solch ein Vorgehen auch im Bereich der Geschäftssoftware etablieren lässt.

Was sich Faßbender letztlich für den Tester wünscht, sind intelligente Tools, die nicht nur den mechanischen Teil der Erstellung und Verwaltung von Tests abbilden, sondern auch den kreativen Teil der methodischen Testfallfindung und Testdatendefinition aktiv unterstützen - oder gar den Fachspezialisten effektiv Tests erstellen lassen. Doch das sei Zukunftsmusik, hier sehe er noch keinen bahnbrechenden Ansatz in der Branche.

Einig sind sich die Spezialisten darin, dass das Thema Testen in den Unternehmen künftig sehr viel ernster angegangen wird. Die Firmen werden von den Todsünden der Vergangenheit eingeholt, heißt es in der Branche, denn der Einzug der IT hat inzwischen ein Ausmaß angenommen, dass Systemausfälle zunehmend verheerende Folgen haben. Hinzu kommt, dass die Bereiche Softwareentwicklung und betriebswirtschaftliche Software bereits über ausgereifte Vorgehens- und Prozessmodelle verfügen - lediglich im Testumfeld werden diese Ansätze noch nicht praktiziert. Und dies in Zeiten, in denen die Industrie verstärkt auf Web-Services-Techniken und Service-orientierte Architekturen setzt. Die Qualitätssicherung solcher Infrastrukturen wird deutlich komplexer und setzt die systematische Spezifikation und Pflege von Testfällen zwangsläufig voraus. (ue)