Praxis-Tipps am Beispiel Banken

Pragmatischer Umgang mit dem Testmanagement in der Banken-IT

Dieter Koenen, Manager Consulting Services bei der innobis AG, leitet seit über zehn Jahren große Testmanagement-Vorhaben im Umfeld von SAP-Anwendungen bei Banken. Er ist Experte für die Entwicklung und Praxiseinführung von Methoden und Verfahren in diesem Kontext.
Banken müssen in der IT eine Vielzahl regulatorischer Vorgaben beachten und umsetzen. Nicht selten schießen sie dabei über das Ziel hinaus. Wichtig ist es, auch im Testmanagement einen angemessenen Umsetzungspfad zu finden.

Seit Veröffentlichung des Rundschreibens „10/2012 (BA) – Mindestanforderungen an das Risikomanagement MaRisk“ sowie den Erläuterungen in 12/2012 durch die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) gibt es in der IT von Banken eine Vielzahl von umzusetzenden Maßnahmen, um insbesondere die Anforderungen aus AT 7.2 und AT 7.3 zu erfüllen. Angekündigte Sonderprüfungen nach § 44 KWG Absatz 1 (Kreditwesengesetz) fordern gleichermaßen Business- und IT-Verantwortliche heraus. Zahlreiche Formalismen und administrative Hürden sind zusätzlich zur hohen Belastung im Tagesgeschäft zu bewältigen. Natürlich sind die regulatorischen Vorgaben zu erfüllen, aber nicht selten schießen die Maßnahmen auch übers Ziel hinaus. Wichtig ist es, einen angemessenen Umsetzungspfad zu finden. Das Testmanagement bildet dabei die zentrale Klammer zwischen Fachbereich, Entwicklung und Betrieb.

Banken haben im IT-Betrieb zahlreiche regulatorische Vorgaben zu beachten, sollten bei deren Umsetzung aber auch nicht über das Ziel hinausschießen.
Banken haben im IT-Betrieb zahlreiche regulatorische Vorgaben zu beachten, sollten bei deren Umsetzung aber auch nicht über das Ziel hinausschießen.
Foto: ramcreations - shutterstock.com

Tipps aus Sicht des Testmanagements

Im Test vorgeschriebene Maßnahmen führen zu erheblichen Seiteneffekten in den oben benannten Bereichen. Nachstehend werden pragmatische und praxiserprobte Ansätze entlang des Software-Entwicklungsprozesses skizziert, mit denen sich die regulatorischen Anforderungen aus Sicht des Testmanagements erfüllen lassen. Anhand einer Checkliste (siehe unten) kann verifiziert werden, welche Komponenten noch zu implementieren sind.

Konzeption

Neue oder modifizierte Software muss getestet werden. Die fachliche Ausprägung der Testfälle unmittelbar vor der Testphase durch die Fachbereiche gestaltet sich oft als zäher Prozess. Viel besser ist es, in der Konzeptionsphase für jedes formulierte Requirement auch eine Beschreibung des Testszenarios einzufordern.

Das Thema Rollen und Berechtigungen wird üblicherweise eher stiefmütterlich behandelt. Auch hier sollte die IT schon in der Konzeptionsphase auf die korrekte und vollständige Definition, auf Funktionstrennung sowie auf die Formulierung entsprechender Testszenarien drängen.

Entwicklung

Aktuelle und möglichst schlank gehaltene Entwicklungsrichtlinien mit Namenskonventionen, Richtlinien für den Umgang mit kritischen Programmiertechniken sowie Hinweisen für optimierten Programm-Code sind inzwischen ein Muss.

Weiterhin empfiehlt sich ein integriertes Auftrags- und Transportverwaltungssystem. Für SAP-Anwender bietet sich hier die Komponente SAP Change Request Management (ChaRM) des Solution Managers mit dedizierten Genehmigungsverfahren, strikten Rollentrennungen sowie dem revisionssicheren Nachweis der Transportkette von Entwicklungs- über Test- und Abnahmesysteme bis hin zur Produktion an.

Nicht viele Entwicklungsbereiche nehmen sich die Zeit für Code-Reviews nach dem Vier-Augen-Prinzip. Auch hier gibt es inzwischen gute Werkzeuge auf dem Markt, welche Programm-Code unter anderem auf sicherheitsrelevante Schwachstellen überprüfen und bei Regelverletzungen den Transport in Qualitätssicherungs- oder Produktivsysteme verhindern. Im SAP-Umfeld gelten der Code Profiler von Virtual Forge sowie der SAP Code Vulnerability Scanner als führend.

Eingangsvoraussetzung für den Fachtest sind dokumentierte Modultests durch die Entwicklung sowie die Benennung von Testeinschränkungen wie noch nicht fertiggestellte Funktionen oder bereits bekannte Fehler. Auch hier bieten sich unterstützende Werkzeuge an. Die ChaRM-Komponente des SAP Solution Managers ermöglicht beispielsweise die Dokumentation und den Nachweis von Modultests.

Testmanagement

Als allererstes empfiehlt es sich, die Testmanagement-Prozesse und die Rollen in den Test- und Abnahmeprozessen eindeutig zu definieren sowie Templates zum Beispiel für Testkonzepte oder Testfallbeschreibungen zur Verfügung zu stellen. Auch hier gilt der Grundsatz: „Weniger ist mehr“. Lange Prosa-Passagen werden nicht gelesen. Besser sind Checklisten, Tabellen und Grafiken. Übrigens ist die strikte Rollentrennung zwischen Fachbereich, Entwicklung und Test wichtig, um die regulatorischen Vorgaben zu erfüllen.

Excel-basierte Testmanagement-Verfahren haben sich überholt. Tests und Abweichungen sind nachvollziehbar und revisionssicher zu dokumentieren und aufzubewahren. Der Einsatz von integrierten Testmanagement-Tools wie das HP Application Lifecycle Management (HP ALM) Quality Center, IBM Rational Quality Manager oder die SAP Solution Manager Test Workbench ist obligatorisch.

Aus Sicherheitsgründen dürfen in nicht zentral gemanagten Testumgebungen keine sensiblen (insbesondere keine personenbezogenen) Daten verwendet werden. So sind beispielsweise Geschäftspartnerdaten zu anonymisieren. Für den Zugriff auf Testdaten durch Tester (und gegebenenfalls durch Entwickler für Fehleranalysen) ist ein Prozess zu definieren. Die Vergabe von User-IDs und Berechtigungen ist zu protokollieren.

Stark an Bedeutung gewinnt das Risikomanagement. So muss die Bank auch nachweisen, dass Testrisiken wie die zu späte Bereitstellung der zu testenden Software oder eine fehlende Testinfrastruktur aufgenommen und bewertet sowie entsprechende Mitigationsmaßnahmen durchgeführt und verfolgt werden.

Bewährt hat sich der risikobasierte Testansatz. Prozesse werden in diesem Verfahren nach Kritikalität wie Aufrufhäufigkeit oder Sicherheitsanforderungen sowie hinsichtlich Änderungen und Anpassungen im laufenden Testvorhaben bewertet (siehe Schaubild „Die Methodik Risk-based Testing beim Testmanagement“).

Risk-based Testing im Überblick: Herausforderungen, Methodik, Ergebnisse
Risk-based Testing im Überblick: Herausforderungen, Methodik, Ergebnisse
Foto: innobis AG

Daraus leiten sich der Umfang und die Priorität der involvierten Testobjekte beziehungsweise Testfälle ab. Der Fokus verschiebt sich damit risikogetrieben auf die wirklich wichtigen Tests.

In der Verantwortung des Testmanagements liegt der Nachweis, dass Pflichtergebnistypen wie ein Testkonzept oder eine Testplanung erstellt, obligatorische Tests wie Security- oder Disaster-Recovery-Tests durchgeführt (beziehungsweise die Nichtausführung begründet) oder der Abnahmeprozess ordnungsgemäß durchlaufen wurden. Hier bietet sich ein Checklisten-gestütztes Internes Kontrollsystem (IKS) an.