Wer mit komplexen IT-Systemen arbeitet, kennt den Spruch "never touch a running system!" Sinngemäß meint dies, dass komplexe Computerprogramme, die einmal zur Anwendung gekommen sind und reibungslos funktionieren, besser in Ruhe gelassen werden, bevor sich durch eine Veränderung Fehler an unvorhergesehenen Stellen einschleichen. Dieses Risiko erweist sich bei Clearing-Systemen als besonders hoch, die beispielsweise dann zum Einsatz kommen, wenn der Kunde eines Kreditinstituts mit seiner Bankkarte an einem japanischen Geldautomaten Geld abhebt, in einem US-amerikanischen Supermarkt bezahlt oder seine Rechnung in einem Mailänder Restaurant begleicht. In allen Fällen muss der Betrag vom Konto des Kunden auf das Konto des Händlers beziehungsweise dessen Bank überwiesen werden. Diverse Gebühren müssen zudem ihren Weg zu den beteiligten Dienstleistern finden. Das Clearing-System übernimmt all diese Abrechnungsfunktionen - und zwar in Sekundenschnelle. Dabei ermöglicht es eine Anbindung von Mastercard, USA und der Euro Alliance of Payment Schemes (EAPS). Nachdem der Prozess entwickelt, im Pilotbetrieb getestet und schließlich endgültig in Betrieb genommen wurde, rührt man es also besser nicht mehr an - getreu der eingangs erwähnten Devise.
Often touch the clearing-system
Allein, so einfach ist es nicht. Eine Vielzahl von Faktoren erzwingen bei Clearing-Systemen geradezu stete Veränderungsprozesse.
So schreibt etwa die Vereinheitlichung des europäischen Zahlungsverkehrs unter dem Stichwort Sepa (Single Euro Payments Area) vor, dass bis Mitte 2014 das aktuelle DTA-Format im Zahlungsverkehr durch xml-basierte Sepa-Formate abgelöst werden muss. Für die Clearing-Systeme stehen deshalb wichtige Erweiterungen an.
Auch verschiedene Transaktionen erfordern diverse Anpassungen, zum Beispiel bei sogenannten Berlin-Group-Transaktionen (Transaktionen zwischen nationalen europäischen Zahlungssystemen), V-Pay-Transaktionen (Visa) oder Maestro-Transaktionen (Mastercard).
Gleichzeitig gilt es, individuelle Wünsche einzelner Banken zu berücksichtigen, denn vor allem bei der Gebührenabrechnung werden höchst unterschiedliche Ansätze verfolgt: Manche Institute ziehen es vor, die Gebühren zunächst über Konten des Clearing-Dienstleisters abzurechnen, um später kumulativ zu verrechnen. Andere Banken bevorzugen die Verwendung eigener Abrechnungskonten, die mitunter individuelle Besonderheiten aufweisen.
In der Folge entstehen immer wieder Anpassungserfordernisse am Clearing-System. Schließlich ist auch das Thema Sicherheit eine kontinuierliche Quelle für Veränderungen. Die Sicherheitsanforderungen der Payment Card Industry (PCI) zielen vorrangig darauf ab, den Missbrauch von Kartendaten zu unterbinden. Hierzu existieren umfangreiche Sicherheitsanforderungen, die von den beteiligten Verarbeitungssystemen umzusetzen und einzuhalten sind. Dabei wird aber nicht nur das Clearing-System selbst, zum Beispiel das Betriebssystem oder der zugrunde liegende Web-Server, in die Sicherheitsbetrachtung einbezogen. Sofern hier für das Clearing-System relevante Sicherheitslücken bekannt werden, müssen entsprechende Sicherheits-Patches eingespielt werden.
Aus der Devise "never touch a running system!" wird damit der Leitspruch "often touch the clearing system!". Dies impliziert allerdings eine grundlegend andere Herausforderung, vor der alle Systeme stehen, die häufigen Änderungen unterworfen sind: Wie kann sichergestellt werden, dass sich durch Änderungen am System oder an der Einsatzumgebung (zum Beispiel neue Sicherheits-Patches) keine Fehler einschleichen?
Regressionstests auf Knopfdruck
Das Zauberwort in diesem Zusammenhang heißt "automatisierte Regressionstests". Dabei handelt es sich um Testverfahren, die erneut ausgeführt werden, nachdem ein Computerprogramm oder dessen Einsatzumgebung modifiziert wurden. Sie sollen überprüfen, ob sich durch die Veränderungen Fehler in den schon vorhandenen Funktionen eingeschlichen haben. Die von Clearing-System zu verarbeitenden Geschäftsvorfälle sind jedoch äußerst vielfältig: Transaktionen werden eingereicht (First Presentment), können zurückgewiesen (Charge Back) und erneut eingereicht werden (Second Presentment). Darüber hinaus müssen unterschiedliche Transaktionsarten, zum Beispiel Geldautomat oder PoS, gegebenenfalls mit einer Baraus zahlung - auch Cashback genannt - verarbeitet werden. Diverse Gebühren an Geldautomaten sind ebenfalls zu berücksich tigen. Häufig ist das Abheben von Bargeld an einem institutseigenen Automaten oder an einem Automaten innerhalb einer Verbundgruppe für den Kunden kostenfrei, an anderen Automaten allerdings nicht. Zudem gelten für diverse Geldautomaten mitunter unterschiedliche Gebühren - je nachdem, ob die Automaten in Euro oder in einer anderen Währung betrieben werden.
All diese Möglichkeiten müssen in einem flexibel realisierten Clearing-System konfigurierbar sein. Eine manuelle Prüfung beziehungsweise ein manueller Regressionstest ist in der Regel aus zeitlichen Gründen kaum möglich. Bei vollständig automatisierten Regressionstests lassen sich alle Tests ohne zeitraubende Vorbereitungen auf Knopfdruck ausführen. Zur Realisierung dieses Verfahrens hat die Bank-Verlag GmbH zusammen mit der SRC Security Research & Consulting GmbH, die eine eigene Abteilung für Test und Qualitätssicherung unterhält, ein separates Testsystem entwickelt, damit Regressionstests störungsfrei und unabhängig vom Echtbetrieb ausgeführt werden können.
Vierstufiges Vorgehen
Das Vorgehen zum Testen gliedert sich in vier Stufen: In der ersten werden auf relativ abstraktem Niveau der Testumfang und die Testabdeckung definiert. In diesem Status ist die Frage zu beantworten, welche Funktionalitäten in welcher Intensität getestet werden sollen. Hierdurch wird der Testumfang in einer Prüfvorschrift übersichtlich und nachvollziehbar dokumentiert. Im zweiten Schritt wird die Testspezifikation erstellt. Aus der Prüfvorschrift werden Testfälle abgeleitet. Trotz der Fülle an Daten, die ein Clearing-System verarbeitet, müssen die Testfälle übersichtlich gestaltet werden. Dadurch wird es möglich, sich in einem Testfall auf die wesentlichen Testinhalte zu konzentrieren. Im dritten Schritt werden die Testskripte erstellt.
Das in diesem Kontext zum Einsatz gebrachte Test-Tool (Scala) kann alle erforderlichen Transaktionsdaten in den entsprechenden Formaten sowohl erzeugen als auch auf Korrektheit prüfen. Beim Test des Clearing-Systems wird das IPM-Format von Mastercard und das Base-II-Format von Visa, das DTA-Format in seinen teilweise sehr unterschiedlichen Ausprägungen, das MT-940 Format sowie diverse andere Formate unterstützt, um Autorisierungsinformationen oder spezifische Nachrichten, zum Beispiel von Mastercard oder Visa, verarbeiten zu können. Zukünftig sollen auch die xml-basierten Sepa-Formate gemäß ISO-Standard 20022 unterstützt werden. Zusätzlich müssen im Testablauf über die Oberfläche des Clearing-Systems spezielle Konfigurationen eingestellt werden. Dies ist etwa dann erforderlich, wenn bestimmte Gebührenkonstellationen zu testen sind. Insgesamt erlaubt das Test-Tool einen vollständig automatisierten Testablauf beginnend mit der Einstellung von Parametern über die Benutzeroberfläche über das Erzeugen diverser Transaktionsdateien für das Clearing-System bis hin zur Entgegennahme und Prüfung von Transaktionsdateien, die das Clearing-System erstellt hat.
Der vierte Schritt nach der Erstellung der Testskripte ist die Testdurchführung. Die Tests werden ausgewählt und angestoßen. Alles weitere erfolgt automatisch. Insbesondere protokolliert die Anwendung alle durchgeführten Schritte und erleichtert so die Analyse im Fehlerfall. Ein erzeugter Report zeigt auf, welche Tests mit welchen Ergebnissen ausgeführt wurden. Darüber hinaus können in den Testskripten Daten vereinbart werden, die anschließend im Report angezeigt werden sollen.
Testmethodik auch bei Kartenproduktion anwendbar
Das gewählte Verfahren erfüllt die strengen Anforderungen der Revision: In der Prüfvorschrift ist der Testumfang festgelegt. Der Revisor kann sich davon überzeugen, dass die Testabdeckung angemessen ist. In der Testspezifikation sind alle Testfälle beschrieben. Der Revisor kann außerdem überprüfen, ob die Prüfvorschrift korrekt in Testfälle abgebildet wurde. Zu jedem Testfall gehört ein Testskript. Zu jedem Testdurchlauf liegen ein Report und entsprechende Protokolldateien vor. Damit wird auch die Testdurchführung übersichtlich und nachvollziehbar dokumentiert.
Die am Beispiel des Clearing-Systems geschilderte Testmethodik kann auch zum Test anderer Systeme eingesetzt werden, zum Beispiel (wie im Falle des Bank-Verlags) bei einer E-Banking-Plattform oder für Systeme der Kartenproduktion. Damit lassen sich selbst bei kurzfristigen Änderungen die erforderlichen Tests schnell und umfassend durchführen. Im Bedarfsfall müssen spezialisierte Schnittstellen eingerichtet werden, beispielsweise zu Chipkarten, um automatisiert eine TAN von der Chipkarte zu beziehen oder um Transaktionsdaten direkt von einer Testkarte berechnen zu lassen. Durch die Verwendung ein- und desselben Test-Tools für den Test unterschiedlicher Systeme entstehen signifikante Synergieeffekte. So können sich die Mitarbeiter über die verschiedenen Systeme hinweg über die Verwendung des Test-Tools austauschen. Von Erweiterungen der Anwendung, zum Beispiel hinsichtlich der Benutzerführung oder der Gestaltung von Reports, profitieren alle Beteiligten. Die Akzeptanz der systematischen Verwendung des Test-Tools wird damit erhöht und eine Vereinheitlichung der Prozesse bei allen angewandten Testmethoden steigert die Effizienz der Testerstellung.