Wer zu spät testet, verschleudert Geld

IT-Projekte sprengen deshalb so oft den Kosten- und Zeitrahmen, weil die im späten User-Acceptance-Test gefundenen Fehler nur aufwändig und teuer zu beheben sind. Die Tests sollten schon in der frühen Projektphase der Anforderungsspezifikation ansetzen.

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.