Ihr Standort: movisco // Blog »
kontakt mail icon
kontakt phone icon

Auswirkungen agiler Anwendungsentwicklung auf die Testpraktiken in Banken

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.

Agiles Projekt- und Produktmanagement in Banken erfordert auch agiles Testing

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.

Wasserfall-Testing und Agilität passt nicht zusammen

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: schneller zum Erfolg

„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.

Verschiedene Testdimensionen der Qualitätssicherung

Agiles Testen bedient sich verschiedener Testverfahren respektive Testdimensionen:

 

1. Testdimension: Unit-Tests

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:

  • Im Idealfall sind Unit-Test gut voneinander isoliert, d.h. dass die Reihenfolge ihrer Durchführung nicht das Ergebnis eines anderen Tests beeinflusst.
  • Sie sichern möglichst nur eine Eigenschaft ab.
  • Zudem sind sie vollständig automatisiert, um uch unter Zeitdruck ausgeführt werden zu können.
  • Und sie sollten vor dem zu testenden Code geschrieben werden

 

2. Testdimension: Akzeptanztests

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.

 

3. Testdimension: Exploratives Testen

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.

Verpflichtungen aus der BAIT umsetzen

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-Expertise

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.

 

Kontakt


Ihre Ansprechpartnerin

Susanne Jung

info@movisco.com
elektronische Visitenkarte

Fon +49 40 767 53 777

Schnellkontakt-Formular

Die abgesendeten Daten werden nur zum Zweck der Bearbeitung Ihres Anliegens verarbeitet. Weitere Informationen finden Sie in unserer Datenschutzerklärung.

Datenschutz bestätigt?

Sie haben Fragen?

Wir freuen uns über Ihre direkte Kontaktaufnahme!

  • Telefon: +49 40 767 53 777
  • E-Mail