Analytische Qualitätssicherungs-Maßnahmen in ReSy-Einführungsprojekten

Konkret betrachten wir die Prüfung von

1. aus Sicht des zuständigen Fachanalysten final ausgearbeiteten Spezifikationsdokumenten (User Stories)
2. neuen Software-Ständen (Releases) der Kundendistribution von ReSy, die als Ergebnis eines Entwicklungszyklus (Sprints) an den Kunden ausgeliefert werden.

Prüfung von Spezifikationsdokumenten (User Stories)

Um zu verstehen, wie Spezifikationsdokumente (User Stories mit zugehörigen Anhängen) qualitätsgesichert werden, werfen wir zunächst einen Blick auf deren Erstellungsprozess:

Jede User Story wird federführend durch genau einen für diese User Story zuständigen Mitarbeitenden des Fachanalyse-Teams ausgearbeitet. Im Falle von fachlich komplexen User Stories ist dies in der Regel ein Convista-Experte für die im jeweiligen fachlichen Kontext relevanten ReSy-Komponenten. Weniger komplexe User Stories können ggfs. auch Fachbereichs-Mitarbeitende des jeweiligen Kunden erstellen. Unabhängig vom konkreten User-Story-Ersteller basiert die Ausarbeitung einer User Story üblicherweise auf einem oder auch mehreren zuvor durchgeführten Fachanalyse-Workshops mit allen relevanten Fach- und Produktexperten. In diesen Workshops diskutieren die Teilnehmenden die fachlichen Anforderungen gemeinsam und stimmen ein mit der Produktphilosophie von ReSy kompatiblen Lösungsansatz ab.

Sofern der für die Ausarbeitung einer User Story zuständige Fachanalyst die User Story aus seiner Sicht vollständig und final ausgearbeitet hat, ist es dessen Aufgabe für diese eine formale Realisierungsfreigabe durch den kundenseitigen Product Owner und durch einen Convista-seitigen Proxy Product Owner zu erwirken. Diese beidseitige (!) formale Freigabe ist Voraussetzung für die nachgelagerte Umsetzung der User Story durch das Entwicklungsteam.

Je nach Komplexität der User Story werden der kundenseitige Product Owner und/oder der Convista-seitige Proxy Product Owner vor der Erteilung ihrer jeweiligen formalen Freigabe eine nochmalige Prüfung durch Fachbereichs-Experten bzw. Produkt-Experten in einem Umlaufverfahren oder in einem speziellen Abnahmeworkshop veranlassen. Im Falle eines Abnahmeworkshops präsentiert der Ersteller der User Story seine Ausarbeitung den anwesenden Teilnehmern nochmals im Detail.

Test von neuen Software-Ständen (Releases)

Beim Test von neuen ReSy-Releases stellen verschiedene Arten von maschinellen Regressionstests, die regelmäßig auf einem Automatisierungs-Server ausgeführt werden können, eindeutig den Schwerpunkt der analytischen QS-Maßnahmen dar. Der nachfolgende Exkurs „Maschinelle Regressionstests“ gibt einen Überblick über die auch in ReSy-Einführungsprojekten genutzten „Klassiker“ unter den maschinellen Regressionstests, bevor wir einen besonders wichtigen und ReSy-spezifischen Typ von Regressionstests ausführlich vorstellen.

Manuelle Softwaretests durch fachliche Experten werden in der Regel nur für den Test von kundenspezifisch neu entwickelten Features durchgeführt, um für diese nicht nur die korrekte Umsetzung der Vorgaben aus der Spezifikation zu überprüfen, sondern letztlich auch nochmals die fachliche Korrektheit der Softwarelösung als Ganzes.

Maschinelle Regressionstests

Wie bereits erwähnt, bilden verschiedene Arten von maschinellen Regressionstests den Schwerpunkt des Softwaretests in ReSy-Einführungsprojekten. Klassische Regressionstests für Web-basierte Java EE Anwendungen werden üblicherweise von deren Entwicklern in der Programmiersprache Java geschrieben und danach regelmäßig auf einem Automatisierungs-Server (wie Jenkins) ausgeführt. Typische Beispiele für solche Regressionstests, die auch in ReSy-Einführungsprojekten vom Entwicklungsteam erstellt und nachgelagert regelmäßig automatisiert ausgeführt werden, sind

• Unit-Tests auf Basis des JUnit-Frameworks
• Java EE Integrationstests mit OpenEJB als Testcontainer
• GUI-Tests auf Basis des Selenium WebDriver APIs

Excel-basiertes Testframework der Convista

Wünschenswert sind neben den obigen, vom Entwicklungsteam zu erstellenden Arten von maschinellen Regressionstests auch maschinelle Regressionstests, die durch Tester und Fachexperten ohne Entwicklungs-Know-how erstellt werden können. Genau für diese Art von Regressionstests hat ReSy ein eigenes Excel-basiertes Testframework mit an Bord, mit dem beliebige Geschäftsvorfälle mit zugehörigen Eingabeparametern in der jeweiligen Kundendistribution von ReSy angestoßen werden können. Die Ergebnisse dieser Ausführung können dabei gegen im Testframework hinterlegte Erwartungswerte geprüft werden. Das Testframework kann hierdurch sowohl die Arbeit eines menschlichen Sachbearbeiters als auch die Durchführung von Dunkelprozessen in ReSy nachstellen.

Als Dokumentationsprogramm nutzt das Test-Framework Excel. Dadurch ist es möglich, Testfälle auch ohne tieferes technisches Verständnis des Systems zu erstellen und mit diesen die korrekte Funktion des Systems zu überprüfen. Unterstützend können sämtliche Excel-Funktionalitäten wie Formeln oder VBA-Skripte verwendet werden, etwa um Erwartungswerte von Excel berechnen zu lassen, wodurch die Testfälle leichter pflegbar werden.

Das Testframework basiert auf einzelnen Arbeitsschritten/Kommandos (Commands), die vom Ersteller eines Tests feingranular definiert und in eine Ablaufreihenfolge gebracht werden können. Es eignet sich besonders für den Test von mathematischen Berechnungen, den Test von komplexen Alterungs- und Veränderungsprozessen im Vertragsbestand sowie für End-2-End Tests aller Art. Es unterstützt somit den Test der Anforderungen von Aktuariat, Kundenservice und Rechnungswesen. Derzeit stehen über 150 unterschiedliche Commands zur Verfügung.

Zeitreise im System

Für viele End-To-End Tests essenziell ist die Möglichkeit einer „Zeitreise“ im System. Heißt konkret: Jedem Kommando kann ein definiertes Datum (in der Vergangenheit oder in der Zukunft) mitgegeben werden, zu dem es den zugehörigen Geschäftsvorfall ausführen soll:

• Beginnend mit der Vertragsanlage
• über Vertragsänderungen im Rahmen von  Storno- / Aufstockungs- und Alterungsprozessen
• bis hin zur Leistungsbearbeitung, der Prüfung von Buchungen oder dem Erzeugen von Reports und Dokumenten

können so durch das Excel-Framework zu testende Prozessschritte in zeitlich stimmiger Abfolge angestoßen und zugehörige Erwartungswerte geprüft werden. Da die Tests auf einer vollwertigen Kundendistribution ausgeführt werden, lässt sich mit dem Testframework auch die Datenversorgung der kundenspezifisch angebundenen Umsysteme testen.

Mit und ohne Entwicklungsumgebung

In ReSy-Einführungsprojekten nutzt das Entwicklungsteam mittlerweile häufig auch Excel-Framework basierte Testfälle anstelle von klassischen Java EE Integrationstests. Hierzu binden die Entwickler diese Testfälle so in ihre Entwicklungsumgebung ein, dass sie diese wie klassische Integrationstests aus der Entwicklungsumgebung heraus starten können. Tester und Fachexperten hingegen nutzen das Excel-Testframework ohne eine Entwicklungsumgebung. Sie verwenden stattdessen direkt das auf einem Testsystem installierte Docker-Image der zu testenden Kundendistribution, um ihre mit dem Excel-basierten Test-Framework erstellten Testfälle per Docker-Kommandozeilen-Befehl aufzurufen.

Sämtliche finalisierten Excel-Tests werden unabhängig von deren Ersteller in automatisierte Regressionstests für die jeweilige Kundendistribution von ReSy eingebunden, die fortan regelmäßig auf einem Automatisierungs-Server (Jenkins) wiederholt werden. Der Automatisierungs-Server Jenkins ist Teil der CI-Infrastruktur des Entwicklungsteams, die sicher stellt, dass nicht beabsichtigte Seiteneffekte durch die Weiterentwicklung der Kundendistribution schnellstmöglich erkannt und korrigiert werden.

Das Excel-basierte Testframework kann in ReSy-Einführungsprojekten auch sehr gut dazu genutzt werden, Test-Fixtures für manuelle Tests eines neuen Releases der jeweiligen ReSy-Kundendistribution zu definieren und jederzeit leicht wiederherzustellen. Die entsprechenden Testfälle beschränken sich in diesem Fall einfach darauf, die Geschäftsobjekte dieses Test-Fixtures anzulegen ohne zugehörige Erwartungswerte zu prüfen.

GUI-Tests mit Selenium

Da das Excel-basierte Testframework direkt auf die Backendlogik der ReSy-Kundendistribution zugreift, ist es nicht dazu geeignet, Fehler in der deren Anwenderschnittstelle (Benutzeroberfläche) zu finden oder die Funktion der Anwenderschnittstelle durch Regressionstests abzusichern. Um diese Lücke zu schließen, werden im Rahmen der Umsetzung von User Stories mit Bezug zur Anwenderschnittstelle immer auch Tasks für die Erstellung von neuen oder für die Anpassung von bereits existierenden automatisierten GUI-Tests umgesetzt. Diese GUI-Tests werden wie die Anwendung selbst in Java geschrieben und nutzen das Selenium WebDriver API, um in den in einem Browser angezeigten Web-Seiten der laufenden Anwendung ReSy Benutzeraktionen wie die Erfassung von Eingabefeldern oder das Drücken von Funktionsknöpfen zu simulieren. Wichtig hierbei ist, dass sämtliche Kontrollelemente der Web-Seiten mittels ihrer IDs und nicht mittels ihrer Positionen innerhalb der Web-Seite angesprochen werden, damit die GUI-Tests robust gegenüber reinen Layout-Anpassungen der Anwenderschnittstelle sind.

Da Tests auf der Anwenderschnittstelle meist langsamer laufen als Tests über die Backendlogik, können die beiden Welten Excel-basiertes Testframework und GUI-Tests miteinander kombiniert werden. So können zum Beispiel Verträge zunächst über das Testframework eingespielt werden und diese anschließend über GUI-Tests weiterbearbeitet werden. So kann der Tester die Laufzeit der Tests verringern und „Vorbereitungsarbeiten“ dem schnelleren Testframework überlassen.

Autoren

Cornelia Burko – Management IT Consultant

Mit Blick sowohl auf technische als auch organisatorische Themen unterstützt Cornelia Burko das Competence Center „Versicherungs-Methodik und IT“ im Geschäftsbereich Versicherung. Ihr aktueller Schwerpunkte ist dabei das Testmanagement mit Fokus auf die Testautomatisierung sowohl in klassischen als auch in agilen Projekten.

Dr. Claus Ziegler – Senior Management Consultant

Dr. Claus Ziegler ist verantwortlich für die versicherungsfachliche Funktionalität des Bestandsführungssystems ReSy. Mit seinen über 30 Jahren Berufserfahrung detailliert und konsolidiert er die fachlichen Anforderungen der ReSy-Bestandskunden und berät das ReSy-Entwicklungsteam beim technischen Design von zugehörigen Lösungen.