Banking-IT: Warum Resilienz wichtiger ist als Fehlerfreiheit

Rechenzentren sind keine sterilen Labore, sondern Krisengebiete. Während der Kunde auf seinem Smartphone eine saubere Oberfläche sieht, herrscht im Backend ein ständiger Kampf gegen Entropie, Latenzen und Schnittstellen-Chaos.

Die Wahrheit ist: Hinter jeder geglückten Überweisung steht kein „perfektes“ System. Es steht eine Architektur dahinter, die gerade so davon abgehalten wird, zu kollabieren. Funktionales Testing im Banking, wie in anderen Branchen mit komplexer IT, dient daher selten dazu, Fehlerfreiheit zu simulieren. Sein einziger Zweck ist es, das unvermeidliche Scheitern von Komponenten so zu managen, dass die Kundenerfahrung nicht beeinflusst und Regularien eingehalten werden.

Abschied vom „Happy Path“: Chaos ist der Default-Zustand

Die Vorstellung, Banksoftware dürfe „nie“ Fehler haben, ist gefährlich. Hardware fällt aus, API-Partner haben Timeouts, Systeme von Zulieferern stocken, Deployments schlagen fehl. Das ist kein Unfall, das ist Statistik.

Aktuell testen wir daher nicht nur den Schönwetter-Fall („Happy Path“), sondern die Resilienz:

• Graceful Degradation: Fällt die Echtzeit-Bonitätsprüfung aus, darf der Kreditantrag nicht fehlschlagen. Das System muss in einen sicheren Wartezustand wechseln.
• Idempotenz: Sendet eine App wegen schlechtem Netz die Überweisung dreimal, darf das Kernbankensystem nur einmal buchen. Es muss erkennen: „Diese Nachricht kenne ich schon.“
• Traceability (Logs): Der letzte Layer ist der prüfende Mitarbeiter. Wenn die Automatisierung an ihre Grenzen stößt oder ein Kunde reklamiert, muss der Support den Fall rekonstruieren können. Wir testen daher, ob Logs nicht nur technisches Rauschen speichern, sondern eine für Menschen lesbare „Geschichte“ der Transaktion erzählen, damit das Backoffice handlungsfähig bleibt.

Ohne diese Mechanismen bewirken technische Trivialitäten Chaos.

Die Realität: Hybrid-Architektur im Spannungsfeld von Alt und Neu

Moderne Banking-IT ist kein monolithischer Block mehr, sondern ein hochkomplexes Geflecht: COBOL-Mainframes bilden das Fundament, Cloud-Dienste die Infrastruktur und React-Frontends die Schnittstelle zum Kunden.

In dieser hybriden Architektur – oft noch verschärft durch die Koordination global verteilter Teams (Offshore/Nearshore) und laufende Cloud-Migrationen – ist Qualitätssicherung keine reine Technik-Frage mehr. Sie wird zum strategischen Risikomanagement. Drei Beispiele, warum das Zusammenspiel kritisch ist:

• Der Dolmetscher-Effekt (Legacy Integration): Moderne Apps kommunizieren via JSON/REST, während im Backend Mainframes in EBCDIC rechnen. Funktionale Tests sind hier der einzige verlässliche Dolmetscher. Ein Konvertierungsfehler an dieser Schnittstelle – ohne strikte Plausibilitätsprüfung – und aus 100,00 € werden schnell 1,00 € oder 10.000,00 €.
• Der regulatorische Zwang (DORA): Mit dem Digital Operational Resilience Act ist Systemstabilität Gesetz. Banken müssen nachweisen, dass sie nicht nur ihre eigene Software, sondern auch die Risiken ihrer ICT-Drittanbieter (Cloud, SaaS) im Griff haben. Wer hier nicht testet, riskiert nicht mehr nur Bugs, sondern empfindliche Bußgelder.
• Der Echtzeit-Stress (Instant Payments): Die Welt wartet nicht mehr auf den nächtlichen Batch-Lauf. Kunden fordern Transaktionen in Sekunden. Das zwingt Systeme, die für „Bürozeiten“ konzipiert wurden, in einen 24/7-Betrieb. Funktionale Tests müssen hier beweisen, dass parallele Zugriffe (Race Conditions) nicht zu Dateninkonsistenzen führen - eine Komplexität, die rein manuelle Tests faktisch unmöglich macht.

Risikobasiertes Testen als Konsequenz aus der Qualitätspyramide.

Risk-Based Testing: Mut zur Lücke

Alles zu testen ist unmöglich. Wer das verspricht, hat kein Budget-Bewusstsein. Ressourcen sind endlich, daher nutzen wir – auch mit Blick auf DORA – im Testmanagement das Risk-Based Testing:

Wir priorisieren gnadenlos nach Schadenpotenzial:

• Der Super-GAU: Ein Fehler in der Zinsberechnung oder bei SWIFT-Überweisungen ist inakzeptabel. Hier geht es um Haftung, Regulierung und die Existenz der Bank.
• Der Image-Schaden: Ein Glitch beim Profilbild-Upload oder inkonsistente Menüs sind zwar nicht systemkritisch, zerstören aber die „User Experience“. Wenn die App sich „billig“ anfühlt, leidet das Vertrauen in die Marke massiv.
• Das Einfallstor: Instabile Funktionen sind oft versteckte Sicherheitslücken (z. B. fehlende Validierung). An diesen kritischen Punkten integrieren wir nahtlos unsere Security Testing Services, um Angriffsflächen sofort zu schließen.

Die Entscheidung ist strategisch: In Rücksprache mit den Stakeholdern sichern wir den Critical Path (Geldfluss & Daten) mit maximaler Härte ab. Bei UX-Themen wägen wir ab – wir akzeptieren ein dokumentiertes, kalkuliertes Restrisiko, solange der Kernbetrieb (die Sicherheit der Gelder) nicht gefährdet ist.

Konventionelles vs. resilientes Vorgehen

Vertrauen durch Kontrolle

Am Ende ist funktionales Testing eine Versicherungspolice gegen den Reputations-Super-GAU. Kunden erwarten funktionierende Transaktionen wie Strom aus der Steckdose. Wenn Banksysteme „einfach funktionieren“, dann nicht durch Magie, sondern weil im Hintergrund Tests liefen, die das Chaos antizipiert und absorbiert haben.

Leise, effizient und ohne Applaus. Genau so, wie es sein soll.

Melden Sie sich bei uns - wir können Ihnen weiterhelfen!