Agil und instabil?

Eine der großen Herausforderungen in den iterativen Modellen ist es, die bewusst kleinen Module zu einem großen Ganzen zusammen zu fügen. Manche sehen hier den entscheidenden Punkt, an dem sich die Tauglichkeit der agilen Methoden erweist. Schließlich legen diese Ansätze ihren Schwerpunkt mehr auf die vielen kleinen Entwicklungsschritte der einzelnen Module. Insgesamt zeichnen sich heutige Systeme jedoch vor allem durch ihre rasant steigende Komplexität aus. So müssen auch agile Methoden die weiter aktiven Posten der IT-Vergangenheit berücksichtigen: von Unix-Servern als Basis für die Client/Server-Architektur bis hin zu den Mainframes, die etwa fast alle Banken für ihr Kerngeschäft betreiben.

Hier greifen Integrationstests. Sie prüfen, ob die Komponenten oder Software-Anwendungen fehlerfrei zusammenwirken. Für den Integrationstest haben sich vor allem zwei Hauptstrategien herauskristallisiert:

• Der geschäftsprozessorientierte Integrationstest betrachtet alle Systemkomponenten gemeinsam, die zusammen einen Geschäftsprozess abbilden. Die Tester nehmen dann zum Beispiel die Abwicklung eines Kundenauftrags unter ihre Fittiche: von der Akquisition über die Auftragserfassung, die Auslieferung bis hin zur Bezahlung. Im weiteren Verlauf nehmen die QS-Experten immer mehr solcher Geschäftsprozesse in den Test mit auf, bis die gesamte Anwendung ausreichend abgedeckt und getestet ist.
• Der technische Integrationstest hingegen testet zum Beispiel die Integration von Systemkomponenten, die eine gemeinsame Schnittstelle nutzen. Diese Tests werden anhand der Schnittstelle definiert.

Für die Analyse größerer Systeme und ihrer Bausteine eignet sich das Product Quality Assessment. Mit ihm untersuchen die Qualitätssicherer die vorhandene Architektur auf Basis des Quellcodes. Hierfür benutzen sie ausgefeilte Werkzeuge, mit denen sie feststellen, ob sich in der Programmierung relevante Architekturverstöße verbergen. Die Werkzeuge spielen hier einen entscheidende Rolle, denn die Anzahl der Programmzeilen, die Komplexität der vielen unterschiedlichen Objekte, die Vererbungsstrukturen und Komponentensichten machen es einem einzelnen Entwickler oder Tester ohne Hilfsmittel inzwischen sehr schwer, in großen Programmsystemen die wunden Punkte im Programmgewirr zu erkennen.

An dieser Stelle sind ausgewiesene Spezialisten von großem Nutzen. Sie machen die technischen Berichte aus den Product Quality Assessments erst zu hilfreichen Dokumenten, weil sie diese entsprechend interpretieren können. Die Reports machen nur deutlich, wo welche Komplexität im System verborgen ist. Die Architekturspezialisten können hingegen jenen Input geben, der über die Wirtschaftlichkeit der einzelnen Verbesserungsmaßnahmen entscheidet. Sie verstehen, ob die Komplexität Folge der geforderten Funktionen ist oder ob die Programme einfach nur verschlungen programmiert sind. Im ersten Fall ist die gefundene Komplexität eine Notwendigkeit, im letzteren treibt sie die Aufwände für Entwicklung und Wartung einfach nur sinnlos in die Höhe.

Systematische Tests und Qualitätssicherung entscheiden auch bei agilen Entwicklungsmethoden über die Wirtschaftlichkeit von Projekten oder sogar über deren gesamten Erfolg. Die rein formale Anwendung von Methoden wie XP mit dem Test-first-Ansatz sind nur ein Alibi, wenn nicht auch die Testprozesse beschrieben und gelebt werden. Sie sind besonders beim iterativen Vorgehen erfolgskritisch, weil sie die Ergebnisfortschritte der sehr vielfältigen Teilzyklen transparent machen. Diese Transparenz brauchen die Systemintegratoren, um die Teiliterationen sinnvoll integrieren und die Meilensteine des Projekts einhalten zu können. Dann bedeutet „agil“ am Ende auch „stabil“.

Dirk B. Meyerhoff ist als Entwicklungsleiter bei der SQS Software Quality Systems AG tätig.