Geschäftsgetriebene Testautomatisierung bezeichnet den Ansatz, Fachexpertinnen und Fachexperten aus Versicherungs- oder anderen Fachabteilungen direkt in die Testautomatisierung einzubinden, statt ausschließlich IT-Tester einzusetzen. Dafür braucht es niedrigschwellige Werkzeuge, angepasstes Wording ohne Anglizismen und kontinuierliches Coaching, damit Fachleute eigenständig robuste, risikobasierte Testfälle erstellen und pflegen können.
Das Wichtigste in Kürze
- Fachliche Abnahmetests lassen sich nur dann automatisieren, wenn Versicherungskaufleute das Werkzeug selbst bedienen, weil deren Domänenwissen kein Tester ersetzen kann.
- Der Abnahmetest eines Kundenprojekts bei Signal Iduna läuft nach der Automatisierung in drei Minuten durch, statt mehrere Personentage vor jedem Release zu binden.
- Technisches Vokabular wie “Triple-A-Prinzip” schließt fachliche Anwender aus; bei Signal Iduna ersetzte das Bild “Schienenersatzverkehr” die Begriffe Setup, Execute und Verify.
- Wöchentliches Ensemble-Testing im Coaching-Format, bei dem ein Teammitglied fährt und die anderen navigieren, hält das Automatisierungswissen im gesamten Team lebendig statt in Einzelköpfen.
- Synthetische Testdaten sind bei Signal Iduna der nächste Pflichtschritt, weil gesetzliche Datentrennung zwischen Sparten sonst verhindert, spartenübergreifende Services vollständig zu testen.
Warum Versicherer ihre Fachleute zum Testen brauchen
Bei Versicherungskonzernen reicht die technische Abnahme einer Software nicht aus. Die Versicherungsaufsichtsrechtlichen Anforderungen an die IT (VAIT) verlangen sowohl technische als auch fachliche Abnahmen. Und genau dort entsteht das Problem.
Die fachliche Abnahme braucht das Wissen von Versicherungskaufleuten. Diese Expertise haben Tester nicht, und sie lässt sich auch nicht schnell nachholen. Eine Ausbildung in Versicherungswirtschaft dauert drei Jahre, und der konkrete Bedarf hängt zusätzlich von der Sparte ab.
Bei einem Allversicherer wird die Bandbreite zum eigenen Faktor. Jörg Sievers beschreibt die Lage bei der Signal Iduna: rund 500 Anwendungen, dazu eine Bank und sämtliche Sparten von Auto über Transport und Kranken bis Leben. Niemand aus der Entwicklung kennt die fachlichen Use Cases dieser Systeme im Detail.
Daraus folgt eine klare Konsequenz: Die fachlichen Abnahmen lassen sich nicht in der Entwicklung automatisieren. Wer die Geschäftsvorfälle versteht, sitzt im Fachbereich, nicht im Entwicklungsteam.
Niederschwellig statt technisch: das Werkzeug muss zur Zielgruppe passen
Wenn Fachleute ohne IT-Hintergrund automatisieren sollen, entscheidet die Niederschwelligkeit über Erfolg oder Scheitern. Die zentrale Frage lautet: Wie einfach muss das Ganze sein, damit normale Anwender es nutzen und sich dafür begeistern?
Bei der Werkzeugauswahl gilt ein Grundsatz, den Jörg konsequent anwendet: Die Menschen entscheiden mit, die das Werkzeug später benutzen. Zwei Mitarbeitende ohne Automatisierungserfahrung, aber mit breitem fachlichen Wissen, bekamen mehrere Testwerkzeuge zum Ausprobieren und durften selbst sagen, welches ihnen am besten gefällt.
Das Werkzeug musste sich an einer vertrauten Welt orientieren. In Finanzbranchen kennt jeder Excel, also sollte die Lösung in diese Richtung gehen. Ein reines Excel kam trotzdem nicht infrage, weil Dokumentation revisionssicher erfolgen muss.
Auch die Sprache spielt eine Rolle. Die Signal Iduna ist ein über 100 Jahre altes deutsches Unternehmen mit langjährigen Mitarbeitenden. Englische Fachbegriffe und Anglizismen funktionieren dort nicht als Vermittlungsgrundlage.
Wording verändert die Haltung zum Testen
Schon die Begriffe entscheiden, ob Fachleute mitziehen. Testen ist oft negativ besetzt nach dem Motto “das muss ich tun”. Statt von Testen zu sprechen, ging es deshalb um Qualität prüfen und um Prüfpunkte.
Auch technische Prinzipien brauchen ein anschauliches Bild. Das Triple-A-Prinzip aus der Testautomatisierung, also Arrange, Act, Assert, übersetzten die Coaches in den Begriff Schienenersatzverkehr. Setup, execute und verify, ein Bild, das in Dortmund genauso verstanden wird wie in Hamburg.
Der Vorteil dieses Bildes ist praktisch. Wenn jemand auf einen Testfall schaut und nur zwei Zeilen statt drei sieht, weiß er sofort: Hier fehlt etwas.
Daneben steht eine feste Reihenfolge, die gebetsmühlenartig wiederholt wird, bis sie sitzt: erst den Testfall zum Laufen bringen, dann robust machen, dann parametrisieren. Erst wenn diese Prinzipien in Fleisch und Blut übergegangen sind, lassen sich die Teams allein arbeiten.
Risikobasiert statt “100 Datensätze, weil wir die schon immer hatten”
Fachbereiche denken zunächst selten in Testzielen. Statt über Ziele zu sprechen, gibt es oft die Haltung: “Wir haben hier unsere 100 Datensätze, und das sind unsere Testfälle.” Auf die Frage nach dem Warum folgt die Antwort: “Weil wir die schon immer hatten.”
An dieser Stelle setzt der risikobasierte Ansatz an. Die Leitfrage verschiebt sich auf das größte Risiko und den Geschäftsvorfall, der dieses Risiko abdeckt. Meistens sind das die komplexesten Testfälle.
Daraus ergibt sich eine pragmatische Faustregel für Fachtester: Statt alle Testfälle abzuarbeiten, reicht oft der komplexeste Fall, der zufällig alles Übrige mit abdeckt. Solche Vorgespräche laufen vor jedem Projektstart, angelehnt an ein Vier-Säulen-Modell zur Einführung von Testautomatisierung.
Coaching statt Tester zum Buchen
Die Methode lebt vom engen Kontakt zum Team, nicht von abgegebener Arbeit. Seit September arbeitet die Einheit als Center of Excellence. Das Selbstverständnis ist klar: keine Tester, die man buchen kann, sondern Hilfe zur Selbsthilfe.
Konkret heißt das mindestens eine Stunde Coaching pro Woche mit dem ganzen Team. Das Vorgehen ähnelt Ensemble-Testing: Einer ist Driver und teilt seinen Bildschirm, die anderen bewerten mit, ob alles stimmt. Die Coaches übernehmen die Rolle der Navigatoren und sagen, was zu tun ist.
Reihum wird jeder einmal Driver, damit jeder die Schritte selbst ausführen muss. Vorab schauen die Coaches auf die Arbeit der letzten Woche und sammeln Hinweise, wo sich etwas verbessern lässt.
Dieses Modell trägt über Personalwechsel hinweg. Eine Kollegin stieß erst nach Start der Automatisierung dazu, ohne Vorwissen, durchlief die Schulung und das Coaching und machte ihr eigenes Ding daraus. Eine zuvor skeptische Mitarbeiterin, die sagte “auf Testen habe ich keinen Bock”, entschied sich danach, in diese Richtung weiterzugehen.
Schwierige Projekte zuerst, nicht der harmlose Kalkulator
Der Einstieg lief bewusst über kritische Systeme statt über ein Randthema. Üblich wäre, mit einem kleinen Webseiten-Kalkulator zu beginnen, der mit anderen Systemen nichts zu tun hat. Das funktioniert schnell, hilft aber nicht weiter, weil danach unklar bleibt, wie es im Ernstfall läuft.
Stattdessen wurden zwei für das Unternehmen wichtige Projekte gewählt. Eines automatisiert das Kundenportal, über das Kunden ihre Unterlagen digital einreichen statt analog. Das andere betrifft den digitalen Abschluss von Versicherungen und weiteren Produkten.
Das Versprechen an die Teams war konkret und unter Zugzwang: Wer die Automatisierung einmal aufbaut, muss die langwierige manuelle Abnahme nie wieder so durchführen. Anders als externe Werkzeuganbieter konnten die internen Coaches dieses Versprechen nicht einfach behaupten, sie mussten es einlösen.
Das Ergebnis nach rund dreieinhalb Jahren: Kein Projekt hat abgebrochen, und alle sind noch so begeistert wie zu Beginn.
Business-Driven Test Automation: das Verhalten testen, nicht schnell grün werden
Der gefährlichste Reflex in der Testautomatisierung ist, schnell auf Grün zu kommen. Genau dagegen richtet sich der Ansatz, den Jörg als Business-Driven Test Automation (BDTA) bezeichnet, angelehnt an Behavior-Driven Development. Getestet wird das Verhalten des Systems, nicht der kürzeste Weg zum grünen Häkchen.
Ein Beispiel macht den Unterschied greifbar. Gibt ein Anwender “20000” und Enter ein, formatiert das System nach kurzer Verzögerung zu “20.000,00” und speichert genau diesen Satz in der Datenbank. Wer im Test direkt “20.000,00” einträgt, prüft nicht, was draußen passiert.
Die Folge wäre fatal: Macht ein Zulieferer dieses Formatierungs-Feature kaputt, fällt es im Test nicht auf, während die Anwender draußen plötzlich schlechte Datensätze speichern. Deshalb gilt die Regel: Nimm die Anwendung, wie sie ist, und suche keine Wege außen herum, etwa an einem blockierten Feld vorbei.
Wir wollen, dass das Verhalten eines Systems getestet wird. Automatisierer können immer Wege hintenrum wählen. Ein Feld ist blockiert, kein Problem, ich komme da dran vorbei. Genau das wollen wir nicht.
Jörg Sievers
Wie zwei Werkzeuge sich ergänzen statt zu konkurrieren
Verschiedene Testwerkzeuge müssen nicht gegeneinander antreten, sie spielen auf unterschiedlichen Ebenen. Im Kundenportal-Projekt nutzte die Entwicklung Cypress, während die Fachseite mit Sahi Pro arbeitete. Anfangs entstand der Eindruck einer Konkurrenz.
Die Auflösung lag in einer klaren Aufgabenteilung nach Stärken. Cypress eignet sich gut für eine One-Pager-App. Sobald aber Umsysteme ins Spiel kommen, etwas hoch- oder heruntergeladen oder zu einem anderen System gesprungen wird, spielt das andere Werkzeug seine Stärke aus.
Die Werkzeugauswahl folgte zusätzlich einem Kommunikationsziel. Gesucht war eine einfache Programmiersprache, auf die auch Entwickler sofort schauen können, denn JavaScript beherrscht praktisch jeder Entwickler. So lässt sich derselbe Test aus zwei Perspektiven lesen.
Das Resultat dieser Teilung ist messbar: Die Geschäftsvorfälle mit Systeminteraktion liefen weiter über Sahi Pro, ein großer Teil wanderte zu Cypress, und der Abnahmetest ist seither in drei Minuten durch, bevor es in die Produktion geht.
Testdaten zuerst, dann Konfiguration, dann Automatisierung
Bei komplexen Systemen entscheidet die Reihenfolge der Schritte über die Effizienz. Im datenintensiven Kundenportal-Projekt galt deshalb: Erst die Testdatenbereitstellung klären, dann alles Weitere.
Daraus entstand eine gestaffelte Abfolge. Zuerst werden die Testdaten generiert. Sind sie fertig, prüft das System seine Konfiguration. Erst danach startet die Automatisierung.
Allein der Konfigurations-Check spart pro Release einen Personentag. Fährt ein komplexes System mit fehlerhafter Konfiguration hoch, beginnt sonst alles von vorn, und der Tag ist verloren.
Die Automatisierung lässt sich zusätzlich gezielt starten. Wurde nur an einem Parameter gedreht, genügt es, im Jenkins die passende Testfallgruppe auszuführen statt des gesamten Laufs.
Hilfe zur Selbsthilfe heißt: Teams entwickeln eigene Ideen
Ein gutes Center of Excellence macht sich an den richtigen Stellen überflüssig. Die Einheit kann nicht alles leisten und stellt deshalb Methoden, Verfahren, Techniken, Werkzeuge und teils die Testumgebung bereit, statt die Arbeit zu übernehmen.
Dieser Ansatz zeigt sich an einer konkreten Aufgabe. Vor einer dreiwöchigen Abwesenheit gab Jörg einem Kollegen die Aufgabe mit, die Umgebungserkennung selbst zu lösen, also zu erkennen, auf welchem Testsystem die Automatisierung gerade läuft. Mit ein paar Tipps und ohne ständige Begleitung schaffte der Kollege es.
Solche eigenen Ideen sind das eigentliche Ziel. Auch die Reihenfolge aus Testdaten, Konfigurations-Check und aufgefächertem Start entstand maßgeblich in den Teams, nicht als Vorgabe von außen.
Die Werkzeugfreiheit hat dabei Grenzen, und das aus gutem Grund. Jedes eingesetzte Werkzeug braucht einen technisch und einen fachlich Verantwortlichen. Deshalb gibt es einen Katalog, aus dem die Teams wählen, statt einen ganzen Zoo an Tools wie ein Startup.
Automatisiert, manuell, explorativ: Was wo bleibt
Nicht alles wird automatisiert, und das ist beabsichtigt. Wo standardisierte Maschine-zu-Maschine-Kommunikation läuft, etwa über den Branchenstandard BiPRO im Austausch mit Vergleichsportalen, lässt sich vollständig automatisieren. Das ist allerdings ein anderer Test als der über die Oberfläche.
Bei internen Anwendungen ohne Schnittstellen läuft vieles über die Oberfläche, und Fachabteilungen führen weiterhin manuelle Tests durch. Besonders dort, wo Einheiten an Fachabteilungen außerhalb der agilen Strukturen abgeben, bleiben manuelle Tests die Regel.
Exploratives Testen wird aktiv gefördert. In kurzen Schulungs-Sessions über zwei halbe Tage lernen die Fachleute Testtechniken, die zum Unternehmen passen, etwa Äquivalenzklassenbildung und Grenzwertanalyse, samt praktischen Beispielen und der Begründung, warum man so vorgeht.
Synthetische Testdaten und Contract Testing als nächste Hebel
Zwei Themen stehen als nächste große Aufgaben an. Das erste sind synthetische Testdaten. Als Allversicherer steht die Signal Iduna unter gesetzlichen Restriktionen: Mitarbeitende der Lebensversicherung dürfen nicht sehen, was die Krankenversicherung verarbeitet.
Pseudonymisierung löst dieses Problem im Test nur halb, weil die Restriktion erhalten bleibt. Synthetische Testdaten sollen Systeme freigeben, auch im Hinblick auf künftige Produkte, die mehrere Sparten überschneiden. Wer nicht in die andere Sparte schauen darf, kann ein solches Produkt sonst kaum testen.
Das zweite Thema ist Consumer-Driven Contract Testing. Der Konzern wandelt sich von monolithischen Altsystemen, darunter WebSphere und 40 Jahre alter Cobol-Code, hin zu einer verteilten Welt aus Microservices. Zwischen den Services muss die Absprache gesichert sein.
Der Reiz von Contract Testing liegt in der Autarkie: Teams können für sich testen, ohne dass der ganze umgebende Systemzoo laufen muss. Dafür braucht es zuerst Projekte, die den Ansatz anwenden und andere damit überzeugen.
Eine Haltung zieht sich durch beide Themen. Im Testen wird vieles über Schmerz gelöst, obwohl prophylaktisches Handeln günstiger wäre. Wie Jörg es zuspitzt: Man kann prophylaktisch arbeiten oder reaktiv, und das Zweite ist teurer.
