Testautomatisierung in der Praxis – Erfahrungen mit SoapUI im Public Umfeld

Die Qualitätssicherung ist ein etabliertes Beratungsinstrument, das in Softwareentwicklungsprojekten nicht mehr wegzudenken ist. Sie minimiert Softwarerisiken und kann einen essentiellen Beitrag zur nachhaltigen Steigerung der Softwarequalität leisten. Allerdings hat die Qualitätssicherung auch eine Kehrseite, denn neben den Vorteilen, birgt sie ebenfalls Problemfelder und Herausforderungen. Diese machen sich insbesondere bei einem erhöhten manuellen Testaufwand – beispielsweise durch sich unzählig zu wiederholende manuelle Testausführungen – bemerkbar. Als Folge können dadurch enorme Ineffizienzen und Qualitätseinbußen im Testen eintreten – so gesehen ein Tanz auf Messers Schneide, von dem sich auch das Public-Umfeld nicht freisprechen kann. Als probates Mittel in diesem Zusammenhang erscheint die Einführung von Testautomatisierungslösungen sinnig.

Aber welches Heilmittel kann hier Abhilfe schaffen? Wir haben SoapUI Pro als das Mittel zur Bewältigung der Probleme und Herausforderungen identifiziert und möchten euch in unserem Blog-Beitrag unsere Erfahrungen schildern. Dabei sind wir folgenden Fragestellungen nachgegangen: Was bedeutet Testautomatisierung? Warum überhaupt SoapUI Pro? Wie haben wir eine Testautomatisierungslösung mit Hilfe von SoapUI Pro strukturiert aufbauen und integrieren können? Und was waren die Lessons learned?

Testautomatisierung macht doch jeder, oder? Jein

Es gibt triftige Gründe, ein Verfahren kaum, partiell oder vollumfänglich an die Testautomatisierung heranzuführen. Die Vor- und Nachteile sollten stets individuell abgewogen werden, wie im Folgenden erkennbar ist.

Vorteile

• Hohe Zeitersparnis
• Minimierung von Qualitätsrisiken
• Gesteigerte Motivation von Testern
• Gegebenenfalls verbesserte Testabdeckung

Nachteile

• Hoher initialer Ressourcenaufwand
• Hohe Kompetenz- und Wissensanforderung
• Wiederkehrender Anpassungsbedarf bei neuen Releases und wechselnden Sicherheitseinstellungen
• Teilweise Überzeugungsarbeit nötig

Testautomatisierung sollte vor allem dann in Betracht gezogen werden, wenn sich Defizite abzeichnen - wie etwa ein hoher Grad an sich wiederholenden manuellen Testsets, lange Testausführungszeiten, unzureichende Testkapazitäten oder eine hohe Frustration bei Fachtestern durch repetitive, wenig abwechslungsreiche Aufgaben. Ob Testautomatisierung jedoch ohne weiteres eingeführt werden sollte und welchen Nutzen sie generiert, hängt, neben den genannten Defiziten, ebenfalls von weiteren Anforderungsbereichen ab. Diese werden wir noch weiter thematisieren.

Ein konkretes Tool, um ein Testautomatisierungsvorhaben umzusetzen, ist das Testwerkzeug SoapUI Pro. Es dient als Werkzeug für automatisierte Integrationstests von Schnittstellen sowie zum Testen weiterer Webservices. Mittlerweile gehört SoapUI Pro zur etablierten Tool-Suite der ReadyAPI-Plattform (ReadyAPI versteht sich als tool-übergreifende API-Qualitätsplattform).

WSDL (Web Service Definition Language) Dateien können als zentrales Feature genutzt und direkt in SoapUI importiert werden. Dies ermöglicht eine übersichtliche Darstellung über die zu testenden Schnittstellen, die anschließend mit Hilfe von verschiedenen Standardkomponenten - beispielsweise den Testschritten (REST- und JDBC-Request, Property Transfer, Conditional Goto, Run TestCase, Groovy Skript u.v.m.) - flexibel und individuell getestet werden können. Der grundlegende Aufbau eines SoapUI-Projektes folgt der Struktur, dass Testschritte in Testcases und Testcases in Testsuites organisiert sind. Es lassen sich beliebige Testschritte in einem Testcase kombinieren und über ein leichtgewichtiges und intuitives Assertion System hinsichtlich der zu erwartenden Ergebnisse prüfen.

Unterstützt SoapUI einen spezifischen Testschritt nicht, kann über eingebundene Java Dateien oder individuell aufgebaute Groovy Skripte der Funktionsumfang erweitert werden.

Was hat uns beim öffentlichen Auftraggeber erwartet? Und wie wurden wir an das Thema Testautomatisierung herangeführt?

Vorgefunden haben wir in unserem Verfahren einen bereits strukturierten und etablierten Testprozess. Optimierungsbedarfe in Struktur und Ablauf konnten kaum identifiziert werden. Es wirkte sehr eingespielt und harmonisch – eine sehr solide Basis, an die wir dankbar anknüpfen konnten.

Gleichwohl ließ sich ein ganz anderes Potenzial rasch ausmachen, das eher bei den eingesetzten Testwerkzeugen verortet war. Diese waren zum Teil veraltet und wiesen nur sehr geringe Automatisierungsanteile auf. Kurzum: es wurde sehr viel manuell getestet, das Feld der Testautomatisierung war noch nicht weit erschlossen und die notwendigen technisch-infrastrukturellen sowie organisatorischen Voraussetzungen (etwa Freigaben, Lizenzen und Zertifikate) noch nicht erfüllt. Nach langer Überzeugungsarbeit (auch durch den vorangegangenen Dienstleister) und viel Geduld konnte jedoch die Umstellung von der SoapUI Open Source auf SoapUI Pro initiiert werden. Das ermöglichte uns nicht nur, die vorher eingesetzten veralteten Testwerkzeuge für obsolet zu erklären und damit auch die Anzahl der Tools zu reduzieren, sondern primär unentdeckte Funktionalitäten von SoapUI zu nutzen. Schließlich stand uns nun ein schier grenzenloser Funktionsumfang durch die Lizenzierung von SoapUI Pro zur Verfügung. Das Ufer zur Testautomatisierung schien in greifbare Nähe zu rücken.

War das also schon die halbe Miete? Natürlich nicht! Denn es lag noch ein weiter und steiniger Weg vor uns. Es sollten gleich mehrere Schnittstellen zu diversen Nachbarsystemen mit Hilfe eines Regressionstest vollständig automatisiert getestet werden. Aber wie startet man hier überhaupt? Was muss beachtet werden? Und wie kann man einen systematisierten Prozess aufsetzen, der sich von der Planung, dem Aufbau über die Entwicklung und Integration bis hin zur Inbetriebnahme eines übergabe- und lauffähigen automatisierten Schnittstellen-Regressionstests erstreckt? Die Antworten darauf finden sich in dem von uns entwickelten 4-Phasen-Modellansatz wieder und sollen im Folgenden sukzessive ausgeführt werden.

Einführung einer SoapUI Pro basierten nachhaltigen Testautomatisierungslösung mithilfe eines 4-Phasen-Modellansatzes

Der Statuscheck

Nachdem die notwendigen technisch infrastrukturellen sowie organisatorischen Rahmenbedingungen erfüllt waren, mussten weitere Anforderungsbereiche adressiert werden. Hierfür eignet sich der erste Schritt des 4-Phasen-Modells, der Statuscheck. In einer sogenannten Reifegradprüfung unterzogen sich der Fachbereich und das Verfahren allgemeinen qualitativen Fragestellungen. Das Ziel dieser Reifegradprüfung besteht darin, eine grundlegende Einschätzung darüber zu bekommen, ob und gegebenenfalls wie weit beziehungsweise „reif“ das Verfahren und/oder der Fachbereich für die potentielle Einführung von Testautomatisierungslösungen ist. Das qualitative Assessment soll Fragestellungen aus folgenden Anforderungsbereichen adressieren: Fachlich technische Anforderungen, vorhandene Tools, Mitarbeitende und Kompetenzen, Organisation und Kultur, Aufbau des Testprozesses. Das Ergebnis ist eine grobe Handlungsempfehlung sowie ein potentieller Maßnahmeplan über die nächsten To Do’s und Arbeitsschritte. In unserem Fall war das Ergebnis eindeutig: Das Testautomatisierungspotenzial bei unserem Verfahren war – aufgrund der bereits geschilderten Defizite – enorm. Wir konnten also sofort mit der inhaltlichen Arbeit beginnen!

Die Analyse

Der anschließende Arbeitsschritt, die Analyse, verlangte uns schon wesentlich mehr Manpower und Tatkraft ab. Basierend auf den fachlichen Dokumenten, die während des Statuschecks ermittelt wurden, wurde eine eingehende Anforderungsanalyse durchgeführt. Im Zentrum der Prüfung standen insbesondere System- und Schnittstellenspezifikationen sowie weitere systemrelevante Dokumente. Da die Fachdokumente sehr umfangreich waren und aus diesem Grund diverse Inhalte mehrfach priorisiert und reduziert werden mussten, war die enge und stete Abstimmung mit dem Fachbereich unabdingbar. Schließlich wollten wir nicht an den Interessen unserer Stakeholder „vorbeiarbeiten“. Neben der Prüfung der Fachdokumente waren zudem die Untersuchung und der anschließende Aufbau des SoapUI-Testautomatisierungsframeworks integraler Bestandteil der Analyse. Das Framework sollte als Hülle fungieren und die notwendigen technischen Voraussetzungen für die spätere Integration schaffen. Das Ergebnis: Ein – mit zugegebenermaßen viel Fleiß, Scharfsinn und Durchhaltevermögen verbundenes – ausgearbeitetes Fachkonzept mit dedizierten Testfallblöcken sowie ein initial aufgebautes SoapUI-Testautomatisierungsframework.

Die Integration

Nachdem die Analyse erfolgreich abgeschlossen war, konnte mit der Integration gestartet werden. Die Arbeitsschritte umfassten die Übertragung des Fachkonzepts in das bereits vorbereitete SoapUI-Grundgerüst (dem Testautomatisierungsframework) sowie zahlreiche iterative Verprobungen der zu integrierenden Testfall-Suites und -Cases. Im gesamten Verlauf der Integration konnten wir feststellen, dass sich das iterative Vorgehen bei der Verprobung sehr bewährt hat. Die Integration der dedizierten Testsuites und -Cases ging mit der iterativen Verprobung quasi Hand in Hand. So konnten kleine technische Unwägbarkeiten und Stolpersteine schnell im Vorfeld identifiziert und korrigiert werden. Was konnten wir am Ende der Integration vorweisen? Den initialen Piloten eines ausführbaren automatisierten Schnittstellen-Regressionstests – ein hartes Stück iterative Arbeit.

Die Ausführung und Adaption

Der Schnittstellen-Regressionstest war also geboren und konnte in der letzten Phase, der Ausführung und Adaption, durchgeführt werden. Die frühzeitige Verprobung einzelner Testblöcke hatte sich jetzt ausgezahlt, denn der Piloten-Regressionstest erwies sich als robust und zuverlässig. Ein toller Erfolg nach wochenlanger Arbeit, die in dieses Projekt investiert wurde. Also ein Grund zum Jubeln? Jein! Auf der einen Seite waren wir natürlich zufrieden und kurzzeitig glückselig, auf der anderen Seite musste sichergestellt werden, dass der Test mit jedem Auslieferungszyklus und Release nicht nur ausgeführt, sondern auch systematisch weiterentwickelt wird. Hier hat sich das iterative Vorgehensmodell erneut bewährt. Denn der Regressionstest versteht sich natürlich nicht als ein statisches Konstrukt, sondern muss vielmehr mit der Weiterentwicklung des Verfahrens dynamisch adaptiert werden und heranwachsen: Das „Baby“ war geboren, lernte schnell laufen und wurde mit der Zeit – also Release für Release – reifer und ansehnlicher.

Das Training und Coaching

Ein nicht zu vernachlässigender Parallelstrang, der abschließend unbedingt erwähnt werden sollte, ist das sich über den gesamten Arbeitsverlauf erstreckende Training und Coaching. Es ist für uns Consultants essentiell, den Kompetenzaufbau und Wissenstransfer proaktiv zu fördern, um beim Kunden Anschlussfähigkeit und Nachhaltigkeit zu gewährleisten. Was bedeutet das im Klartext? Wir möchten nicht nur ein Arbeitsergebnis übergeben, sondern die Lösung beim Kunden auch langfristig und nachhaltig im Alltag organisatorisch verankern. Das ist an dieser Stelle keineswegs eine abgedroschene Phrase, vielmehr ein essentieller Bestandteil unserer operativen Arbeit gewesen. Wir haben festgestellt, dass viele Kolleginnen und Kollegen, sowohl intern als auch extern, sehr heterogene Erfahrungs- und Wissensstände vorwiesen und demnach bedarfsgerecht an das Thema herangeführt werden mussten. Demnach galten flankierende und individuelle Schulungsmaßnahmen und Coaching-Angebote als i-Tüpfelchen des 4-Phasen-Modells.

Unser Fazit

Wir können sagen, dass wir unsere ersten Meter auf dem Weg des automatisierten Testens erfolgreich bestritten haben. Dabei hat sich die stets enge Zusammenarbeit zwischen IT- und Fachbereich sowie unserem adesso Team als der wichtigste Erfolgsfaktor ausgezahlt. Der 4-Phasen-Modellansatz hat als solide Basis für eine geordnete Projektstruktur und -durchführung fungiert und die wesentlichen Anforderungen und Stakeholder-Interessen berücksichtigt.

So wird derzeit und infolge unseres initialen Impulses bei verschiedenen Fachbereichsverfahren unser Ansatz zur Einführung einer Testautomatisierungslösung aufgegriffen und diskutiert. Eine standardisierte übertragbare Lösung „aus dem Regal” kann es zwar aufgrund der individuellen Rahmenbedingungen in den jeweiligen Verfahren nicht geben, dennoch konnten wir eine valide und vorzeigbare Referenz aufbauen und eine Pionierstellung einnehmen. Die Folge: Hoch interessierte Fachbereiche, erste Gespräche, sowie konkrete Überlegungen für einen potentiellen Einsatz einer Testautomatisierungslösung basierend auf unserem Ansatz.

Als wir vor Monaten unsere Arbeit aufnahmen, haben wir einen Nachteil besonders zu spüren bekommen: Den hohen initialen Ressourcenaufwand. Die anfängliche nicht zu unterschätzende und langwierige Mehrarbeit bei der Einführung unserer Testautomatisierungslösung hatten wir zwar erwartet, jedoch nicht in dem Umfang antizipieren können. Hohe Anforderungen an einen sensiblen Sicherheitsbereich (ständige Zertifikats- und Credential-Wechsel aufgrund begrenzter Gültigkeitsdauer), die sich zu Anfang unserer Arbeit verschärfende Corona Situation (wenige Präsenztage, eingeschränkte Verfügbarkeiten unser internen Fachbereichskollegen, umständlich zu organisierende Termine) sowie eine besondere technische Infrastruktur wirkten dabei als zusätzliche Aufwandstreiber. Wir waren zugegebenermaßen etwas überrascht vom Mehraufwand.

Dem gegenüber steht mittlerweile der große Aspekt der Zeitersparnis, die besonders nach Inbetriebnahme der Testautomatisierungslösung greift und unsere anfängliche Überraschung über den Mehraufwand zunehmend kompensiert. Nachdem die Testautomatisierungslösung aufgebaut, entwickelt und zur Ausführung übergeben wurde, konnten wir mit zunehmender Zeit und mit viel Freude feststellen, dass sich die eigentlich erwartete Zeitersparnis realisiert hat. Der anvisierte Return of Investment (ROI) hat sich eingestellt.

Perspektivisch werden wir das Thema Testautomatisierung proaktiv weiter gestalten, die Übertragbarkeit auf andere Einsatzfelder prüfen und intern mit unserer aufgebauten Referenz hausieren gehen. Unser Ziel ist es, das Portfolioelement Testautomatisierung sowohl fachverfahrensübergreifend organisatorisch zu verankern als auch anderen Kunden aus dem Public-Umfeld mit dieser Referenz beratend zur Verfügung zu stehen. Zudem werden wir zukünftig unser Portfolio im Bereich der Testautomatisierung weiter ausbauen. Neben der automatisierten Testauswertung und –dokumentation mittels Zephyr/ZAPI bieten sich beispielsweise automatisierte GUI-Tests an, die mit Hilfe der Testtools Tosca, PowerBuilder IO oder Silenium ausgeführt werden. Auch eine Ausweitung in dem Bereich der Last- und Performancetests ist angedacht. Also bleibt für uns zu sagen: “Fortsetzung folgt”.

Ihr braucht Unterstützung beim Thema Testautomatisierung mit SoapUI - schreibt uns gerne an und wir versuchen Euch zu helfen.