Testmanagement in Public-Projekten - was tut sich da?

Entwicklung des Testmanagements in Public-Projekten

Der Softwareentwicklung im Bereich der öffentlichen Verwaltung liegt schon seit längerer Zeit nicht mehr ausschließlich das klassische Wasserfall-Vorgehensmodell zu Grunde. Wie in vielen anderen Branchen üblich, kommen auch hier zunehmend agile Vorgehensweisen zur Anwendung. Selbst das ehrwürdige Vorgehensmodell V-Modell hat diese Entwicklung aufgegriffen und sieht mit dem V-Modell XT die Integration von agilen Ansätzen vor.

Dieser Trend, der nicht auf den ersten Blick mit der öffentlichen Verwaltung in Verbindung gebracht wird, kommt nicht von ungefähr: Softwareentwicklungsprojekte im Public-Sektor sind häufig äußerst anspruchsvoll. Die Komplexität ergibt sich insbesondere aus den zahlreichen Schnittstellen eines Verfahrens zu anderen Behörden - auch nationenübergreifend beziehungsweise europaweit und spiegelt sich häufig in entsprechend großen Projektstrukturen wider. Zudem gilt es, gesetzliche Vorgaben zeitnah umzusetzen oder bestehende - oftmals technologisch veraltete - Verfahren abzulösen. Agile Vorgehensweisen sind daher eine gute Möglichkeit, um Komplexität zu entzerren und Anforderungen priorisiert in kurzen Entwicklungszyklen umzusetzen.

Persönliche Erfahrungen mit agilen Vorgehensweisen

Als ich vor Jahren begann, mich mit der agilen Vorgehensmethode Scrum auseinanderzusetzen, war ich erst einmal sehr enttäuscht. Ich habe bis dahin viele Erfahrungen im Testing sammeln können und fand im ganzen Scrum-Modell nicht einmal das Wort Test, geschweige denn die Rolle des Testers. Ich stellte mir daher folgende Fragen: Soll der Test als ein wesentliches und anerkanntes Element der Qualitätssicherung jetzt keine Rolle mehr spielen? Würden meine gesammelten Testerfahrungen zukünftig nicht mehr benötigt werden?

Es hat eine Weile gedauert, bis ich Scrum besser verstand und erkannte, dass der unabhängige Test auch in Scrum ein fester Bestandteil des Softwareentwicklungsprozesses ist und bleibt. Der Umstieg auf eine agile Vorgehensweise in meinen Folgeprojekten war für alle Beteiligten im Projekt eine Herausforderung. Schließlich stellt ein solcher Umstieg die bisherigen Definitionen von Rollen, Prozessen und Aufgabenverteilungen in einem Softwareentwicklungsprojekt vielfach in Frage und erfordert neue Lösungsansätze.

Mein aktueller Eindruck ist, dass die neuen Rollen - Product Owner (Requirement Engineering) und Developer - ihre bisherigen Rollen und Prozesse schon recht gut auf Agilität angepasst haben. Aber wie weit ist hier der Test? Und worin liegen hierbei die zu klärenden Fragestellungen? Gibt es vielleicht Dinge, die wie bisher ihre Gültigkeit behalten?

Sehr schnell wurde mir bewusst, dass ich meine liebgewonnenen und gut beherrschten Testvorgehensweisen in der agilen Welt nur schwer bewahren kann. Es zeigte sich aber auch recht schnell, dass prinzipielle Ansätze für das Testvorgehen nicht an Aktualität verloren haben. Der Test ist weiterhin unverzichtbar für die Prüfung und den Nachweis einer vollständigen und fehlerarmen Umsetzung von Anforderungen.

Kurze Entwicklungszyklen sind ein wesentliches Merkmal von agilen Vorgehensweisen und das hat Auswirkungen auf den Test. Die Vorgabe, nach jedem Sprint eine getestete und lauffähige Softwareversion zu haben, erfordert es, Testaktivitäten parallel zur Entwicklung zu beginnen. Nicht nur Entwicklerinnen und Entwickler, sondern auch Testende benötigen hierfür immer den aktuellen Kenntnisstand der umzusetzenden Sprintanforderung. Zudem ergeben sich Chancen, dass sich Developer sowie Testende gegenseitig helfen, ohne dass der Testende dabei seine Unabhängigkeit aufgibt. Dazu zählen beispielsweise Skripte, die die Testdatenbereitstellung vereinfachen oder der Test kann ein Set an Testfällen bereitstellen.

Ein weiterer Aspekt liegt in der Verkürzung des Testzyklus. Hatte man früher circa ein bis zwei Wochen Zeit für (Systemintegrations-) Tests, werden Testergebnisse heute schon nach ein bis zwei Tagen benötigt. Dies gelingt nur mit der Automatisierung von Testfällen. Ist es nicht möglich, alle Fälle zu automatisieren, dann aber möglichst einen großen Teil davon.

Meiner Erfahrung nach, sollte das Augenmerk auch auf den Aufbau und die Pflege von Regressionstestfällen gelegt werden. Regressionstestfälle weisen nach, dass die bisher umgesetzte Funktionalität einer produktiven Version auch in der Version fehlerfrei vorliegt, die sich noch im Test befindet. Die Menge an Regressionstestfällen nimmt also von Version zu Version zu und bedeutet einen gewissen Pflegeaufwand. Regressionstestfälle stellen jedoch gerade in langläufigen Projekten einen unschätzbaren Wert dar: dank ihnen kann das bisherige Systemverhalten schnell nachgestellt werden. Und Hand aufs Testerherz - wer von euch hat nicht schon einmal die Situation erlebt, dass ein Developer felsenfest davon überzeugt war, dass das System noch nie über eine bestimmte Funktion verfügte? Da sind Testfälle zum Nachweis einfach Gold wert!

Mein Fazit

Ich kann sagen, dass ich meine ersten Meter auf dem Weg zum agilen Testen gegangen bin und Gefallen daran gefunden habe. Als besonders angenehm habe ich die Annäherung zwischen Entwicklung und Test empfunden. Beide Seiten verstehen sich jetzt besser in ihren Nöten und Wünschen und können sich gegenseitig helfen.

Derzeit werden in adesso-Projekten verschiedene Ansätze für ein agiles Testvorgehen entwickelt und eingesetzt. Eine fertige Lösung „aus dem Regal” wird es nicht geben. Zu sehr haben die konkreten Projektrahmenbedingungen Einfluss auf die Lösungsfindung.

Ihr möchtet erfahren, mit welchen Themen wir im Public-Bereich unterwegs sind? Dann werft einen Blick auf unsere Website.