Automatisierung - ja, aber wie? Über Testautomatisierung und RPA

Testautomatisierung und RPA sind beides sehr ähnliche Technologien mit dahinterliegenden Vorgehensmodellen, welche im Kern repetitive und für Menschen auf Dauer langweilige Arbeitsaufgaben durch Computerprogramme ablösen wollen. Inwiefern diese sich unterscheiden und welche Gemeinsamkeiten sie aufweisen, soll in diesem Grundlagenartikel herausgestellt werden. Dieses soll helfen, Klarheit darüber zu erlangen, welcher Typ der Automatisierung für Sie interessant sein kann.

Eine Definition der beiden Begriffe

Der renommierte Anbieter von Marktforschungsergebnissen und Analysen über die Entwicklungen in der Informationstechnologie, Gartner, definiert Robotic Process Automation in seinem IT-Glossar frei übersetzt wie folgt. “RPA ist ein Tool, welches es dem Benutzer erlaubt ein oder mehrere Skripte (einige Toolhersteller nennen diese auch Robots oder kurz Bots) zu erstellen, welche Aktionen am Computer automatisiert durchführen. Das Resultat ist, dass diese Bots ausgewählte Aufgaben (Transaktionsschritte) innerhalb eines Prozesses nachahmen bzw. emulieren können. Diese Schritte können die Manipulation, die Weitergabe bzw. den Empfang von Daten zwischen verschiedenen Applikationen oder das Ausführen von Transaktionen beinhalten. RPA nutzt dazu eine Kombination aus User Interface (UI) Interaktionen und Descriptor-Technologien (Anm. des Verfassers: z. B. XPATH für Web).“

Wikipedia kommt zu einer kürzeren, aber durchaus gleichartigen Definition unter Verwendung leicht anderer Begrifflichkeiten: „Robotergesteuerte Prozessautomatisierung (auch Robotic Process Automation, RPA) ist ein Ansatz zur Prozessautomatisierung, bei dem manuelle Tätigkeiten durch sogenannte Softwareroboter erlernt und automatisiert ausgeführt werden. Softwareroboter emulieren die Eingaben auf der bestehenden Präsentationsschicht (UI) einer Anwendungssoftware.“

Beide Definitionen beziehen sich dabei vorwiegend auf die technische Realisierung von RPA, die hauptsächlich durch Nachahmung von Benutzerverhalten am Computer erreicht wird.

Unter Testautomatisierung versteht man laut Wikipedia kurz und bündig „die Automatisierung von Aktivitäten im Software Test“. Meistens ist damit die Ausführung automatisierter Testfälle in der Phase der Testdurchführung unter Ablösung manueller Tests gemeint. Natürlich gehört dazu auch das Erstellen von Testskripten oder Testautomaten, welche die in einem Testfall vorgesehenen Benutzeraktionen auf der Präsentationsschicht (UI) in der zu testenden Anwendungssoftware durchführen. Bei moderner Software-Entwicklung umfassen Software-Tests weitere, kleinteiligere Testautomaten, welche nicht über die Präsentationsschicht interagieren.

Die verschiedenen Arten automatischer Tests werden gemäß des V-Modells nach ihrer Granularität gegliedert und häufig in der sogenannten Testpyramide dargestellt, welche einen Eindruck über die optimale Mengenverteilung der unterschiedlichen Testarten vermitteln soll. Dabei nimmt die Anzahl mit zunehmender Komplexität ab.

Ähnlichkeiten zwischen RPA und Testautomatisierung

Sofern man die Automatisierung von Usereingaben über eine grafische Benutzeroberfläche betrachtet, kommen sowohl bei der Testautomatisierung (TA) als auch bei Robotic Process Automation (RPA) dieselben Technologien zum Einsatz. Hierfür können sogar dieselben Tools eingesetzt werden.

Beide Disziplinen wollen grundsätzlich Abläufe automatisieren, insbesondere solche, die

• repetitiv und für Menschen langweilig sind,
• hohe Kosten verursachen, wenn man diese hochskaliert,
• Risiken durch menschliche Fehleingaben beinhalten,
• nach festen Regeln arbeiten.

Ähnlichkeiten zwischen TA - insbesondere bei UI-basierten oder sogenannten Ende-zu-Ende (E2E) Tests - und RPA bestehen insbesondere darin, dass sie grafische Elemente der Benutzerführung suchen und klicken, um damit menschliches Nutzerverhalten zu simulieren. Ähnlichkeiten gibt es auch für darunterliegende Schichten der oben erwähnten Testpyramide. Allerdings sind Unit Tests auf der untersten Ebene der Testpyramide aus Prozesssicht für RPA schlichtweg uninteressant, da diese zu atomar und kleinteilig sind sowie selten über eine Business Aussage verfügen. Schließlich ruft ein Fachmitarbeiter auch nicht Methodenbausteine innerhalb einer Schnittstelle einer Anwendungssoftware auf und befüllt diese händisch. Für die Testautomatisierung stellen diese sehr entwicklungsnahen und in der Regel schnell-laufenden Tests (da keine vollständigen Umgebungen wie Datenbanken, Applikationsserver usw. gestartet werden müssen) das adäquate Mittel dar, um einem Entwickler ein schnelles, genaues und leicht überprüfbares Feedback bzgl. seiner Codequalität zu liefern.

In der Testautomatisierung ist es ebenfalls sehr wichtig, dass automatisierte Testfälle in Reihenfolge und Ergebnis voneinander unabhängig sind (also nicht auf anderen Tests aufbauen), um singuläre Ergebnisse zu erzielen und Fehlerkaskaden zu vermeiden. In der Praxis gelingt dieses nicht immer, aber zumindest verfolgt man dieses Prinzip, soweit es wirtschaftlich sinnvoll ist. RPA dagegen verfolgt einen holistischen Ansatz und strebt nach Umsetzung ganzheitlicher Geschäftsprozesse. Hier ist es sogar unabdingbar, die Dinge nacheinander, teilweise asynchron in der richtigen Reihenfolge zu tun. In der Praxis versucht man aber trotzdem, Arbeitsschritte insoweit zu isolieren, dass bei Fehlern nicht die komplette Kette wieder von vorne durchlaufen werden muss, sondern jedes Glied möglichst unabhängig agiert. Obwohl diese Herangehensweisen vom Grundsatz verschieden sind, nähern sie sich in der Praxis sehr an.

Beide Disziplinen arbeiten darüber hinaus mit Daten, die durch die Transaktionen und Prozesse verändert werden. Bei der Testautomatisierung handelt es sich dabei in der Regel um Testdaten, die entweder artifiziell erstellt oder aus Produktivdaten gewonnen werden. RPA arbeitet direkt auf produktiven Daten.

Beide Disziplinen streben gemeinsam danach, so viele Bots oder Automaten in so kurzer Zeit wie möglich zu betreiben, u. a. um Ausführungszeiten zu minimieren. Daher spielen Deploymentverfahren, Skalierung und Parallelisierung eine wichtige Rolle.

Weitere Ähnlichkeiten, auf die ich im letzten Abschnitt genauer eingehe, bestehen im Vorgehensmodell der Einführung von Testautomatisierung und RPA.

Unterschiede zwischen RPA und Testautomatisierung

Der wohl signifikanteste Unterschied ist, dass Testautomatisierung im Kontext von Test Umgebungen mit Testdaten angewendet wird, während RPA auf Produktivsystemen mit Produktivdaten arbeitet. Damit sind alleine die Sicherheits- und Stabilitätsanforderungen, aber auch formale und juristische Anforderungen an ein RPA-System grundsätzlich höher. Aus diesem Grund sind RPA-Lösungen wesentlich mehr darauf bedacht, alle durchgeführten Änderungen detailliert in sogenannten Audit Trails zu protokollieren. Technisch ließe sich dieses auch auf Testsystemen umsetzen, wäre dort aber in den meisten Fällen völlig überflüssig, da die Testdaten i. d. R. nicht schützenswert sind und durch Tests sowieso verbraucht werden. Auch sicherheitstechnische Regeln wie das sichere Ablegen von Passwörtern, das Setzen verschiedenster Rechte und Rollen ist ein Muss in einem RPA System, während es in Testsystemen lediglich gute Praxis darstellt.

Ein offensichtlicher Unterschied besteht auch in der Zielsetzung. Mit dem Ziel der Qualitätssicherung steht bei TA im Vordergrund, die repetitive und mit wachsendem Funktionsumfang potenziell steigende Anzahl an Regressionstests stabil auszuführen. Manuell wäre dieses gerade in agilen Projekten mit kurzen Sprintzyklen niemals möglich. Man denke hier auch an CI/CD (Continous Integration / Continous Deployment) Pipelines, die sofort nach Fertigstellen des Codes Rückmeldung an den Entwickler über die Qualität seiner Arbeit liefern. RPA hat dagegen die Ausführung produktiver Aufgaben zum Ziel. Damit verbindet sich mit RPA häufig eine sehr schnelle, klare und einfach quantifizierbare ROI (Return On Investment) Aussage, während Testautomatisierung / Qualitätssicherung immer noch fälschlicherweise als notwendiges Übel gesehen wird, u.a. weil ein ROI häufig schwerer zu quantifizieren ist.

Ein weiterer Unterschied besteht darin, dass Testsysteme mehrere Teststufen beinhalten, in denen die zu testende Applikation gestaged wird. RPA Code läuft dagegen nur auf einem oder mehreren gleichartigen, produktiven Zielsystemen. Dafür ist es bei RPA Code wesentlich relevanter, diesen mit dem System, auf dem es genutzt, wird zu stagen. Innerhalb von Testsystemen kann ein Test auch mal fehlschlagen, korrigiert und dann wiederholt werden. In einem Produktivsystem kann eine Fehleingabe durch falsche Roboteranlernung zu einer Kaskade an Problemen, aufwändigen Fehleranalysen und Umsatzeinbußen führen.

Folgendes erlebe ich häufig in der Praxis: Zum Themengebiet Test und Testautomatisierung existiert eine sehr ausgeprägte Taxonomie. In Testautomatisierungsprojekten kann man somit bereits heute mit Kunden auf ein Grundgerüst an Definitionen und Begrifflichkeiten zurückgreifen. RPA-Methoden sind in der Fachliteratur noch kaum mit einheitlichen Begrifflichkeiten verankert, was sich alleine in den verschiedenen Bezeichnungen für die kleinen Softwarehelfer widerspiegelt: Skript, Bot, Roboter, Automat sind alles Bezeichnungen für ein und dasselbe. Die IEEE hat hier eine erste Taxonomie festgelegt und im letzten Jahr den „P2755.1™/D1.1  Draft Guide for Taxonomy for  Intelligent Process Automation Product Features and Functionality“ vorgelegt, um Interessenten eine bessere Vergleichbarkeit von Produktmerkmalen an die Hand zu geben.

Ein Tool, sie alle zu bedienen – fragen Sie die viadee

Eine erfolgreiche, digitale Transformation benötigt die richtigen Tools. Der viadee Roboter, mateo rpa, ist für nicht-technische Anwender ausgelegt und ermöglicht unseren Kunden Software-Roboter für sich wiederholende Tätigkeiten zu erstellen.  Dieses erhöht die Produktivität und macht Mitarbeiter frei für herausfordernde Aufgaben. Zusätzlich bietet der viadee Roboter erweiterte Tracking, Sicherheits- und Kommunikationsfeatures.

Die Kerntechnologie der Ansteuerung von Oberflächen ist im viadee Roboter identisch zu mateo, dem Tool zur Testautomatisierung (ehemals viadee Test Framework vTF), welches mit anderer Zielsetzung und anderer Feature-Ausstattung schon heute bei vielen Kunden Regressiontests automatisiert und so Zeit für exploratives und produkthinterfragende Tests schafft.

Die beste Methode für nachhaltigen Erfolg ist eine solide Einführungsstrategie

In jedem IT-Projekt ist es zu Beginn von entscheidender Bedeutung, die IT, das Management und betroffene Fachbereiche zusammenzubringen, um Prozesse mit hohem Beispielcharakter für einen ersten PoC auszuwählen, Erwartungshaltungen abzugleichen, Ziele zu definieren und diesen Prozess kontrolliert mit Experten zu begleiten. Dieses gilt sowohl für Testautomatisierungs- als auch für RPA-Projekte. Allerdings existieren aufgrund der Unterschiede in den eingesetzten Umgebungen und den daraus resultierenden Anforderungen unterschiedliche Schwerpunkte. Für Testautomatisierung hat die viadee bereits ein 6 Punkte Erfolgsprogramm auf Basis von Erfahrungen aus vielen Projekten entwickelt. Für RPA ist dieses Vorgehensmodell sehr ähnlich, besitzt aber zum einen eine unterschiedliche Terminologie und weicht zum anderen bzgl. der Intensität einzelner Schritte ab.

Üblicherweise ist z. B. beim Abprüfen der Rahmenbedingungen bei RPA-Projekten wesentlich mehr Sorgfalt und Abstimmung notwendig, weil man in produktive Umgebungen eingreift und auch formal sehr früh wesentlich höhere Anforderungen an Betrieb und Sicherheit stellt als an ein Testsystem. Dagegen fällt die Analysephase aufgrund einer geringeren Granularität und der nicht geforderten Vollständigkeit der funktionalen Überdeckung häufig einfacher aus. Standardprozesse mit einigen häufigen Varianten sind hier ausreichend. Ausgiebige Qualitätsprüfungen von Fehlerszenarien bis auf Feldebene werden z. B. nicht umgesetzt. Hier reicht bisweilen sogar eine Konzentration auf besonders hochfrequente und damit profitträchtige Arbeitsabläufe. Dafür ist im Schritt der Entwicklung wesentlich mehr zu beachten, da nicht nur UI-Elemente bedient werden müssen, sondern zusätzlich aussagekräftige Audit Trails, Compliance Regeln, Datenschutz oder IT-Sicherheitsbestimmungen beachtet werden müssen. Damit steigt normalerweise auch die Anzahl an fachlichen Experten, welche für eine finale Optimierung mit einbezogen werden müssen. Oben ist das Erfolgsmodell einer RPA-Einführung dargestellt. Man sollte an dieser Stelle nicht vergessen, dass fertige Automatisierung – ob RPA oder Testautomatisierung – nicht „auf ewig“ Bestand hat, sondern wie jede Software durch Updates des Frameworks selbst oder Updates der unterliegenden Anwendungen regelmäßig gewartet werden muss. Testskripte sind genauso Programmiercode wie die Anwendungen, die durch den Automatisierungscode gesteuert werden. Die viadee bietet daher immer einen Wartungsvertrag mit an, entweder um das Framework selber auf dem aktuellsten Stand zu halten oder um die erstellten Testskripte an neuere Releases der Kundensoftware anzupassen.