Software-Entwicklung mit agilen Methoden

So weit die Theorie. Die Praxis sieht oft ganz anders aus. Selbst Projekte, die erklärtermaßen nach agilen Methoden vorgehen, erreichen oft instabile Ergebnisse und können die Projektvorgaben nicht mehr einhalten, selbst wenn sie mit XP, Rational Unified Process (RUP) oder einem ähnlich innovativen Modell arbeiten und die zahlreichen Feedback- und Testschleifen berücksichtigen. Die Ursache sind oft Tests, welche die Entwickler ad hoc und intuitiv durchführen. In diesem Fall halten sie zwar die Vorgaben der Entwicklungsmethode genau ein. Sie berücksichtigen jedoch nicht, dass auch das Testen systematisch erfolgen muss, wenn es zielführend und dann auch wirtschaftlich sein soll. So gehören zu einem sinnvollen Testprozess zum Beispiel Verfahren der Testfallermittlung und der Priorisierung der einzelnen Testobjekte. Sonst testen die IT-Spezialisten zwar, aber es ist mehr oder weniger dem Zufall überlassen, ob sie auch das Richtige und Wichtige testen.

Insofern ändert sich an den grundlegenden Testaufgaben mit den agilen Ansätzen nichts. Es ist die organisatorische Einbettung des Testens, die sich verändert: Das Testen wird entwicklungsnäher. Während die klassische Entwicklung zunächst ein fertiges Fachkonzept hervor brachte, das die Qualitätsspezialisten dann im Funktionstest auf Herz und Nieren prüften, sind Entwicklung und Test heute sehr stark verwoben. Deshalb muss die QS auch ihre Prozesse stärker iterativ gestalten und die Arbeitspakete kleiner zuschneiden.

All diese Maßnahmen greifen jedoch nur dann, wenn Entwickler und Tester auch mental die alten Rollenzuschreibungen ad acta legen. Darauf verwies XP-Pionier Kent Beck auf der vergangenen ICSTEST (International Conference on Software Testing) in Köln: „Die soziale Struktur unserer Arbeit muss sich verändern, wenn wir weiter erfolgreich sein wollen.“

Für die Qualitätssicherung heißt das: Sie muss sich zunehmend als Treiber der gesamten Entwicklungsprozesse definieren. Die Tester müssen in diesem Sinne auf gleicher Augenhöhe mit dem Entwickler diskutieren. Dies bedeutet natürlich auch, dass die Qualitätssicherer fachlich „näher dran“ sein müssen. Die Tester brauchen mehr Business-Know-how als bisher, müssen detaillierter mit den Feinheiten der Branche vertraut sein und sich auch mit den systemtechnischen Details der Entwickler besser auskennen. Nur so macht die zunehmend enge Abstimmung zwischen Entwicklern und QS – eher täglich statt monatlich – überhaupt Sinn.