Das Testmanagement von SAP-Anwendungen wie 'SAP for Banking' sollte von Anwenderunternehmen nicht unterschätzt werden. Vernachlässigen die Verantwortlichen in den Unternehmen das Thema, können die damit verbundenen Konsequenzen durchaus gravierend sein. Um die Herausforderungen zu meistern, bietet sich die Methodik des Risk-based Testing als Lösung für Banken an.

Die aktuellen Herausforderungen im Testmanagement

Zu den aktuellen Herausforderungen im Test-Management zählen vor allem die verschärften regulatorischen Anforderungen. Die Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) fordert eine regelmäßige Bewertung der Kritikalität von Prozessen sowie die Erfüllung der Mindestanforderungen an das Risikomanagement nach MaRisk AT 7.2 (technisch-organisatorische Ausstattung). Dazu zählt die Besetzung des Testmanagements durch eine unabhängige Stelle sowie die Vorschrift, dass wesentliche Veränderungen zu testen sind. Diese Vorschriften stehen nicht nur auf dem Papier. Die BaFin kommt auch ins Haus und prüft. Verstöße können zu negativen Sanktionen führen, bis hin zur Verpflichtung, das Eigenkapital zu erhöhen.

Neben den regulatorischen Anforderungen muss das Testmanagement bedingt durch Marktveränderungen schnell auf kurze Entwicklungszyklen reagieren. Parallel dazu wird die Test- und Betriebsumgebung durch Portale, Services, zahlreiche Schnittstellen und hohe Sicherheitsanforderungen im Internet zunehmend komplexer und das Testfenster kleiner. Darüber hinaus erfordern Releasewechsel von SAP-Anwendungen (Beispiel SEPA) oft einen Regressionstest über alle Prozesse.

Konsequenzen für das Testmanagement

Die Auswirkungen dieser veränderten Rahmenbedingungen sind hohe Testkosten, verursacht durch komplexe Testumgebungen, den erhöhten Einsatz von internen Mitarbeiten oder auch durch die Substituierung von internen Testern durch externe Ressourcen. Ignoriert man die neuen Anforderungen, müssen Unternehmen in der Konsequenz eine nicht oder nicht ausreichend getestete Software in Kauf nehmen. Im ungünstigsten Fall führt die mangelnde Qualität der auszurollenden Programme zu negativen Außenwirkungen auf die Geschäftsprozesse der Bank.

Erfahrungen aus der Praxis zeigen, dass oft viel, aber nicht immer das Richtige getestet wird. Zwei typische Beispiele:

• Im Rahmen eines Releasewechsel-Regressionstests wird auch die Druckstraße getestet, obwohl sich an der Schnittstelle nichts geändert hat. Folge: Die Bereitstellung der Infrastruktur verzögert sich. Die Gesamtabnahme des Tests ist gefährdet.

• Oder: Für den Test der Prolongation von Hypothekendarlehen gibt es zwölf Varianten, alle mit der Priorität 'sehr hoch' gewichtet. Kurz vor Testende zeigt sich, dass nur zwei Varianten getestet werden konnten und die übrige Zeit für die Durchführung der verbleibenden Testfälle nicht ausreicht.

Und genau hier setzt die Methodik Risk-based Testing an. Im Folgenden werden die Erfahrungen mit dem risikobasierten Testansatz beschrieben.

Die Methodik Risk-based Testing am Beispiel 'Darlehensverwaltung'

Das grundsätzliche Vorgehen ist immer gleich. Zuerst wird, wie auch von der BaFin vorgeschrieben, regelmäßig, zum Beispiel jährlich, die Kritikalität der Prozesse ermittelt. Im Beispiel unten werden im ersten Schritt die relevanten Bewertungskriterien wie Außenwirkung auf den Kunden, Auswirkungen auf den Prozess, Aufrufhäufigkeit und Sicherheitsrelevanz erfasst und gewichtet. Danach erfolgt pro Prozess die Bewertung. Das heißt: Wie kritisch ist das Eintreffen von Fehlfunktionen für das jeweilige Kriterium. Im Beispiel hat ein Fehler in der 'Vertragsanlage' eine sehr hohe Außenwirkung auf den Kunden und eine sehr hohe Auswirkung auf die Ausführung des Prozesses 'Vertragsanlage'. Die Aufrufhäufigkeit ist als 'sehr hoch' und die Sicherheitsrelevanz als 'hoch' zu beurteilen. Daraus ergibt sich für den Prozess 'Vertragsanlage' eine gewichtete Kritikalität von 'sehr hoch'.

Unabhängig von der Bewertung der Kritikalität werden im zweiten Schritt pro Projekt die Änderungen an der Software für den jeweiligen Prozess beurteilt. Kriterien für Projekte rund um SAP-Anwendungen sind zum Beispiel:

• funktionale Veränderungen (Anpassungen oder Erweiterungen),

• Änderungen in den Datenstrukturen (z.B. neue oder geänderte Felder),

• Änderungen im Customizing.

Im Beispiel werden für den Prozess 'Vertragsanlage' sehr hohe funktionale Anpassungen und mittelgroße Änderungen in den Datenstrukturen und im Customizing festgestellt. Daraus ergibt sich eine gewichtete Bewertung der Veränderungen durch das Projekt von 'hoch'.

Im letzten Schritt wird die Priorität beziehungsweise der Umfang der Testfälle aus der Kritikalität des Prozesses und der Bewertung der Veränderungen durch das Projekt ermittelt. Im vorliegenden Fall ergibt sich für die 'Partnerverwaltung' eine Priorität 'mittel'. Dieser Wert ist als Rahmen oder Leitplanke für die Priorisierung und den Umfang der Testfälle zu betrachten, aber keine absolute Vorgabe. Diese Bewertung erfolgt in einem Workshop mit der Projektleitung sowie Stakeholdern aus den Fachabteilungen und dem Testmanagement. Die Fachbereiche erstellen im Anschluss auf Basis der Priorität die Testfälle.

Optional können noch Prioritäten für Testarten festgelegt werden. Im genannten Beispiel benötigt der Prozess 'Partnerverwaltung' keine Last- und Performancetests und für Regressionstests gilt wegen der Software-Kapselung eine geringe Priorität.

Erfahrungen aus der Praxis

Risk-based Testing in der Praxis zu etablieren, ist kein Selbstläufer, sondern eher ein zäher Prozess. Widerstände resultieren meist insbesondere aus Zeitmangel oder aus Unkenntnis der Methodik. Der Schlüssel zum Erfolg lautet daher: viel Überzeugungsarbeit mit den Stakeholdern und ein gut vorbereiteter Bewertungs-Workshop.

Der oben skizzierte dreistufige Ansatz wird eher selten verfolgt. Hauptgrund sind nicht vorhandene Prozessmodelle oder zu grobe Prozesse. Auch ist das Testmanagement hier oft nicht der Treiber des Verfahrens. Häufiger wird mit der Bewertung des Projekts gestartet und daraus die Priorität der Testfälle oder auch von Testobjekten abgeleitet. Insbesondere bei Neuentwicklungen ist das Reduktionspotenzial für die Tests eher gering. Aber in jedem Fall lassen sich durch die Priorisierung Reihenfolgen für die Tests festlegen. Ist die Zeit knapp, entfallen die Testfälle mit geringer Priorität. Äußerst lohnend ist der Einsatz von Risk-based Testing bei der Planung von Regressionstests zum Beispiel beim Releasewechsel. Es werden nicht, wie häufig üblich, alle Funktionen oder auch Infrastrukturkomponenten blind durchgetestet, sondern der Fokus der Tests liegt auf den wirklich wichtigen Features beziehungsweise auf den Software-Änderungen.

Als Einstieg in die Methodik eignet sich durchaus auch der Start mit Schritt 3. Ein erfolgreicher Ansatz ist - auf Basis einer Testfallmatrix mit primären Testfällen und Varianten (zum Beispiel Produktarten) - zusammen mit den Fachbereichen eine Priorisierung zu erarbeiten. Warum sollen die Varianten C, D und E noch intensiv getestet werden, wenn A und B einwandfrei funktionieren?

Fazit

Es lohnt sich immer, unabhängig von der gewählten Variante, in das Thema Risk-based Testing einzusteigen. Am Anfang gilt es jedoch, Überzeugungs- und methodische Arbeit in die Implementierung zu investieren. Aber: Allein schon der Bewertungs-Workshop mit der Projektleitung, den Fachbereichen und dem Testmanagement bringt eine einheitliche Sicht auf die Testschwerpunkte. Im Idealfall lassen sich durch den Fokus auf die wirklich wichtigen Tests die Testkosten reduzieren und die Software-Qualität verbessern. Als Nebeneffekt erfüllt das Vorgehen die Anforderung der BaFin hinsichtlich regelmäßiger Bewertung der Kritikalität von Prozessen.