Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

31.08.2006

Wer zu spät testet, verschleudert Geld

IT-Projekte sprengen den Kosten- und Zeitrahmen, weil die im späten User-Acceptance-Test gefundenen Fehler aufwändig zu beheben sind. Die Tests sollten schon bei der Anforderungsspezifikation ansetzen.
Die Standish Group analysierte über 9000 IT-Projekte.
Die Standish Group analysierte über 9000 IT-Projekte.
Je früher die Testvorbereitung beginnt, desto geringer ist der Gesamtaufwand für den Test.
Je früher die Testvorbereitung beginnt, desto geringer ist der Gesamtaufwand für den Test.

Die Zahlen des von der Standish Group alle zwei Jahre veröffentlichten "Chaos Report" 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.

Hier lesen Sie …

Korrekturkosten

Wer einen Fehler in der frühen Phase der Anforderungsspezifikation findet, muss für dessen Korrektur etwa 100 Euro kalkulieren. Denselben Fehler nach einem User-Acceptance-Test auszubügeln kostet 7500 Euro.

Arbeitsplatz

Ein gut ausgestatteter Testing-Arbeitsplatz kostet maximal 40000 Euro. Die Anschaffung amortisiert sich also bereits bei der Vermeidung von 14 Fehlern, wenn die Fehlerbehebung ohne Tool 3000 Euro und mit Tool nur 200 Euro kostet.

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.

Auf die lange Bank geschoben

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.

Gekaufte Tools verstauben

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.

Ungeliebtes Kind

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.

Als Handlanger abgestempelt

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üchternd 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 entsprechend lückenhafter Beschreibungen 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 damit 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.

Beispiel für ein Vorgehensmodell

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 ihrer 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 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. 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. 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.

Kurze Wege führen nicht zum Ziel

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, den Kreis 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, 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 auch den kreativen Teil der methodischen Testfallfindung und Testdatendefinition aktiv unterstützen - oder gar den Fachspezialisten effektiv Tests erstellen lassen. Doch hier sehe er noch keinen bahnbrechenden Ansatz in der Branche.