Als Versicherer oder Assekuradeur im Maklermarkt benötigen Sie BiPRO-Schnittstellen von höchster Qualität. Aber wie stellen Sie eine hohe Qualität sicher und was sollten Sie beim Testen von BiPRO-Schnittstellen beachten? Welche Aufgaben haben IT, Fachbereich und Vertrieb? Was sind die größten Probleme beim Testen von BiPRO-Schnittstellen und warum sollte man auch auf einer produktiven Betriebsumgebung „testen“? Diese und mehr Fragen behandeln wir in unserem Artikel zum Thema BiPRO Testing.
Warum sollten Sie BiPRO-Schnittstellen testen?
Ganz egal, ob Dokumentenaustausch per Norm 430, Neu- und Ersatzgeschäft über Norm 420, Extranet-Einstieg per DeepLink nach 440 oder Schadenmeldung gemäß BiPRO-Norm 503: die Qualität und Stabilität Ihrer BiPRO-Schnittstellen ist geschäftskritisch. Ihre Schnittstellen sind – genauso wie die Benutzeroberflächen Ihrer Extranets und Web-Anwendungen – ein Aushängeschild Ihres Unternehmens und gleichzeitig eine Eingangstür. Fehler und Ausfälle ärgern nicht nur Ihre Vertriebs- und Anbindungspartner, sie können auch zu einem schlechten Image führen und schwerwiegende Probleme und Verletzungen des Datenschutzes verursachen. In der Praxis haben wir bereits erlebt, wie Dokumente eines Maklers bei einem anderen angekommen sind. Mit anderen Worten: Ihre BiPRO-Prozesse und BiPRO-Daten sind für Sie und Ihre Vertriebs- und Kooperationspartner von elementarer Bedeutung. Das ist auch der Grund, warum Sie ihre BiPRO-Schnittstellen besonders sorgfältig testen sollten.
Im Rahmen einer empirischen Erhebung hat die auf BiPRO spezialisierte b-tix GmbH festgestellt, dass diejenigen Versicherer, die Ihre BiPRO-Schnittstellen auch in eigenen Web-Anwendungen selbst nutzen, Ihren Anbindungspartnern eine deutlich höhere Qualität und Quantität anbieten können.
Die Erklärung dafür ist einfach: Während BiPRO-Schnittstellen gewöhnlich nur von Dritten genutzt werden, erfolgt bei diesen Anbietern eine Selbstnutzung über Benutzeroberflächen durch den eigenen Innen- und Außendienst. Sie haben einen hohen Anspruch, entdecken Mängel schnell und kritisieren deutlich. Das führt wiederum zu einer besseren Testqualität und einem höheren Funktions- und Datenumfang.
Wer sollte BiPRO-Schnittstellen testen?
Auftrageber, Vertrieb und Fachbereiche gehen häufig davon aus, dass die IT für das Testing zuständig ist. Immerhin trägt sie die Verantwortung für die technische Umsetzung und bei BiPRO handelt es sich ja schließlich auch um ein Technikthema. Und ja, natürlich ist die IT für das Testing verantwortlich, allein schon aus Gründen der IT-Sicherheit. Der Gegenstand des Testings ist aber die Schnittstelle selbst und die Systeme dahinter. Dabei sollte ein Hauptaugenmerk auf die so genannten Negativtests gelegt werden. Hierbei handelt es sich um Testfälle, die Grenzwerte prüfen und darauf ausgelegt sind, die Schnittstelle zu einem unerwarteten technischen oder fachlichen Verhalten zu führen, weil zum Beispiel Prüflogiken fehlen. So ist es beispielsweise nicht selten möglich, einer BiPRO-Schnittstelle einen Preis für eine Deckung zu entlocken, die der Produktgeber gar nicht anbietet.
Neben der IT sollten Auftraggeber, Vertrieb und Fachbereiche ein ebenso hohes Interesse an einer gesicherten Qualität haben. Sie verweigern sich allerdings gerne intensiven Tests. Dabei ist gerade ihr Einfluss entscheidend für den späteren Erfolg der Schnittstellen. Sie schauen nämlich aus einer anderen Perspektive auf den „Kommunikationskanal Schnittstelle“ und haben ein Interesse an einem Test aus Sicht des Marktes. Sie kennen das peinliche Gefühl, wenn ihnen ein Vertriebspartner die mangelnde Qualität oder Verfügbarkeit der hauseigenen Anwendungen und Schnittstellen vor Augen hält und sie mit Störungsmeldungen konfrontiert. Für sie ist es also wichtig zu wissen, ob die Anforderungen des Marktes umgesetzt sind, die BiPRO-Schnittstelle also im Markt funktioniert und auch nach Veränderungen stabil bleibt. Hierfür ist ein fachliches und vertriebliches Testing im prozessualen Sinne von Ende zu Ende erforderlich, das häufig sogar über mehrere Schnittstellen hinweg läuft, die erst miteinander einen echten Mehrwert für den Vertriebspartner erzeugen. Zudem wünschen sich diese Parteien auch ein Testing auf produktiven Betriebsumgebungen, um Störungen frühzeitig zu erkennen. Diese Art von produktiven Tests fallen unter den Begriff Monitoring.
Wann sollten Sie Ihre BiPRO-Schnittstellen testen?
Üblicherweise beginnen Tests erst mit Fertigstellung der BiPRO-Schnittstellen. Im Sinne einer sorgfältigen Qualitätssicherung ist das jedoch verhältnismäßig spät. Bei einer BiPRO-Implementierung ist es zu empfehlen, schnellstmöglich einen technischen Durchstich zu realisieren und Auftraggeber sowie Fach- und Vertriebsbereiche möglichst früh in den Test zu involvieren. Als Durchstich bezeichnet man eine Programmierung von Ende zu Ende, die nicht in die Breite geht, sondern den vollständigen Prozess- und Datenfluss im Fokus hat. Auf diese Weise werden frühzeitig konzeptionelle, d. h. grundlegende Schwächen erkannt, die zu diesem Zeitpunkt meist noch kostengünstig heilbar sind. Eine frühzeitige Einbeziehung der Vertriebs- und Fachbereiche hat dabei den Charme, dass die Fachvorgaben für die Entwicklung nachgeschärft werden können.
Das Ziel sollte es sein, möglichst frühzeitig einen Test von Ende zu Ende durchzuführen. Der Gegenstand dieses Testings ist dann nicht länger nur die Sicht der IT auf eine technische Schnittstelle, sondern die Sicht des Marktes auf den gesamten Prozess- und Datenfluss von Ihnen zum Vertriebspartner oder umgekehrt. Eines dieser Enden ist Ihr Vertriebspartner mit seinem Maklersystem, das Ihre BiPRO-Schnittstellen konsumiert. Gewinnen Sie möglichst frühzeitig einen Pilotpartner, jemanden, der bereit ist, eine Anbindung an Ihren Prototypen vorzunehmen und dabei die zahlreichen „Kinderkrankheiten“ in Kauf nimmt.
Welche Probleme gibt es beim BiPRO Testing?
Häufig sind bei der Umsetzung von BiPRO-Schnittstellen viele Parteien involviert wie beispielsweise unterschiedliche IT-Abteilungen, angefangen von den Fach- und DV-Konzeptionären über die Anwendungsentwicklung im Front- und Backend bis hin zum IT-Betrieb und externen IT-Dienstleistern. Die fachlichen Vorgaben stammen meist aus den Fachbereichen und dem Vertrieb. Dazu kommen Pilotpartner und deren Systemhersteller, die Ihre Schnittstelle technisch integrieren.
Problem: Anforderungen
Bevor Sie mit dem BiPRO Testing beginnen können, sollten Sie definieren, welche Erwartungen Sie an Ihre Schnittstelle haben. Diese Erwartungen sind Anforderungen, die den Sollzustand definieren. Ein Test gilt als erfolgreich durchgeführt, wenn der definierte Sollzustand vollständig erreicht ist, also die Erwartungen und Anforderungen erfüllt sind. Ohne klare Anforderungen können Sie nur intuitiv testen.
Welchen Funktions- und Datenumfang und welche Anwendungsfälle möchten Sie an Ihrer BiPRO-Schnittstelle testen? Welche Verfügbarkeiten und Antwortzeiten soll Ihr Web Service eigentlich haben? Berücksichtigen Sie bei der Formulierung der Anforderungen optimalerweise bereits die Erwartungen für das Testing und bedenken Sie, dass einige Ihrer künftigen Anbindungspartner teils hohe Erwartungshaltungen an die Prozess- und Datenqualität haben und dies sogar Ihr Ranking beeinflussen kann.
Problem: Kommunikation
Alle Beteiligten müssen Hand in Hand arbeiten, um Vorgaben zu erarbeiten, Testdaten und Testfälle zu erstellen, auszuführen, Fehler zu erkennen, zu beseitigen und nach Behebung erneut zu testen. Die fehlerbereinigten BiPRO-Schnittstellen müssen danach bei Veränderung fehlerfrei und stabil gehalten werden. Zu den größten Problemen beim Testen von Schnittstellen gehören meist eine mangelnde Koordination und ineffiziente Kommunikation zwischen allen Beteiligten. Die Kommunikation ist häufig über mehrere Abteilungen, Unternehmen und Systeme verteilt und es mangelt an Detailinformationen für eine effiziente Analyse der Fehlersituation.
Problem: Testdaten
Auch die Erstellung und Aktualisierung von Testdaten ist aufwändig und lästig. Insbesondere wenn Sie mit Ihrer BiPRO-Schnittstelle beginnen, mangelt es Ihnen an Erfahrung und Daten. Testdaten müssen deshalb aufwändig erstellt werden und altern, wenn sie nicht gepflegt werden. Eine Regel, die überprüft, dass der Versicherungsbeginn nicht in der Vergangenheit liegen darf, kann bei statischen Testdaten heute noch ein korrektes und morgen bereits ein falsches Testergebnis liefern, weil das Datum in den Testfällen inzwischen gealtert ist. Diese Alterung von Testdaten ist nicht zu unterschätzen und bezieht sich nicht nur auf die fachlichen Inhalte, sondern auch auf die BiPRO-Datenstrukturen. Im Rahmen eines Versionswechsels kann es beispielsweise zu teils erheblichen Strukturveränderungen kommen, so geschehen beim Versionswechsel von BiPRO R2.3 auf 2.4, der faktisch einem Releasewechsel zu R3 gleich kam.
Problem: Wiederholbarkeit
Legen Sie von Beginn an Wert darauf, Testfälle nur einmal zu definieren, aber mehrfach automatisch ausführen zu können. Erstellen Sie sofort einen Testfall, sobald Sie einen Fehler gefunden haben und lassen sie den entsprechenden Testfall regelmäßig ausführen. So erkennen Sie umgehend, wann Ihre IT eine neue Version der Schnittstelle veröffentlicht hat, die den Fehler behebt. Lassen Sie diesen Test auch nach der Fehlerbehebung weiter laufen, um sofort zu erkennen, wenn sich derselbe Fehler zu einem späteren Zeitpunkt erneut einschleicht. Dies ist umso wichtiger, je stärker Ihre Schnittstelle „in Bewegung“ ist. Je öfter an der Schnittstelle gearbeitet wird, desto häufiger werden sich bereits gelöste Fehler wieder einschleichen oder Fehler an anderer Stelle als unerwünschte Seiteneffekte auftreten.
Problem: Recherche
Das Testen von BiPRO-Schnittstellen produziert erhebliche Aufwände für die Fehlererkennung und Dokumentation für die Reproduktion eines Fehlers. Lässt er sich nicht einfach reproduzieren, sind technische Protokolle entscheidend für eine effiziente Recherche. Achten Sie darauf, dass Sie Ihren Prozess detailliert protokollieren und diese Protokolle einfach und durch mehrere Mitarbeiter auszuwerten sind. Bitte beachten Sie in diesem Zusammenhang, dass auch Vertriebs- und Fachbereiche solche Protokolle benötigen könnten, um ihre Vertriebs- und Kooperationspartner besser betreuen zu können.
Problem: Erkenntnisse
Setzen Sie das Ergebnis eines fehlgeschlagenen Testfalls mit den Ergebnissen aus anderen Testfällen ins Verhältnis. Auf diese Weise erkennen Sie Zusammenhänge und verborgene Ursachen. Das ist insbesondere dann wichtig, wenn Ihre BiPRO-Schnittstelle eine Meldung generiert, die nicht klar und verständlich ist. Scheitern auch andere Testfälle an völlig anderen BiPRO-Schnittstellen, lassen sich Rückschlüsse auf Fehler in gemeinsam genutzten Komponenten finden.
Problem: Marktsicht
Der Test Ihrer BiPRO-Schnittstelle in Anwendungsfällen aus Sicht des Marktes mit einem entsprechenden Ende-Zu-Ende-Test kommt eine hohe Bedeutung zu. Selbst die verfügbaren Testtools mit BiPRO-Unterstützung eignen sich für diese Tests nicht wirklich. Ihr Pilotpartner kann Ihnen hierbei natürlich weiterhelfen, allerdings ist seine Software nicht unter Ihrer Kontrolle und damit – auch im Hinblick auf eine regelmäßige Qualitätssicherung – kein dauerhaft geeignetes Testtool für Sie. Der Begriff Pilotpartner signalisiert ja bereits den Charakter der Partnerschaft. Er hat gewöhnlich kein Eigeninteresse, Ihnen dauerhaft bei der Sicherung Ihrer BiPRO-Qualität entgegen zu kommen, ganz im Gegenteil sogar.
Welche Tools unterstützen Sie beim BiPRO Testing?
Der Markt für Testools für technische Schnittstelle ist allgemein recht groß und es gibt zahlreiche leistungsfähige Tools, die aber nicht selten hohe Lizenzkosten mit sich bringen. Für ein effzientes Testen von Schnittstellen benötigen Sie aber in der Regel geeignete Testtools. In der Versicherungswirtschaft begegnet man häufig Testtools wie beispielweise SoapUI, das u. a. für den Test von XML-Schnittstellen geeignet ist. Es ist kostenfrei, eignet sich aber nicht für Fachleute und ist für den Testgegenstand „Schnittstelle“ vorgesehen.
Fazit: Die wenigsten Testtools verfügen über eine native BiPRO-Unterstützung. Falls doch, eignen sie sich meist nicht wirklich für die Vertriebs- und Fachbereiche und auch nicht für Ende-zu-Ende-Tests aus Marktperspektive.
Die b-OX LD Plattform ist ein etablierter BiPRO Client, der im Markt von Tausenden Maklern verwendet wird. Die b-tix GmbH hat diesen BiPRO Client um Testfunktionalitäten erweitert und zu einem vollwertigen BiPRO Testtool weiter entwickelt. Ausführliche Protokolle und ein integriertes Supportsystem erhöhen die Effizienz genau an den richtigen Stellen und sorgen dank der einfachen Aufzeichnung und automatischen Ausführung von Testfällen sowie der Protokollierung und Kommunikation von Fehlern für eine deutliche Effizienzsteigerung.
Mit dem Testframework der b-OX LD nutzen Sie einen im Markt etablierten BiPRO Client als Vorgabe für Ihre Entwicklung, erhalten Testdaten, testen Ihre BiPRO-Schnittstellen manuell oder automatisch, nachdem Sie die Testfälle mit einem Recorder aufgezeichnet haben. Sie verwalten Ihre Testfälle in Excel und nutzen die Mächtigkeit von Excel zur Formulierung von Prüfungslogik. Die Excel-Testsuites werden automatisch ausgeführt und liefern Ihnen regelmäßig Reports mit den Testergebnissen. Fehler werden per Screenshot und mit technischen Protokollen gesichert und über das integrierte Supportsystem mit anderen internen oder externen Mitarbeitern geteilt. Nutzen Sie die b-OX LD auch als Monitoring-Plattform für Ihre produktiven Betriebsumgebungen und erkennen Sie Fehler noch bevor Ihr Vertriebspartner etwas bemerkt.
