Man holding a table with the word Automation displaying

Vorher/Nachher: Test Daten Automatisierung bei einer Versicherung

Die vollautomatische Bereitstellung von Testdaten bringt natürlich nicht nur einen Zeitgewinn, sondern vereinfacht ganz allgemein die Prozesse und entlastet damit die Entwicklungsabteilung und Projektteams.

Es entstehen weniger Engpässe beim Software-Testing und die kontinuierliche Entwicklung der benötigten Applikationen verläuft entspannter. Aber was heißt das ganz konkret? Im Folgenden wollen wir einmal kurz skizzieren, was das im Falle eines großen Versicherers bedeuten kann.

 
Vorher: halbautomatische Testdaten-Bereitstellung
 

Im beschriebenen Beispiel wurden – wie das bei vielen Banken und Versicherungen üblich ist – alle wesentlichen Applikationen selbst entwickelt, z.B. für das Schadenmanagement, die Aufgabenverwaltung, die Vertragsverwaltung usw. alles auf z/OS mit einer Db2 Datenbank. Auch die aus diesen Applikationen benötigten Testdaten wurden durch eine Eigenentwicklung aus verschiedenen Ebenen extrahiert und semi-automatisiert zusammengestellt.

Diese Eigenentwicklung verfügte über einige ISPF Panels, mit denen diverse Funktionen gesteuert werden konnten, z.B. um die Kundennummer x aus Umgebung A in Umgebung B zu transportieren etc.

Das ISPF sollte und konnte aber nur von einigen wenigen Entwicklern bedient werden. Daher wurde eine E-Mail-Schnittstelle eingerichtet.

Brauchte ein Entwickler oder Tester einen Testfall, z.B. einen bestimmten Vertrag mit all seinen angehangenen Informationen. Dann schickte er seine Bestellung per E-Mail an einen Gruppen-Briefkasten.

Die eingehenden Bestellungen wurden von drei Experten nach und nach abgearbeitet. Um diese Anfragen zu verwalten, hatten sie sich einige Excel-Tabellen gebaut. Dieses Vorgehen war zweifellos ein recht arbeits- und zeitintensiver Ansatz.

 
Nachher: Unkomplizierte und automatisierte Testdaten Bereitstellung
 

Gemeinsam mit dem Versicherer wurde ein Webportal als eine zentrale Einstiegsapplikation geschaffen. Dahinter hängen dann die entsprechenden Anwendungen der UBS Hainer TDM Suite zur automatisierten Testdaten-Beschaffung.

Wo es sinnvoll war, wurden die Regeln bzw. Pattern der bisherigen Prozesse in die neue Lösung integriert. Über das Portal kann man nun Testdaten beziehen, die alle wesentlichen Bereiche abdecken, wie z.B. Kunden, Verträge, Schäden, Ereignisse, Verkaufschancen etc.

Heute wird agil iterativ getestet. Die Struktur sieht drei Schichten vor: Zunächst ist da die Produktion. Als nächstes gibt es eine Integrationsebene mit Entwicklungs- und Testumgebung und mit unterschiedlichen Constraints. Die dritte Ebene ist das Entwicklungsumfeld mit fünf bis sechs Umgebungen, die zu unterschiedlichen Zeitpunkten aktualisiert werden. Hier wird definiert wann und wie Deployments stattfinden und nach welchen Regeln mit den Daten verfahren wird.

Um die Ausgangs-Situation zu optimieren kam die UBS Hainer TDM Suite zum Einsatz. Dabei wurden zwei Fliegen mit einer Klappe geschlagen:

  1. Alle benötigten Testfalldaten können heute über ein zentrales Webportal von jedem einzelnen Entwickler und Tester jederzeit in Produktionsqualität abgerufen werden.
  2.  Gleichzeitig wird das gesamte System sukzessive von Mainframe auf Distributed – also in diesem Fall von DB2 auf Oracle – umgestellt.

Fazit: Gemeinsam mit UBS Hainer gewann die Versicherung ein hohes Maß an Unabhängigkeit, einen massiven Geschwindigkeitszuwachs und machte dabei einen wichtigen Schritt zu flexibleren zukunftsorientierten Technologien.

AKTUELLE BEITRÄGE

TDM Lösung – Make or Buy?

Die TOP5 ARGUMENTE – Warum sich die Eigenentwicklung einer Testdatenmanagement-Lösung heute nicht mehr lohnt. TDM ist zu einem komplexen Thema für Experten geworden, die ausgereifte Lösungen auf den Markt bringen

MEHR »

Testdatenbeschaffung – Drei grundlegende Optionen

Im Prozess der Software-Entwicklung müssen immer wieder Tests durchgeführt werden. Dazu werden je nach Entwicklungsphase verschiedene Testdaten – von einzelnen Testfalldaten bis hin zu Massendaten – benötigt. Welche Möglichkeiten gibt es, diese Testdaten zu beschaffen? Im Folgenden werden wir uns drei Optionen anschauen.

MEHR »

Massendaten für System- und Releasetests

Best-Practice: Testdatenbeschaffung im Rahmen kontinuierlicher Software-Entwicklung (TEIL 3/3). Bevor die neuen oder modifizierten Applikationen live gehen, kommen abschließend System-, Abnahme-, Last- oder Performancetests zur Anwendung. Hier braucht es keine feinkörnigen maßgeschneiderten Testfalldaten, sondern produktionsnahe Daten in größeren Mengen.

MEHR »

Maßgeschneiderte Testfalldaten für Funktions-, Komponenten- und Regressionstests

Best-Practice: Testdatenbeschaffung im Rahmen kontinuierlicher Software-Entwicklung (TEIL 2/3). In der Regel bedeutet die Weiterentwicklung einer Anwendung, dass unterschiedliche Features oder auch Bug Fixes zu implementieren sind. Im Optimalfall erhält jedes Feature eine eigene Umgebung. Diese Umgebung enthält nur die relevanten Daten für den jeweiligen Fall.

MEHR »

Grünes Licht für automatisiertes
Testdatenmanagement

Nutzen Sie unsere kostenlose Erstberatung, um schnell und unkompliziert Ihre optimalen und individuellen Optionen zu ermitteln!

Green traffic light