Eine deutsche Regionalbank stand aufgrund eines auslaufenden Wartungsvertrages vor der Aufgabe, ein neues Core-Banking-Systems für ihre ausländischen Niederlassungen zu implementieren. Es handelt sich dabei um Geschäftseinheiten in den USA, in Singapur und in China. Diese sollten von der Applikation Midas auf die Applikation Avaloq umgestellt werden. Weitere ausländische Einheiten der Bank (zum Beispiel in Großbritannien) hatten aufgrund der spezifischen dort implementierten Geschäftsprozesse keinen Bedarf für das neue System.
Die bereits genannten Niederlassungen verfügten neben dem alten Core-Banking-System über weitere Systeme, mit denen Aufgaben, unter anderem im Umfeld des regulatorischen Berichtswesens, des Zahlungsverkehrs, des internen Reportings und der Archivierung erfüllt werden. Das neue Core-Banking-System soll für alle Geschäftseinheiten zentral in Luxemburg betrieben werden, da die Applikation Avaloq von der dort ansässigen organisatorischen Einheit bereits zwei Jahre zuvor implementiert wurde und daher entsprechende Erfahrungen im Aufsetzen des Systems, den Tests und dem Betrieb vorhanden sind. Das technisch spezialisierte Personal stand in Luxemburg ebenfalls zur Verfügung und konnte die Einführung des Systems in den Filialen wesentlich unterstützen.
Komplexes Szenario für den Systemtest
Die serverseitigen Systemkomponenten der Applikation Avaloq wurden am Ort des Systembetreibers in Luxemburg installiert, die clientseitigen Systemkomponenten jeweils lokal in den ausländischen Niederlassungen. Für den Systemtest bedeutete das fünf geografische Bereiche mit jeweils unterschiedlichen Teilen der IT-Architektur, die für die Avaloq-Implementierung angepasst und getestet werden mussten (Abbildung 1).
Die Daten, die für die weitere Verarbeitung (aufsichtsrechtliches und internes Reporting) in den Filialen notwendig waren, wurden täglich über die von PPI entwickelte Applikation Travic Link aus dem Data Warehouse (DWH) des Systembetreibers an die lokalen DWHs der Niederlassungen übermittelt. Die Kommunikationssoftware Travic Link war bereits seit mehreren Jahren im Mutterunternehmen im Einsatz und bedurfte keiner aufwendigen Tests mehr. Gleichzeitig erhielten auch die zentralen Abteilungen in Deutschland die Daten aus den regionalen Einheiten über Avaloq für das Risikocontrolling und das Konzernberichtswesen.
Das Management des Projektes seitens des künftigen Betreibers, der ungeachtet der Konzernzugehörigkeit im Interesse der Klarheit und Transparenz der Prozesse als ein außenstehender Outsourcer zu behandeln war, blieb von der Projektleitung der Zentrale unabhängig.
Der Betreiber hatte die Verantwortung für die Implementierung des Systems, die Erweiterung der Funktionalität, der Erstellung der Export-Datenbasis und die Konzipierung und Durchführung der Anwenderschulungen.
Neben der Überwachung der Projektaktivitäten in der Bankzentrale umfasste die Projektleitung auch die generelle Abstimmung der Projektaktivitäten in den ausländischen Niederlassungen. Nichtsdestoweniger waren die Niederlassungen weitgehend unabhängig in der Bestimmung, Gestaltung und Implementierung der eigenen lokalen IT-Landschaften.
Umfassendes Testschema für alle beteiligten Standorte
Ausgehend von der vom Kunden vorgegeben und explizit erwünschten Standardmethodik der Bank, die drei traditionelle Teststufen (1. Modul- und Modulintegrationstest, 2. Systemtest- sowie 3. Abnahmetest) vorsieht, wurde ein umfassendes Testvorgehen für die fünf beteiligten Standorte entwickelt.
Die jeweiligen Modul und Modulintegrationstests wurden von den einzelnen Geschäftseinheiten in Eigenregie durchgeführt. Der erfolgreiche Abschluss dieser ersten Testphase war die Voraussetzung für den Eintritt in die zweite Testphase des Systemtests. Die Durchführung des System- und des sich daran anschließenden Abnahmetests wurde zentral koordiniert. So wurde der Schwerpunkt des Modultests in den Auslandsniederlassungen auf die neuen IT-Komponenten innerhalb der lokalen Teile der IT-Architektur gesetzt, die für die Nutzung des neuen Core-Banking-Systems die Voraussetzung darstellten. Es handelte sich dabei sowohl um neue DWH-Strukturen, Reporting Systeme als auch Schnittstellen zu den bereits bestehenden Systemen.
Während der Beginn der jeweiligen Modultests von den ausländischen Standorten selbst bestimmt wurde, war der Endtermin für den Modul- und Modulintegrationsphase für alle Einheiten vorgegeben, da er auch den Beginn der Systemtests darstellte. Die im Rahmen des System- und des Abnahmetests erzeugten Dokumente wurden revisionssicher im Tool Quality Center abgelegt. Die Verantwortung für diese beiden Teststufen lagen beim zentralen Testmanager der Projekte.
Wie bereits zuvor dargestellt, wurden die Phasen des Modulintegrationstests von den jeweiligen organisatorischen Einheiten im Ausland selbst koordiniert. Einzig die Deadline für den Abschluss dieser Teststufen wurde vom zentralen Testmanagement vorgegeben.
Der Systemtest wurde hingegen zentral gesteuert. In dieser Teststufe bedurfte die zyklische Testdurchführung weiterer Detaillierung. Dabei musste die Performance der Fehlerbearbeitung und potenzielle Nebeneffekte, die sich aus den Programmänderungen ergeben konnten, berücksichtigt werden. Es wurden pauschal drei Zyklen geplant, wobei im ersten Zyklus sämtliche vorgesehene Testfälle durchgetestet werden sollten.
Die fertig bearbeiteten Fehler resultierend aus Zyklus eins (insbesondere solche von hoher Priorität) sollten bereits im zweiten Zyklus erneut geprüft werden (Defect-Retest), wobei gleichzeitig ein Subset der ausgewählten Testfälle in einem Regressionstest die potenziellen Nebeneffekte identifizieren sollte.
Im dritten Zyklus wurden alle restlichen Programmänderungen aus Fehlern des ersten und zweiten Zyklus durchgetestet, mit dem Ziel, nur noch wenige Fehler mit niedriger Priorität mit in die Stufe der Abnahmetests zu übernehmen.
Organisation und zeitliche Planung eines Tests wichtig
Aufgrund des großen Testumfangs war eine weitere umfassende Strukturierung der Testinhalte notwendig. Es wurden zusammenhängende Testaktivitäten im System- und Abnahmetest zu sinnvollen und wesentlichen Test-Clustern gruppiert (siehe Abbildung 2) und geeignete Testkoordinatoren für ihre Betreuung identifiziert.
Um die gewünschte Transparenz der Tests abzubilden, war es erforderlich, die nationalen Eigenheiten der IT-Architektur (siehe das Beispiel der chinesischen Auslandsniederlassung in der Abbildung 4) im Test abzubilden. Die zeitlichen Abhängigkeiten innerhalb der einzelnen Test-Cluster aufgrund der separaten individuellen Implementierungspläne für relevante technische Komponenten mussten jedoch innerhalb der allgemeinen Vorgaben für alle Tests verstanden und berücksichtigt werden.
Verschiedene Konzepte nötig
Im ersten Schritt wurde ein Testrahmenkonzept (Overall Test Concept) erstellt, in welchem die generelle Teststrategie, die Vorgehensweise, die Testplanung sowie die Teststufen vorgestellt wurden. Auch die Abnahmekriterien für sogenannte Quality Gates innerhalb der System- und Abnahmetests wurden hier unter Beachtung der bankweiten Regelungen festgehalten.
Auf Basis des Testrahmenkonzeptes wurden detaillierte Testkonzepte für individuelle Test-Cluster erstellt. Folgende Testkonzepte sind dabei entstanden:
- Das Detailed Test Concept Migration beschrieb die Vorgehensweise beziehungsweise die Testobjekte für die Tests der aus Midas in Avaloq migrierten Daten.
- Das Detailed Test Concept Avaloq Functionality and new Requirements stellt die Testobjekte sowohl für die sogenannte Standardfunktionalität, die im System Avaloq durch Auslandsniederlassungen in Anspruch genommen wird, als auch für neue Anforderungen, die im Standardpaket nicht enthalten waren und durch extensive zusätzliche Programmierung umgesetzt werden mussten.
- Das Detailed Test Concept Headquarters Downstrem befasste sich mit der Überleitung der Daten aus Avaloq in die zentralen Bestands- und Controllingsysteme der Bank.
- Beim Detailed Test Concept ANL Downstream handelte es sich um drei detaillierte Testkonzepte der relevanten Niederlassungen, die in enger Abstimmung mit den lokalen Koordinatoren der Auslandsniederlassungen erstellt wurden.
Die im Rahmen der detaillierten Testkonzepte identifizierten Testobjekte lieferten eine Vorgabe für die Erstellung der notwendigen Testfälle. Angelehnt an die Struktur der Test-Cluster wurden folgende Testfallbereiche die für die Prüfung der gesamten Infrastruktur konzipiert.
- Migration: Testfälle für die Überprüfung der korrekten Überleitung der Daten aus des System Midas in die Applikation Avaloq.
- Infrastruktur: Testfälle für die technische Infrastruktur (neue Server) und den Datentransfermechanismus. Hier wurden logische - also noch unvollständige und nicht mit konkreten Testdaten hinterlegte - Testfälle erstellt, die in jeder geografischen Lokation entsprechend individuell und den dortigen Gegebenheiten Rechnung tragend angepasst wurden.
- Avaloq Standard Functionality: Um den Aufwand der Niederlassungen zu sparen, wurden diese Testfälle durch externe Berater in Abstimmung mit Fachpersonal des Outsourcers erstellt.
- Neue Anforderungen: Testfälle für die neu implementierte Anforderungen im neuen Core-Banking-System.
- Local IT: Testfälle für die Überprüfung der Anpassungen in den lokalen IT-Architekturen in jeder Niederlassung.
- Downstream Head Office: Testfälle für den Datentransfer in das Zentrale Data Warehouse des Mutterunternehmens und anschließende Verarbeitung in diversen zentralen Banksystemen.
- Nichtfunktionale Testfälle: Die Beschreibung der Testfälle innerhalb der Core-Banking-Infrastruktur übernahm der Outsourcer, während Niederlassungen die nichtfunktionalen Testfälle für lokale IT in Eigenregie erstellten.
Komplexe Testfallerstellung
Die Erstellung der Testfälle für den Bereich Avaloq Standard Functionality stellte eine besondere Herausforderung dar und erwies sich als sehr ressourcenintensiv. Schwierig erwies sich die Umsetzung der Anforderung, das bereits bestehende Testfallportfolio der Luxemburger Einheit wiederzuverwenden. Andererseits mussten die Testfallbeschreibungen in englischer Sprache verfasst werden, welches für die ausländischen Einheiten Voraussetzung für die Teilnahme an den Tests war. Dafür wurden mithilfe der externen Beratung produktbezogene Excel-Templates erstellt, welche eine weitgehende Klarheit und Transparenz der Testfallbeschreibungen, der dafür notwendigen Voraussetzungen und der erwarteten Testergebnisse sichergestellt haben.
Die Testfallerstellung beinhaltete die Ersterstellung der Testfälle, die dann durch die Auslandsniederlassungen geprüft wurden; fehlende Testfälle wurden identifiziert und geschrieben, bestehende Testfälle wurden gegebenenfalls verbessert/geändert und anschließend in das Test Management Tool geladen.
Die Aufgabe der Testdatenbeschaffung wurde dadurch gelöst, dass der Test-Stream "Migration" allen anderen Test-Streams vorangestellt wurde. Die Übernahme der Daten aus dem Midas-System in die Applikation Avaloq wurde der erste Testbereich im Rahmen der fachlichen Systemtests. Anschließend standen für die funktionellen Tests geprüfte und qualitativ nachgebesserte statische und dynamische Testdaten in ausreichender Qualität zur Verfügung.
Mitarbeiter müssen geschult werden
Mit Ausnahme des Systembetreibers nutzen alle Einheiten das Testmanagementtool Quality Center zur Dokumentation der durchgeführten Tests im System- und Abnahmetest. Die Verzeichnisstruktur im Test Plan sowie im Test Lab wurde anhand einer Analyse der notwendigen Testbereiche ermittelt. Der Betreiber des Systems selbst verfügte über ein eigenes Testsystem IET, dessen Workflows bis in die Entwicklung hineinreichten.
Das Defektmanagement im Systemtest und Abnahmetest erfolgte für alle Test-Cluster ebenfalls zentral im Quality Center, wobei die Avaloq-relevanten Defekte über einen Share Point an das Testsystem des Systembetreibers weitergeleitet wurden. Das Defecttracking in der lokalen IT der Auslandsniederlassungen und in der Lieferstrecke der Zentrale erfolgte direkt im Quality Center.
Die Mitarbeiter wurden in drei Test & Training Sessions, die durch das Test Management in der Betreibereinheit konzipiert wurden, geschult. Aus der Planung ging detailliert hervor, welche Mitarbeiter aus welchen Niederlassungen an welchen Maßnahmen beteiligt waren.
In Abhängigkeit von den Prioritäten der Testfälle und der Defects war die Testabnahme an drei wesentliche Voraussetzungen geknüpft.
- Alle Testfälle mit Prio 1 und 2 mussten ausgeführt sein.
- Es durften keine offenen Prio-1- und - 2- Defekte vorhanden sein.
- Offene Defekte mit der Prio 3 bis 5 waren nicht abnahmeverhindernd für den Systemtest.
Für die Entscheidung über eine Testabnahme war die Tabelle (Abbildung 6) mit relevanten Kombinationen der Prioritäten der Testfälle und Defects hilfreich.
Im Rahmen der nach Projektabschluss durchgeführten Testanalyse wurden zwei wesentliche Problemfelder erkannt.
Die Niederlassungen hatten weitgehende Freiheit, die lokale IT-Landschaft selbst zu bestimmen. Dies führte einerseits zu periodischen Anpassungen des Testplans, andererseits führte es zu einem höheren Grad an lokaler Systemheterogenität.
Ausgehend von der Rolle der Geschäftseinheit, die das Betreiben des Systems übernommen hat, wurde anfänglich eine Testmethodik aufgebaut, die keinen Unterschied zwischen den Rollen des "Kunden" und des "Outsourcers" vorgesehen hat. Dies musste im Lauf der Zeit allerdings entsprechend angepasst werden. So kam es zu einer grundsätzlichen klaren Unterteilung der Verantwortung für die Teststufen: Die Tests des Systembetreibers wurden grundsätzlich als Modul- und Modulintegrationstests betrachtet, während die System- und Abnahmetests in der Verantwortung des "Kunden", das heißt der Auslandsniederlassungen und der Zentrale blieben.
Globale Systeme brauchen neue Ansätze für Tests
Die Planung der Testressourcen in den einzelnen Niederlassungen war keine Aufgabe des zentralen Test Management, sondern eine Aufgabe, die in den Niederlassungen in Eigenregie durchgeführt werden musste. Die Planung der Ressourcen in der Luxemburger Tochter erfolgte ebenfalls vollständig unabhängig vom Test Management, da diese wirtschaftlich und organisatorisch unabhängig vom Mutterunternehmen agiert. Spezialisierte Ressourcen in der Bankzentrale waren stark reglementiert und ihre Verfügbarkeit war zeitlich sehr begrenzt - die Zuordnung der Testaufgaben musste in enger Abstimmung mit den jeweiligen Application Managern erfolgen.
Vor dem Hintergrund der wachsenden Bedeutung des Internationalen Banking benötigen Finanzinstitute neue Ansätze für Tests der global einzusetzenden Systeme. Die Testmethodik muss in der Lage sein, diverse Projektansätze, heterogene Systemlandschaften, unterschiedliche Modi des Systembetriebes, inkonsistente Datenstrukturen und -qualität, aber auch interkulturelle Erwartungen und sprachlich erschwerte Kommunikation zu berücksichtigen.
Der vorliegende Artikel weist auf mehrere pragmatische Aspekte eines internationalen Testprojektes einer Bank eines funktionell umfangreichen Systems hin, die organisatorisch und methodisch gelöst werden müssen, um zu einem gelungenen Testabschluss und -abnahme zu gelangen.
