Über 15 Jahre war ich in unterschiedlichen Unternehmen als Freelancer im Bereich der Testautomatisierung und des Testprozess Coachings unterwegs.

Zu den meisten Einsätzen wurde ich als Automatisierungs-Experte zu Hilfe gerufen, weil entweder nicht genügend Personen mit Entwicklungs Know How im Team zur Verfügung standen oder die Skills der verfügbaren Personen nicht ausreichten um eine saubere, nachhaltige Architektur und Implementierung umzusetzen.

Ein Ansatz ist es, qualitativ hochwertigen Code basierend auf JUnit oder TestNG zu erstellen und darauf zu vertrauen, dass dieser Code vom Team dann übernommen und gewartet/weiterentwickelt wird. Rückblickend eine naive und oftmals zum Scheitern verurteilte Annahme. Liegt es doch auf der Hand, dass Organisationseinheiten, die externe Hilfe benötigen, um eine Testautomatisierung zu bauen, selten die Ressourcen und Prioritäten dafür haben, diese dann selber ordentlich zu betreuen.

Auch in unserer Firma mangelt es in vielen Projektteams an entsprechenden Entwicklungskapazitäten. Gemeinsam mit meinem Team haben wir uns auf die Fahnen geschrieben, dieses Problem konzeptionell aufzubereiten und die Konzepte in der Testplattform Tiger umzusetzen. Für die spezifische Testart API Testen gelang es uns hiermit Fast-Code-less Testsuiten zu realisieren.

Die zentrale Frage dieses Artikels lautet also:

Welche Aspekte sollten Organisationseinheiten, die unter SW-Kapazitätsengpässen dauerhaft leiden, berücksichtigen?

Konfigurierbare Testumgebungen

Docker, Helmchart, geheime JARs und WARs aus der Nachbarabteilung, die mit kryptischen Kommandos auf ganz spezifischen Rechner gestartet werden müssen. Die Kollegin im ersten Stock, die als einzige weiß, welche Parameter gesetzt werden müssen, um die Tests sauber durchlaufen zu können. Also genau die, die gerade ihren Urlaub genießt, krank ist oder gestern die Firma gewechselt hat. Shell Skripte, die ohne Kommentierung die Testumgebung seit 10 Jahren starten, die aber keiner mehr anpassen will, weil “never change a running System”.

Abbildung 1: Wenn C++ Programmierer:innen bash Dateien überarbeiten

Was also gebraucht wird, ist eine einfache konfigurierbare Testumgebung. Eine Implementierung eines Testumgebungsmanagers wie in der Tiger Testplattform, der über Yaml Konfigurationsdateien transparent und nachvollziehbar Testobjekte und das “System under Test” hochfährt, verwaltet und nach dem Testlauf auch wieder beendet. Ein weiterer entscheidender Aspekte ist die Entkopplung von Real Instanzen und der Testsuite. Ob der Server nun wirklich via https://www.sq-magazin.de angesprochen wird oder über den symbolischen Hostnamen https://testmagazin… macht auf den ersten Blick wenig Unterschied. Bei mehreren Staging Umgebungen ist es dann aber sehr hilfreich, nicht in der Testsuite die Zugriffe an allen Stellen anpassen zu müssen, sondern in der Konfigurationsdatei einfach die Verlinkung für den Server testmagazin auf www.sq-magazin-dev.de ändern zu können.

Abbildung 2 Triviales Beispiel einer Testumgebungs YAML

Der große Vorteil liegt auf der Hand – keine kryptischen bash scripts, sondern transparente Daten in strukturiert lesbaren YAML Dateien. Diese benötigen keine Unix Entwickler:innen und Tester:innen mit fachlichem Know How können diese anpassen und für sich nutzen.

Protokollierte Nachrichtenverläufe

Ja, wie denn nun, der Test ist rot? Zeig mal das Log. Wie, da gibt es keine Zeitstempel? Und nicht alle Nachrichten werden geloggt? Wie kommen wir auf den Server zum Auslesen der Logs? So oder ähnlich kennt man es aus den Testbereichen vieler Organisationseinheiten. Es braucht also eine Möglichkeit, den Nachrichtenverkehr zwischen den Testobjekten zu persistieren, und zwar in einer Form, dass Tester:innen einfach auf diese Nachrichten zugreifen und diese analysieren können. In Zeiten von REST/SOAP/Microservices bietet sich hierfür z.B. natürlich ein HTTP(S) basierter Proxy an, welcher die Nachrichten mitschneidet und menschenlesbar abspeichert.

Abbildung 3: Diagramm Proxy, meshed setup mit Testsuite und Testumgebung

Der in der Testplattform Tiger umgesetzte Tiger Proxy kann aber noch mehr. Für Edge Case / Negativ-Tests ist es sehr effizient, Anfragen und Antworten zwischen den Servern dynamisch über die Testumgebungskonfiguration modifizieren zu können.

Also zum Beispiel alle Anfragen an https://testmagazin/edgecase/failure mit einem 500er Response belegen zu können. Dies ist nur ein triviales Beispiel, um den Rahmen dieses Artikels nicht zu sprengen. In realen Testszenarien sind hier wesentlich komplexere Konfigurationen möglich.

Validierung via RbelPath/JEXL / Protokoll agnostisches Testen

Ein weiterer Aspekt ist natürlich, dass ich eine Nachricht nicht per Code basierten Assertions testen will, sondern am besten protokoll- und format-agnostisch.

Strukturierte objektbasierte Nachrichtenformate (also die überwiegende Mehrheit aller derzeit verwendeten Inhalte) bieten mit DOM und XPath eine sehr schlaue Lösung an. Diesen Ansatz zu generalisieren und für Test Verifikation zu erweitern, reduziert die Aufwände in der Testautomatisierung enorm und wird bei uns mit dem Schlagwort “format-agnostisch” bezeichnet.

Wenn ich also am Header Claim „Algorithmus“ des JWT in einer SOAP Antwort im XML Knoten “AccessToken” interessiert bin, der bei der elektronischen Patientenakte auch noch mit einer Vertrauenswürdigen Arbeitsumgebung verschlüsselt ist, so reduziert es die Aufwände natürlich extrem, wenn der Zugriff auf dieses Claim beispielhaft durch folgenden Ausdruck erfolgen kann:

RbelPath ist eine Implementierung dieses Konzepts, die gekoppelt mit JEXL die Möglichkeiten bietet, sehr effizient und eben format-agnostisch Nachrichten im Testsystem zu prüfen. Ob es nun ein Knoten in einem JSON oder XML oder exotischen Formaten wie SICCT / CETP ist, denn man untersuchen möchte. Mit Hilfe von RbelPath werden die Formate in einem einheitlichen Strukturbaum abstrahiert, in welchem man XPath-like navigieren kann.

liefert den Text des ersten Tasks in der Liste. Etwas fancier mit JEXL liefert den Text des Tasks in der Liste, dessen date Attribut auf den 1. Mai lautet. Sie können mit RbelPath sogar prüfen ob die Nachricht in einem SOAP Request ein gültig signiertes XML in einem Knoten enthält:

Abbildung 4: Beispiele von JEXL/RbelPath mit kurzer Erläuterung

Parametrisierung von Tests

Testdaten in z.B. YAML Dateien gut lesbar und strukturiert zu hinterlegen und die Werte daraus über einfache Lookups in Testfälle einzubauen ist ein weiterer wichtiger Aspekt. Beispielhaft am unten angeführten Testcode. Die ${test…} Ausdrücke werden über eine Testdatenkonfigurations YAML Datei zentral gewartet, können aber in der Testsuite an allen Stellen verwendet werden.

Abbildung 5: Beispiel Testschritte

Abbildung 6: Beispiel Testdaten YAML Datei

Rolle von BDD feature files

Gemeinsam mit in Gherkin formulierten Feature Dateien entsteht so eine Testsuite, die ausführbar ist und an spezifische Umgebungen / Szenarien angepasst werden kann. Diese Feature Dateien liefern damit detaillierte Testkriterien für Anforderungen zu bereits sehr frühen Zeitpunkten – auf technischem API-Niveau detailliert z.B. bis in jeden Knoten der Antwort eines OAuth2 Flows. Gekoppelt mit der Nutzung von Mock Services, kann somit eine ausführbare Testsuite gemeinsam mit der Spezifikation veröffentlicht werden und ermöglicht so frühzeitig Fehler zu finden, dem Mantra des Shift Left Paradigmas.

Tiger eine Open-Source Plattform für Zeroline Testing

Auf Github veröffentlicht, haben wir versucht, diese Konzepte in der Tiger Testplatform umzusetzen. Tiger ist Open-Source, frei nutzbar und ermöglicht Fast-Code-less Testen im deutschen Gesundheitswesen. Eine Nutzung in anderen Bereichen bietet sich für alle Tester:innen an, die neue konzeptionelle Wege bei Ressourcenengpässen ausprobieren möchten.

Über den Autor

Thomas Eitzenberger ist derzeit bei der gematik für die Entwicklung von Testtools und -plattformen verantwortlich. Davor war er 15 Jahre als Freelancer in einer Vielzahl von Unternehmen als Testcoach und Hands-on Consultant tätig. Im Rahmen seiner Tätigkeiten hat er sich intensiv mit Testautomatisierung auf allen Teststufen beschäftigt.