End-to-End-Tests: Das Testen in komplexen IT-Landschaften

Das neue Bestandssystem soll in Kürze eingeführt werden, aber die Briefschreibung am Ende des Prozesses funktioniert nicht. Es fehlen schlichtweg Daten. Und das kurz vor dem Go-live. Wie ist das möglich, es wurde doch alles getestet? Die geschilderte Situation treffen wir in unserem Arbeitsalltag sehr häufig an. Nicht nur bei der Einführung von Bestandssystemen! Dabei liegt es meist keinesfalls daran, dass Tests fehlerhaft durchgeführt wurden. Die IT-Abteilung hat alle Tests entlang des Testprozesses vollumfänglich durchgeführt. Es liegt vielmehr daran, wie die Tests methodisch angegangen wurden.

Aber von Anfang an:

Klassischer Testprozess unter der Lupe

Komponententest, Komponentenintegrationstest, Schnittstellentest, Integrationstest – so lauten die klassischen Stufen eines Testprozesses. Während der Komponententest bzw. Unit Test prüft, ob das entwickelte oder einzuführende Softwaremodul selbst die gewünschten Funktionen abdeckt, checkt der Komponentenintegrationstest, ob das Modul mit den Nachbarsystemen korrekt zusammenarbeitet. Hier ist meist der Schnittstellentest mit integriert. In diesen ersten drei Stufen des Softwaretests arbeiten vor allem die IT-Abteilungen und im weiteren Verlauf die dazugehörigen Fachabteilungen zusammen und prüfen alle im System vorhandenen Komponenten und ihre direkten Schnittstellen auf Herz und Nieren.

Sind alle Systeme fertiggestellt und zum geplanten Gesamtkonstrukt integriert, wird final der vollständige End-to-End-Prozess durchgetestet. Und an dieser Stelle treten meist unerwartete Probleme auf. Eigentlich sollte dies ohne Komplikationen funktionieren, da ja alle Komponenten und Systeme mit ihren direkten Nachbarsystemen getestet wurden, oder?

Reporting und Druck als Symptomträger fehlerhafter Integration einer Prozesskette

Am Ende der Prozessketten treffen wir meist auf das Reporting oder den Dokumentendruck. Data-Warehouse-Experten möchten übergreifende Berichte aus den einzelnen Systemen generieren. Zum einen müssen die gewünschten Daten über entsprechende Schnittstellen abrufbar sein. Zum anderen müssen die Experten die Datenzusammensetzung nachvollziehen können, damit keine Fehlinterpretationen erfolgen. Wie können diese Fehlinterpretationen verhindert werden?

Nehmen wir ein weiteres Beispiel aus dem Druck: Ein Kundenbrief teilt dem Empfänger unter anderem den Gesamtbetrag der Police mit. Alle Systeme, die dem Drucksystem vorgelagert sind, verwenden üblicherweise Beträge ohne Mehrwertsteuer. Jedoch hat es sich bei einer Absprache zwischen zwei benachbarten Systemen in der Kette als hilfreich herausgestellt, den Wert als Bruttobetrag zu übermitteln. Nehmen wir weiter an, das regulatorische Vorgaben beim Erstellen des Druckstücks ein separates Ausweisen des Nettobetrags, Aufschlüsselung der Steuersätze und des Bruttobetrags verlangen. Dies würde dem Druck-Verantwortlichen und seinem Team am Ende der Prozesskette zusätzlichen Klärungsbedarf abverlangen. Es ist nur ein Beitragsfeld vorhanden, und es ist nicht ersichtlich, ob es sich um den Netto- oder Bruttobetrag handelt. Wird der Steuersatz gesondert übertragen? Wenn ja, aus welchen Steuersätzen setzt sich der Wert zusammen? Um die fehlerhaften oder fehlenden Informationen zu ermitteln, wird oftmals aus Zeitnot eine redundante Businesslogik im Druckmodul implementiert. Mit allen Problemen, die dies nach sich zieht, wie z. B. Rundungsdifferenzen zwischen Druck- und Bestandssystem oder eine Verringerung der Wartungsfreundlichkeit. Dies wäre aber eigentlich nicht notwendig.

Kritischer Punkt: Datenzusammenführung

Doch nicht nur am Prozessende treten nun Abweichungen auf, die in den Tests nicht erkannt wurden. Auch beim Aggregieren von Daten aus unterschiedlichen Komponenten entstehen neue Herausforderungen: Ein System erhält Informationen von zwei Schnittstellen. Jede Schnittstelle liefert jeweils Daten, welche für sich genommen den Vorgaben in der Schnittstellendefinition entsprechen. Diese werden auf Basis der Businesslogik (z. B. Verketten/Konkatenation von VN-Nummern) verarbeitet und an nachfolgende Systeme weitergegeben. Zu einem späteren Zeitpunkt im Prozess wird dieser Wert als Referenz zum Auslesen von zusätzlichen Informationen aus einem weiteren System verwendet. Tritt hier ein Fehler auf, ist es für das aufrufende System und das verantwortliche Team sehr aufwendig den Fehler bis zu seiner Quelle nachzuverfolgen bzw. selbst zu beheben.

Data-Flow-Beschreibungen offenbaren Abhängigkeiten

Können die dargelegten Fehler durch die Anpassung des klassischen Testprozesses eventuell minimiert werden? Wir denken: ja! Kehren wir zurück zum Testprozess. Klassischerweise werden am Übergang von Stufe 3 – dem Schnittstellentest – zu Stufe 4 – dem Integrationstest – alle Fachbereiche mit einbezogen. Diese sollten spätestens an dieser Stelle im Prozess beginnen, mithilfe der Analysten der einzelnen Komponenten die Data-Flow-Beschreibungen als Grundlage für End-to-End-Test zu erstellen. In den Data-Flow-Beschreibungen treten nun auch die Anforderungen von Systemen zutage, die sich in der Kette sehr weit vor dem einzuführenden IT-System befinden. Sie zeigen deutlich, welche Daten von welchen Systemen in welcher Form benötigt werden. Und nun wird auch deutlich, welche Daten in welcher Form über mehrere Systeme und Schnittstellen mitgeführt werden müssen, damit sie am Ende des Prozesses zur Verfügung stehen. Schnittstellentests selbst validieren bis zu diesem Zeitpunkt lediglich den Austausch zwischen den direkten Nachbarsystemen. Damit treten die hier beschriebenen Stille-Post-Effekte auf. Werte, die ein System im späteren Prozess benötigt, werden nicht transparent und nicht in der benötigten Form weitergereicht. Die entstandene Abweichung muss dann kostenintensiv nachgebessert werden.

Fazit – Unsere Empfehlung:

Da wir uns in der Versicherungs-IT in komplexen Welten bewegen, lohnt es sich aus unserer Sicht, diese Data-Flow-Beschreibungen im Testkonzept bereits vor dem ersten Komponententest einzuplanen und die Fachbereiche somit frühzeitig für die Data-Flow-Beschreibungen mit ins Boot zu holen. Die darauffolgenden Tests können dann von den IT- und Fachabteilungen mit dem ganzheitlichen Prozesswissen durchgeführt werden. Der vermeintlich entstehende Aufwand hierfür lässt sich leicht dadurch rechtfertigen, dass Probleme frühzeitig erkannt und entsprechende Anpassungen frühzeitig eingeplant werden können. Das verhindert hohe Aufwände später im Prozess. Auf „Notlösungen“ am Ende des Prozesses, die Fehler im Gesamtprozess ausgleichen, kann damit verzichtet werden.