Die über Jahre gewachsene und häufig sehr heterogene IT in Lebensversicherungsunternehmen ist geprägt durch ein komplexes Zusammenspiel von diversen Softwarekomponenten, wie beispielsweise Rechenkern, Druck, In-/ Exkasso, Partnerverwaltung oder Angebotssoftware, die zum Teil von unterschiedlichen Herstellern bezogen und von verschiedenen Verantwortlichen im Haus betreut werden. Um sicherzustellen, dass nach einer Anpassung oder Weiterentwicklung der Software ihre bisherige Funktionalität nicht beeinträchtig wird, werden regelmäßig idealerweise nach jeder Modifikation Regressionstests durchgeführt. Dabei wird das Verhalten der modifizierten Software, das heißt die Reaktion beziehungsweise Ausgabe auf eine bestimmte Eingabe, mit dem Verhalten einer früheren Version der Software bei gleicher Eingabe verglichen. Aufgrund der Häufigkeit von Softwareupdates sowie zunehmender Funktionalität und damit einhergehend steigender Anzahl von erforderlichen Regressionstestfällen ist eine manuelle Durchführung des Regressionstests nicht sinnvoll, da diese sehr zeitaufwändig und fehleranfällig ist.
In einer früheren Ausgabe dieser Zeitschrift [1] wurde gezeigt, wie unter Verwendung von geeigneten Testwerkzeugen zur Steuerung von Bildschirmeingaben und mit Hilfe von Codegenerierungstechniken eine weitgehend automatisierte Durchführung von Tests von Geschäftsvorfällen erzielt werden kann. Dieser Ansatz hat sich in der Praxis als sehr wartungsfreundlich erwiesen und erfordert nur minimale Benutzerinteraktion, welche sich im Wesentlichen auf die Pflege der Testfälle und die Auswertung der Ergebnisse beschränkt. Außerdem wurde in [1] über den mathematischen Test von Rechenkernen berichtet, der in der Praxis oft losgelöst vom übrigen Bestandsführungssystem durchgeführt wird.
Im Allgemeinen genügt es jedoch nicht, einzelne Teilsysteme oder Komponenten separat einem Regressionstest zu unterziehen, denn durch das Zusammenspiel der verschiedenen Komponenten kann eine Softwareänderung in einzelnen Komponenten unerwünschte, nicht vorhersehbare Seiteneffekte in den übrigen Komponenten bzw. dem Gesamtsystem verursachen.
Probleme bei separatem Regressionstest
Als Beispiel betrachten wir den erwähnten separaten Regressionstest des mathematischen Subsystems, wie er in der Grafik „Beispiel 1“ skizziert ist.
Der Rechenkern ist als Subsystem über eine definierte Schnittstelle mit dem Bestandsführungssystem verbunden. Beim separaten Regressionstest werden die Werte, die vom Bestandsführungssystem an den Rechenkern über dessen Eingabeschnittstelle weitergegeben wurden, als feste Eingabewerte für den Regressionstest verwendet. Die entsprechende Ausgabe, das heißt die berechneten mathematischen Werte des zu testenden Systems in der neuen Version, wird mit der Ausgabe einer früheren Version des Rechenkerns verglichen. Das Problem bei dieser Vorgehensweise ist, dass die Eingabewerte bei Änderungen im übrigen Bestandsführungssystem im Allgemeinen nicht mehr aktuell sind und möglicherweise sogar die Eingabeschnittstelle selbst modifiziert wurde. Diese Änderungen des Bestandsführungssystems bleiben dem mathematischen Test somit verborgen. Gleiches gilt für andere Systemkomponenten, die oft separat getestet werden, wie zum Beispiel das Drucksystem.
Integrierter Gesamttest
Daher ist es zur Gewährleistung einer intakten Gesamtfunktionalität erforderlich, einen integrierten Regressionstest im Verbund mit allen beteiligten Systemen durchzuführen. Ein derartiger Test ist insbesondere robust gegen die erwähnte Änderung einzelner Schnittstellen oder deren Inhalte, da die entsprechenden Daten, die zwischen den Teilsystemen übermittelt werden, im Gegensatz zum separaten Test dieser Teilsysteme stets aktuell sind.
Exemplarisch ist in der nächsten Grafik ein Regressionstest für verschiedene Systemkomponenten im Verbund dargestellt, wobei neben der zentralen Bestandsführung die folgenden ausgewählten Komponenten beziehungsweise Subsysteme beteiligt sind: mathematischer Rechenkern, In-/Exkassosystem, Drucksystem und grafische Benut-zeroberfläche (GUI). Das Testszenario besteht aus einer Folge von mehreren Einzelschritten, die entsprechende Geschäftsvorfälle und Abläufe im produktiven Betrieb simulieren. So wird etwa im ersten Schritt ein neuer Vertrag policiert, während im zweiten Schritt eine Fortschreibung angestoßen wird. Im dritten Schritt könnte dann beispielsweise eine technische Vertragsänderung durchgeführt werden. In der Grafik „Beispiel 2“ sind die Schnittstellen zwischen den Komponenten durch farbige Rechtecke symbolisiert, wobei die Pfeile die Richtung des Datenflusses anzeigen. Nur im Kontext aller Teilsysteme kann die Konsistenz und Aktualität dieser Schnittstellen und somit eine realistische Simulation von Geschäftsvorfällen gewährleistet werden.
Im Folgenden werden wir einige praktische Aspekte des Zusammenschlusses von zuvor separat durchgeführten Regressionstests zu einem integrierten Gesamttest diskutieren. Zunächst ist für eine automatische Durchführung dieses Gesamttests eine vollständige Automatisierung der Testdurchführung in allen Teilsystemen erforderlich. Außerdem führt ein computergestützter, regelbasierter Vergleich zwischen Testergebnissen und Referenzwerten dazu, dass der manuelle Aufwand bei der Analyse von Abweichungen so weit wie möglich reduziert wird. Aus organisatorischen Gründen empfiehlt es sich, die Regressionstestfälle und die entsprechenden Referenzwerte für alle Teilsysteme gemeinsam zu verwalten, etwa in einem zentralen Testfallkatalog. Hierdurch erhält man eine vollständige Übersicht über die Testabdeckung für das Gesamtsystem und kann im Rahmen der Integration nun gegebenenfalls redundante Testfälle einsparen. Darüber hinaus ist eine Klassifikation der Testfälle nach Testzweck beziehungsweise nach primär betroffenen Teilsystemen sinnvoll, da in der Regel aufgrund beschränkter Verfügbarkeit von Ressourcen nur gewisse Testfälle aus dem Bestand ausgewählt werden. Bei den Testfällen für den Rechenkern erhöht sich beispielsweise die Ausführungszeit durch die Integration in den Gesamttest im Vergleich zum separaten Regressionstest erheblich: Während im separaten mathematischen Test für eine Vielzahl von verschiedenen Tarifkombinationen entsprechende relevante Geschäftsvorfälle im Rechenkern schnell simuliert werden können, erfolgt die Steuerung im Gesamttest über das Bestandsführungssystem und somit zum Teil über Benutzereingaben. Auch wenn die Eingaben über die GUI automatisiert durchgeführt werden können, erzielt man auf diese Weise einen erheblich geringeren Durchsatz als beim separaten mathematischen Test, so dass es aus Kapazitätsgründen also typischerweise nicht möglich ist, den gesamten mathematischen Regressionstestfallbestand im integrierten Gesamttest durchzuführen.
Testinfrastruktur
Der Aufbau einer Infrastruktur für die automatisierte Durchführung von Regressionstests erfordert neben der Kenntnis von Geschäftsprozessen typischerweise weitreichende IT-Fähigkeiten. Als Beispiel betrachten wir die automatisierte Eingabe von Testdaten über die GUI eines LV-Bestandsführungssystems, wobei entsprechende Testskripte zur Steuerung dieser Eingaben unter Verwendung eines modellbasierten Ansatzes [2] automatisch generiert werden sollen. Wie in Grafik „Testinfrastruktur“ dargestellt, benötigt man für die Generierung von Testskripten und Eingabedaten formale Beschreibungen der Testfälle, der zu testenden Geschäftsvorfälle sowie der Benutzeroberfläche. Die Testfälle mit den entsprechenden Eingabedaten können beispielsweise in einem Testfallkatalog abgelegt sein. Dieser Katalog wird durch eine formale Beschreibung der Geschäftsvorfälle, etwa in Form von Zustandsdiagrammen, ergänzt. Zusätzlich wird eine Spezifikation der typischerweise hierarchisch strukturierten Komponenten der Benutzeroberfläche benötigt. Auf Basis dieser Informationen können ausführbare Testskripte automatisch erzeugt werden. Diese Skripte sind auf ein konkretes Testwerkzeug zugeschnitten und werden von diesem während der Testdurchführung interpretiert, indem es entsprechende Aktionen auf der Benutzeroberfläche des Bestandsführungssystems ausführt.
Wenngleich sich die einzelnen Komponenten vom Testfallkatalog bis hin zum Testwerkzeug in den verschiedenen Versicherungsunternehmen unterscheiden, so ist doch die in der Grafik gezeigte Struktur übertragbar. Daher wurde eine Plattform zur Testfallgenerierung entwickelt, die sich flexibel in die im Unternehmen vorhandene Infrastruktur einfügt und somit die produktionshemmende Lücke zwischen dem Testfallkatalog des Fachtesters und den im Hause verwendeten Testwerkzeugen schließt. Das Unternehmen erhält so eine weitgehend automatisierte und damit sehr effiziente Testumgebung, insbesondere für Regressionstests, die es zunächst fremd administrieren lassen kann, um sie dann entsprechend den eigenen Ressourcen in Eigenregie zu übernehmen.
Auslagerung von Testaktivitäten in LV-Testcenter
Da das Testen eine klar definierte Tätigkeit mit eindeutigem und überprüfbarem Ergebnis ist, wird vielerorts eine mögliche Auslagerung von Testaktivitäten erwogen. So lassen sich bei Bedarf Teilaufgaben, wie zum Beispiel Regressionstest, Migrationstest oder die Themenauswahl beim Fachtest an externe Anbieter übertragen. Besonders in der Testphase unmittelbar vor Auslieferung einer neuen Softwareversion oder vor einer Bestandsmigration steigt typischerweise der Ressourcenbedarf für den Systemtest, weshalb zur Entlastung der eigenen Fachkräfte häufig Dienstleister mit entsprechendem Fachwissen eingesetzt werden. Der Trend zum Outsourcing in externe Testzentren wird darüber hinaus durch zunehmende Automatisierung des Testbetriebs weiter verstärkt [3]. Dabei sind Aufwand und Kosten in der Regel recht präzise kalkulierbar und durch Service-Level-Agreements steuerbar. Testzentren mit Anbindung an die Testumgebung des Versicherungsunternehmens müssen nicht nur über LV-Experten, das heißt erfahrene Sachbearbeiter und Fachtester, verfügen, sondern zusätzlich über fachlich und technisch versierte Testingenieure, die mit leistungsfähigen Testwerkzeugen ausgestattet sind.
Fazit
Gegenwärtige LV-Bestandsführungssysteme zeichnen sich durch ein komplexes Zusammenwirken verschiedener Systemkomponenten aus. Entsprechend muss auch ein Regressionstest alle Komponenten mit einbeziehen, um unerwünschte Seiteneffekte nach Änderung einer Komponente auszuschließen. Ein umfassender Regressionstest ist jedoch heute ohne eine weitgehende Automatisierung kaum durchführbar.
Der Aufbau einer geeigneten Infrastruktur für den automatischen Test von Bestandsführungssystemen erfordert zudem in zunehmendem Maße IT-Expertenwissen sowie fundierte Kenntnis der auf dem Markt befindlichen Automatisierungswerkzeuge. Eine Auslagerung bestimmter Testaktivitäten stellt hier eine sofort verfügbare und zugleich kostengünstige Alternative dar. Ein späteres Insourcing der Testumgebung und Testautomatisierung oder Mischformen durch verteilte Teams sind ebenso denkbar.