RPA für Software-Testing nutzen: Ein strategischer Ansatz

Ineffektive Software-Testautomatisierung ist berüchtigt dafür, Releases zu verzögern, während sie unglaubliche Mengen an Ressourcen verbraucht.

Immer mal wieder taucht in meinem Newsfeed ein Artikel mit „Die Top 10 Life Hacks“ auf. Das sind Tipps und Tricks, wie man gewöhnliche Haushaltsprodukte auf unerwartete Weise nutzt, um das Leben zu verbessern – „…und Tipp Nr. 7 wird Ihren Verstand sprengen!!!“

Geständnis: Ich bin auf diesen Clickbait reingefallen. Ehrlich gesagt, gibt es Momente, in denen ich angenehm überrascht bin. Wer wusste zum Beispiel, dass man lästige Plastik-Blisterverpackungen mit einem Dosenöffner aufschneiden kann, oder eine Toilettenpapierrolle nutzen, um Geschenkpapier vom Abrollen abzuhalten?

Ich habe die beiden „Hacks“ oben ausprobiert – raten Sie was? Sie funktionierten „irgendwie“… für eine Weile. Der Dosenöffner schnitt durch die Naht, wo das Plastik verschweißt war, versagte aber beim Durchschneiden der Verpackungslänge. Die Toilettenpapierrolle hielt das Geschenkpapier eine Weile, aber letztlich schwächte sich der Karton ab und das Papier rollte sich ab. Nicht überraschend: Schere für Blisterverpackungen und ein kleines Stück Klebeband fürs Geschenkpapier funktionierten viel, viel besser.

In sehr ähnlicher Weise erwägen viele Organisationen jetzt, RPA für Software-Testautomatisierung zu nutzen – ein „Tech Hack“ für Software-Testing, gewissermaßen. Doch genau wie die Toilettenpapierrolle keine nachhaltige Lösung für mein Geschenkpapier-Problem bot, ist RPA keine nachhaltige Lösung für Software-Testautomatisierung – und die Modifikationen, die nötig wären, um das RPA-Tool für die Aufgabe der Software-Testautomatisierung nachhaltig zu machen, wären, nun ja, ein Hack.

Wenn Sie bereits ein RPA-Tool in Ihrer Organisation haben und mit Testautomatisierung starten wollen, mag Ihr RPA-Tool wie eine logische Wahl erscheinen. Es ist meist relativ einfach, grundlegende Testszenarien zu automatisieren (z. B. neuen User anlegen und Transaktion abschließen), Validierung hinzuzufügen und zu glauben, man sei auf dem Pfad zur Testautomatisierung.

Doch es ist wichtig zu erkennen: Erfolgreiche – und nachhaltige – Testautomatisierung erfordert weit mehr als die Fähigkeit, durch Applikationspfade zu klicken. Um den desaströsen Branchendurchschnitt bei Testautomatisierungsrate von <20 % zu überwinden, müssen Teams auch in der Lage sein, eine effektive automatisierte Testsuite zu konstruieren und zu stabilisieren. RPA-Tools sind meist nicht dafür designed, das zu ermöglichen. Als Ergebnis stoßen Sie auf Testautomatisierungs-Hürden wie Verzögerungen beim Warten auf erforderliche Testdaten und Testumgebungen, inkonsistente Ergebnisse, die Vertrauen in die Automatisierungsinitiative untergraben, und „aufgeblähte“ Test-Suites, die beträchtliche Ressourcen verbrauchen, aber kein klares, actionables Feedback liefern.

Für einen schnellen Überblick über den Unterschied im Scope zwischen RPA-Tools und Testautomatisierungs-Tools, vergleichen Sie folgende Definitionen von Gartner:

RPA-Tools „führen ‚if, then, else‘-Statements auf strukturierten Daten aus, typischerweise mittels Kombination aus User Interface (UI) Interaktionen oder durch Verbindung zu APIs, um Client-Server, Mainframes oder HTML-Code anzusteuern. Ein RPA-Tool operiert, indem es einen Prozess in der RPA-Tool-Sprache für den Software-‚Roboter‘ abbildet, dem er folgen soll, mit Runtime-Allokation zur Script-Ausführung durch ein Control Dashboard.“

Testautomatisierungs-Tools „ermöglichen einer Organisation, automatisierte funktionale Tests zu designen, entwickeln, warten, managen, ausführen und analysieren … Sie bieten Breite und Tiefe an Produkten und Features über den Software Development Life Cycle (SDLC). Das umfasst Test-Design und -Entwicklung; Test-Case-Wartung und -Wiederverwendung; Test-Management, Testdaten-Management, automatisiertes Testing und Integration – mit starkem Fokus auf Support für Continuous Testing.“

Die Notwendigkeit dieser zusätzlichen Testing-Fähigkeiten wird klar, wenn man einige Kernunterschiede betrachtet zwischen:

• Automatisieren von Task-Sequenzen in Produktionsumgebungen, um einen klar definierten Pfad durch einen Prozess erfolgreich auszuführen, damit Arbeit schneller erledigt wird, und
• Automatisieren realistischer Business-Prozesse in Testumgebungen, um zu sehen, wo eine Applikation versagt, damit man informierte Entscheidungen treffen kann, ob eine Applikation zu riskant für den Release ist

Was bedeuten diese Unterschiede für Software-Testing?

• Automatisierung muss in einer Testumgebung ausführen, die typischerweise unvollständig, sich entwickelnd und constrained ist
• Management von stateful, sicheren, compliant Testdaten wird zur riesigen Herausforderung
• Effektives Test-Case-Design ist essenziell für Erfolg
• Failures müssen Einblick in Business-Risiko geben

In konkreteren Begriffen: Betrachten wir das Testen eines Online-Reiseservices. Angenommen, Sie wollen die Funktionalität prüfen, die es einem User erlaubt, seine prepaid Hotelreservierung zu verlängern. Zuerst müssen Sie entscheiden, wie viele Tests nötig sind, um die Applikationslogik gründlich zu üben – und welche Datenkombinationen jeder braucht.

Dann müssen Sie alle Daten beschaffen und provisionieren, die nötig sind, um die Applikation in den State zu versetzen, wo das Test-Szenario ausführbar ist. In diesem Fall brauchen Sie (mindestens) einen existierenden User-Account mit einer existierenden prepaid Reservierung für ein zukünftiges Datum – und Sie könnten keine echten Produktionsdaten nutzen wegen Datenschutzregulierungen wie DSGVO.

Als Nächstes brauchen Sie einen Weg, den erforderlichen Bereich an Responses vom verbundenen Hotel-Reservierungssystem (Zimmer verfügbar/nicht verfügbar), der Kreditkarte (Transaktion genehmigt/abgelehnt) etc. aufzurufen – aber ohne tatsächlich ein Zimmer zu reservieren oder eine Kreditkarte zu belasten.

Sie müssten den Prozess automatisieren – natürlich. Das involviert Einloggen, Abrufen der existierenden Reservierung, Anzeigen, dass Sie sie modifizieren wollen, dann die Verlängerungslänge spezifizieren.

Sobald Sie den kompletten Prozess automatisiert haben, müssten Sie eine Anzahl Validierungen an verschiedenen Checkpoints konfigurieren. Wurden die appropriaten Details im appropriaten Message-Format an das Hotel gesendet? Wurde die Reservierung in Ihrer User-Datenbank aktualisiert? Wurden Zahlungsdaten korrekt an den Kreditkartenanbieter gesendet? Wurden Account-Credits angewendet? Erhielt der User eine appropriierte Message, wenn die Reservierung nicht verlängert werden konnte? Was, wenn die Kreditkarte abgelehnt wurde? Und wenn die Kreditkarte abgelehnt wurde – hat Ihr System auf die ursprüngliche Reservierungslänge zurückgesetzt, statt zusätzliche Nächte hinzuzufügen, die nicht tatsächlich bezahlt wurden?

Stellen Sie sich vor, Ihr Unternehmen entscheidet, eine 10-$ Änderungsgebühr für alle prepaid Reservierungen einzuführen. Könnten Sie diese neue Anforderung einfach in Ihre existierenden automatisierten Tests einschieben – oder müssten Sie jeden einzelnen Test substanziell überarbeiten, um diese kleine Änderung zu akkommodieren?

Schon dieses einfache Beispiel deckt einige der vielen Software-Testing-Komplexitäten auf, die RPA-Tools schlicht nicht designed sind, anzugehen. RPA-Tools sind gebaut, um spezifische Tasks innerhalb einer Sequenz zu automatisieren. Software-Testautomatisierungs-Tools sind designed, die Resilienz einer breiteren Task-Sequenz zu messen. Klar gesagt: RPA-Tools sind architektiert, einen Prozess zum Laufen zu bringen. Aber für Software-Testing brauchen Sie Tools, die Ihnen helfen zu bestimmen, wie ein Prozess möglicherweise brechen kann.

Ineffektive Software-Testautomatisierung ist berüchtigt dafür, Releases zu verzögern, während sie unglaubliche Mengen an Ressourcen verbraucht. Da CIOs immer mehr in Digital-Transformation-Initiativen investieren, die Kundenerlebnis durch schnellere Software-Delivery verbessern, ist Sparen bei Software-Testing kontraproduktiv. Die Wahl des richtigen Tools für den Job zahlt sich signifikant aus in beschleunigter Delivery, reduziertem Business-Risiko und mehr Ressourcen für Innovation.

Wayne Ariola ist Autor von „Continuous Testing for IT Leaders“ und bekannter Keynote-Speaker im DevOps- und App-Dev-Space.