Agile Methoden in der Entwicklung von Softwareanwendungen finden auch bei Banken immer stärkere Verbreitung. Bei aller Agilität darf aber gerade im Banking-Sektor die wichtige Überprüfung der Softwarequalität nicht vergessen werden. Mehr Agilität in der Entwicklung erfordert auch agile Testmethoden – quasi iterative Verbesserung im evolutionären Prozess.
Beim klassischen Vorgehen (z.B. „Wasserfallmodell“) sind Software-Entwicklung und Test zwei verschiedene, aufeinander folgende Phasen in einem linear ablaufenden Prozess. Die Qualitätssicherung (QS) wartet auf die Entwicklung, die ein aus ihrer Sicht finales Produkt oder Feature zum Testen übergibt. Die QS arbeitet dann seine detaillierten Testpläne ab. Dies umfasst nicht nur den Test neuer Funktionen, sondern auch die Suche nach regressiven Fehlern in bereits vorhandenen Funktionen. Und es gibt wohl kaum einen Tester oder Testmanager, der sich nicht die Frage gefallen lassen musste: „Warum ist dieser Fehler nicht im Test aufgefallen?“. Unter anderem diese Erfahrung motiviert viele QS-Abteilungen, möglichst viele Fehler zu entdecken und somit sehr gründlich zu testen – und das beansprucht entsprechend Zeit.
Treffen nun agile Entwicklung und der traditionelle QS-Ansatz aufeinander, muss das zwangsläufig zu Problemen führen. Im Rahmen agiler Methoden entstehen binnen kürzerer Zeit mehr Releases. Das setzt die QS unter zeitlichen Druck, weil die Menge der eigentlich zu erledigenden Tests signifikant ansteigt. Product Owner müssten sich jetzt also entscheiden, entweder in der Entwicklung zu bremsen, damit die QS mit den Release-Zyklen Schritt halten kann, oder den Umfang der von der QS angedachten Tests zu reduzieren. Das schmälert die Qualität der Software, erhöht die Kosten für Nacharbeiten und Mängelbeseitigung und verringert das Feedback in den agilen Prozess (Sprint Retros). Vor die Wahl gestellt, dürfte die Qualität aber das Entscheidungskriterium erster Wahl eines Product Owners sein.
Conclusio: Um mit der Geschwindigkeit agiler Methoden Schritt zu halten, müssen in der Qualitätssicherung der Banken andere Wege beschritten werden.
„Agiles Testen“ lautet die Antwort auf die skizzierten Probleme. Doch genauso wie „agil“ unterschiedliche Methoden umfasst, handelt es sich beim Agilen Testen um einen Sammelbegriff unterschiedlicher Test-Arten.
Da es kaum in Betracht kommt, die mühsam eingeführten agilen Entwicklungsmethoden zu bremsen, es also bei den häufigen Releases bleiben wird, ist agiles Testen dadurch gekennzeichnet, dass Tests häufiger durchgeführt werden müssen. Das kann nur dann gelingen, wenn Tests stärker automatisiert und gekapselt werden. Und zusätzlich sich ein Teil des Testens in die (agile) Software-Entwicklung selbst verlagert.
Gerade die Automatisierung bietet in agilen Umgebungen viel größeres Potenzial als beim klassischen Wasserfallmodell. Da der gleiche Testfall häufiger zu absolvieren ist, ist es viel sinnvoller, über Wege nachzudenken, diesen zu automatisieren.
Agiles Testen bedient sich verschiedener Testverfahren respektive Testdimensionen:
Sogenannte Unit-Tests, auch als Komponententest bezeichnet, werden hier als ein wichtiges Mittel eingesetzt. Im Kern geht es darum, zu überprüfen, ob die von den Entwicklern geschriebenen Komponenten so arbeiten, wie sie es beabsichtigen. Eine häufige (automatisierte) Ausführung der Unit-Tests wird angestrebt. Es ist üblich, die Tests in der gleichen Entwicklungssprache zu schreiben, wie das Testobjekt selbst. Unit-Tests stellen nicht nachträglich einen Fehler fest, sondern steuern eher die Entwicklung der Komponente. Es gibt inzwischen automatisierte Tools für Unit-Test, beispielsweise JUnit für die Java-Umgebung.
Aspekte von Unit-Tests:
Ein weiteres wichtiges Element im agilen Testen ist der Akzeptanztest. Hier wird die Funktionalität aus Sicht der Anwenderinnen und Anwender respektive der Kundinnen und Kunden überprüft. Auch hier gibt es inzwischen verschiedene Werkzeuge, die Akzeptanztests automatisiert durchführen können. Denn die Anwenderinnen und Anwender selbst sind keine Tester! Ihnen soll ja bereits ein möglichst fehlerfreies Produkt oder Release angeboten werden.
Bei der Formulierung der Akzeptanztests entwickeln Product Owner, Entwicklungsteam und beteiligtes Qualitätsmanagement ein gemeinsames Verständnis über die gewünschten Funktionalitäten und das Verhalten. Daraus werden die Akzeptanzkriterien definiert und parallel die Testfunktionalität automatisiert.
Ein pragmatischer Nebeneffekt: Im Laufe der Zeit entwickelt sich hier eine ausführbare Dokumentation des Gesamtsystems.
Eine starke Automatisierung des Testens bietet große Vorteile, gerade was das Auftreten von Regressionen betrifft. Aber die Automatisierung wird nie alle Szenarien abdecken. Für die „menschliche“ Komponente sorgt im agilen Testing der explorative Test. Kurz gesagt behebt er die wesentliche Schwäche aller Automatisierung, denn diese kann nicht (mit)denken. Der Einsatz der QS-Mitarbeitenden im Rahmen des explorativen Tests kann den Unterschied ausmachen zwischen einer Software, die sich „wie spezifiziert“ verhält, und einem Produkt, das „großartig“ ist.
Im Kern entdecken bei einem explorativen Test die Tester die Software selbst. Sie nutzen ihre Kreativität und denken sich komplexe Aufgaben - oder vielleicht zunächst abwegig erscheinende Nutzungsmuster - aus. Sie beobachten das Ergebnis und können so nicht nur Fehler entdecken, sondern der Entwicklung auch Vorschläge unterbreiten, wie es möglicherweise besser oder eleganter ginge. Bringen Tester ihr Wissen möglichst frühzeitig in das Projekt ein, hilft dies der Entwicklung.
Im gleichen Maße, wie agile Methoden in der Anwendungsentwicklung von Banken eingeführt werden, muss die Qualitätssicherung fokussiert werden. Schließlich erwachsen bereits aus der BAIT Verpflichtungen, die nur durch eine hohe Softwarequalität, IT-Sicherheit und das Testen erfüllt werden können.
movisco steht als verlässlicher und erfahrener Partner im Business und IT-Consulting (SAP GoldPartner) bereit, Banken bei den aktuellen Themen der Digitalisierung, der Einführung agiler Methoden und des agilen Testing (ISTQB SilverPartner) zu unterstützen und im Financial Reporting zu begleiten.
Wir freuen uns über Ihre direkte Kontaktaufnahme!