Testen bei agiler Softwareentwicklung

Testen bei agiler Softwareentwicklung

Automatisierung als Lösung?

1000

Verwandte Inhalte

FTM Bildwelt: Haus im Schnee

“The days when clients could wait for multiple years between projects and upgrades are long gone. Clients want to be agile and need the ability to react quickly to changing business needs, implement a new policy and comply with the latest legislation and regulation. Test automation is an essential element of being able to execute regular cost effective and repeatable upgrades. At ION, as part of our development lifecycle, test automation and acceptance test driven development are rigorously implemented while we build our software in continuous integration environments. Furthermore our clients can use the same test tools and Test Automation Service for their own testing, this minimises the need for manual, error prone and labour intensive testing, which in turn significantly reduces the number and duration of downstream test cycles.”

David Atzeni, Director Research&Development bei ION Trading ­ mittlerweile Eigner von mehreren Treasury- und Commodity-Management-Systemen fasst die Folgen der Umstellung auf agile Softwareentwicklung für das Testen zusammen. Aber nicht nur ION-Kunden sehen sich mit dieser Änderung konfrontiert, denn immer mehr Softwarehersteller auch aus dem Umfeld von Treasury-Management-Systemen wie etwa SAP oder FIS stellen auf agile Entwicklung um. So beschreiben Dirk Joachim Henn, Produktmanager für SAP Treasury, und Jean-Philippe Lombardi, Direktor für Agile Transformation, den Ansatz von SAP: ”SAP started its agile journey to succeed in the cloud many years ago. First and foremost, SAP applies SCRUM@SCALE in all programs in order to receive early feedback – also from end users in the course of design thinking projects. Further, the teams put criteria in place to ensure not only external, but also internal quality of the software. The latter is particularly important to keep productivity high.”

Was bedeutet agile Softwareentwicklung?

Eine detaillierte Beschreibung, was agile Software-entwicklung kennzeichnet und deren Auswirkungen  finden Sie in unserem Dezember Newsletter unter dem Titel „Die Auswirkungen agiler Softwareentwicklung auf TMS-Projekte“.

Zusammengefasst lässt sich sagen, dass es das Ziel der Hersteller ist, in Form von kürzeren Entwicklungszyklen (Sprints), die zu Blöcken zusammengefasst werden, schneller auf Anforderungen durch Kunden oder von gesetzlicher Seite reagieren zu können und somit neue Funktionalitäten zur Verfügung zu stellen. Im Allgemeinen dauert ein Sprint zwei bis vier Wochen. Am Ende eines Sprints erfolgen zwei Dinge:

  1. Den Kunden wird die Entwicklung präsentiert, sodass diese ihr Urteil direkt abgeben können.
  2. Auf Basis der vorhandenen Entwicklungskapazitäten und der vorgefilterten Themen(„User Stories“) entscheidet der Hersteller, was im nächsten Sprint entwickelt wird. Dabei werden Korrekturen oder Änderungen auf Basis von Kundenwünschen, die bei der Präsentation geäußert wurden, ebenfalls berücksichtigt.

Zum Beispiel werden sechs derartige Sprints zu einem Block zusammengefasst und an die Kunden ausgeliefert. Das bedeutet, dass Unternehmen alle paar Monate (zum Beispiel bei sechs Sprints zu je zwei Wochen alle drei Monate) ein Bündel an neuen Funktionalitäten erhalten, das letztendlich in den Produktivbetrieb integriert werden sollte. In Zukunft werden daher große Upgrade-Projekte für ein Treasury-Management-System (TMS) immer seltener. Diese werden durch laufende Aktivitäten ersetzt, sodass das TMS auch immer auf dem aktuellsten Stand ist. Das bedeutet ein permanentes Testen – im Wesentlichen auch für den Fachbereich, der jede neue Funktionalität abnehmen muss.

Wie sieht das Testen bisher aus?

Bevor eine neue Funktionalität in den Produktivbetrieb übernommen werden kann, muss diese getestet werden. In klassischen Projekten werden dabei folgende Testphasen unterschieden und durchlaufen:

  • Entwicklertest beim Hersteller: Damit stellt dieser sicher, dass die Software mit entsprechender Qualität ausgeliefert wird. Alle weiteren Testphasen finden beim Kunden statt.
  • Funktional- oder Unit-Test, bei dem nur die unterschiedlichen Funktionalitäten modular für sich getestet werden.
  • Integrationstests, um sicher zu stellen, dass alle übergreifenden Abläufe inkl. Schnittstellen weiterhin reibungslos funktionieren.
  • System-Performance und technische Sicherheits-Tests, bei denen auf der einen Seite die Systemkapazitäten verifiziert und auf der anderen Seite das korrekte Verhalten bei Systemausfällen geprüft werden.
  • Abnahmetests („User Acceptance Tests“), die letztendlich darüber entscheiden, ob die neue Version bzw. einzelne Funktionalitäten des TMS in die Produktion übergehen. Diese letzte Testphase wird häufig auch dazu verwendet, die Anwender zu schulen.

Es ist offensichtlich, dass diese klassischen, vollumfänglichen Testzyklen nicht alle drei Monate durchlaufen werden können – zumindest nicht, wenn sie primär manuell durchgeführt werden, was bei vielen Unternehmen der Fall ist.

Welche Veränderungen sind beim Testen daher notwendig?

Hier treffen nun die Anforderungen aus der Umstellung der TMS-Hersteller auf agile Entwicklung mit dem häufig getroffenen guten Vorsatz bei Unternehmen, das Testen zu verbessern (dieser wird im Allgemeinen dann getroffen, wenn es darum geht, die notwendigen Testfälle zu erstellen), zusammen. Im Rahmen eines TMS-Upgrade- oder -Einführungsprojektes stellt sich immer wieder heraus, dass Unternehmen für das Testen und insbesondere dessen Vorbereitung nicht ausreichend Zeit einplanen. Als Konsequenz leidet insbesondere die Testdokumentation und damit verbunden ihre Wiederverwendbarkeit.

Um in kurzen Abständen neue Funktionalitäten in Produktion nehmen zu können, sind standardisierte Testfälle unumgänglich. Diese können aber auch nicht jedes Mal manuell durchgearbeitet werden, denn dies würde auf Dauer zu viele Ressourcen binden. Darüber hinaus sind neue Testfälle aufgrund von neu hinzugefügter Funktionalität zu ergänzen. Damit wird der notwendige Testkatalog stetig erweitert. Daher ist eine Automatisierung des Testens die logische Konsequenz. Ein Verringerung des Testumfanges oder gar ein Verzicht auf einzelne Testphasen erhöht das Risiko, dass Fehler im produktiven Betrieb auftreten, was tunlichst vermieden werden sollte.

Vorerst bedeutet dies einen erhöhten Aufwand in Form eines separaten Projekts zur Einführung eines Tools zur Testautomatisierung. Dieses gliedert sich in folgende drei Schritte:

  1. Es wird entschieden, welches Testtool zum Einsatz kommen soll. Häufig ist der TMS-Hersteller, insofern er selbst automatisiert testet, der erste Ansprechpartner. Andernfalls läuft man Gefahr, dass das Treasury-Management-System mit dem Testtool nicht kompatibel ist. In der Folge können dann große zusätzliche Aufwände bei der Integration dieser beiden Komponenten entstehen.
  2. Anschließend sind die fachlichen Geschäftsvorfälle, welche abgebildet werden müssen, zu definieren. Das erfolgt nach klaren Kriterien, wie der Häufigkeit des Auftretens, der Bedeutung für den gesamten Geschäftsbetrieb und der Komplexität. Diese fachlichen Geschäftsvorfälle werden anschließend in einzelne Testfälle übertragen, welche automatisiert werden. Beispiele dafür sind die Deal-Erfassung und dessen Verarbeitung in einzelnen Schritten bis hin zur Auslösung von Zahlungen und Verbuchungen, Ermittlung von Kennzahlen, Auswertungen, Limitüberschreitungen, Hedging, etc.
  3. Im letzten Schritt werden diese Testfälle für das gewählte Testtool aufbereitet. Jedes Tool hat seine individuellen Vorgaben, wie Informationen zum Beispiel zu Transaktionen (Instrument, Kontrahent, Betrag, Preis, etc.) für die automatische Verarbeitung vorzubereiten sind. Als Ergebnis liefern diese Systeme im Allgemeinen Berichte, die farblich (Grün vs. Rot) anzeigen, ob ein Testfall erfolgreich abgeschlossen werden konnte. Dabei wird das Ergebnis mit definierten Kriterien, abhängig vom Ziel eines Tests verglichen. Kriterien können zum Beispiel sein, dass ein Deal ohne Fehlermeldung prozessiert wurde, berechnete Kennzahlen werden mit erwarteten Werten verglichen, Limit-Warnungen werden ausgelöst. Folglich muss man beim eigentlichen Testen nur die fehlerhaften Testfälle analysieren, um die Ursache zu finden und sie zu beheben.

Es ist offensichtlich, dass zumindest Unit-, Integrations- und Performancetests automatisiert werden können. Wie bereits erwähnt, werden Abnahmetests zusätzlich zur Schulung der Anwender verwendet. Aber auch hier ist ein grundsätzliches Umdenken notwendig. Aufgrund der kurzen Intervalle, in denen neue Funktionalität zur Verfügung gestellt wird, gibt es nicht mehr die großen Veränderungen zwischen dem alten und neuen Release des Treasury-Management-Systems. Es ist ein laufender Prozess bestehend aus vielen kleinen Schritten. Damit erfolgt das Lernen ständig am laufenden System. Es ist hilfreich, wenn die betroffenen Anwender bereits an den Präsentationen des Herstellers teilnehmen. Natürlich ist eine entsprechende Dokumentation und Kommunikation durch die Hersteller unumgänglich. 

Und warum ist das Treasury davon betroffen?

Der Trend der Umstellung auf agile Softwareentwicklung macht wie zu Beginn ausgeführt auch vor Herstellern von Treasury-Management-Systemen nicht halt. Das Treasury sollte die Veränderungen, die dadurch entstehen, rechtzeitig annehmen. Die Einführung der Testautomatisierung ist ein eigenständiges Projekt, welches idealerweise nicht mit einem Upgradeprojekt oder einer Neueinführung kombiniert werden sollte, da dies die Projektrisiken signifikant erhöhen würde.

So fasst Andrew Owens, Group CTO bei FIS für Treasury-Lösungen, die aktuelle Situation und Vorgehensweise zusammen, was auch als Appell an das Treasury verstanden werden kann, sich mit diesem Thema aktiv auseinanderzusetzen:

FIS uses agile development across our Treasury and Payments development groups. We also have a high degree of alignment across these groups. The combination of agile processes with our ‘Continuous Integration’ frameworks is helping us to increase software quality and development velocity, whilst providing our product management team with a large amount of flexibility on setting and adjusting the product roadmaps. FIS has a mature ‘Continu-ous Integration’ framework in place for our treasury and payments solutions. The scope of this framework includes automated build and testing, where we run many thousands of tests at least daily.

We use a variety of tooling to assist with unit testing, GUI testing, integration testing, end-to-end testing and security vulnerability testing (static code scanning). The FIS testing framework is in place internally and we are also offering it to our clients in case they want to utilize it for their testing requirements.”

Quelle: KPMG Corporate Treasury News, Ausgabe 64, Februar 2017
Autor: Karin Schmidt, Senior Manager, Finance Advisory, karinschmidt@kpmg.com

Finanz- & Treasury Management

Das Expertenteam vom KPMG weist Ihnen den richtigen Weg im Finanz- und Treasury-Management.

 
Lesen Sie mehr

KPMG Corporate Treasury News

So kontaktieren Sie uns

 

Angebotsanfrage (RFP)

 

Absenden

KPMG's neue digitale Plattform

KPMG hat einen neuen Webauftritt entwickelt, der einen möglichst einfachen, nutzerfreundlichen Zugang zu den Inhalten von KPMG bieten soll.