RPA und Testautomatisierung — verwandt, aber nicht dasselbe
von Rainer Haupt
Robotic Process Automation (RPA) automatisiert Geschäftsprozesse. Testautomatisierung prüft, ob Software korrekt funktioniert. Beide klicken Oberflächen, füllen Formulare aus und lesen Ergebnisse ab. Die Werkzeuge sehen sich zum Verwechseln ähnlich. Trotzdem lösen sie unterschiedliche Probleme.
Seit UiPath 2020 seine Test Suite lancierte und Gartner 2025 den ersten Magic Quadrant für «AI-Augmented Software Testing Tools» veröffentlichte, verwischen die Grenzen weiter. Dieser Artikel sortiert, was zusammengehört und was nicht.
Dieselbe Technik, ein anderes Ziel
Ein RPA-Bot öffnet SAP, liest eine Bestellnummer, gleicht sie mit einer Excel-Liste ab und legt eine Buchung an. Er tut das, weil ein Mensch die Aufgabe nicht mehr manuell erledigen soll. Das Ziel ist Prozesseffizienz.
Ein Testfall öffnet dieselbe SAP-Transaktion, gibt eine bekannte Bestellnummer ein und prüft, ob die Buchung das erwartete Ergebnis liefert. Er tut das, weil jemand sicherstellen muss, dass die Software nach einem Update noch korrekt arbeitet. Das Ziel ist Qualitätssicherung.
Technisch passiert fast dasselbe: UI-Interaktion per Selektor, Dateneingabe, Ergebnisvergleich. Der Unterschied liegt im Zweck. RPA fragt: «Wurde der Prozess erledigt?» Testautomatisierung fragt: «Verhält sich die Anwendung korrekt?»
Was RPA-basiertes Testing konkret bedeutet
Anbieter wie UiPath nutzen ihre RPA-Infrastruktur (Studio, Orchestrator, Robots) auch für Testszenarien. Der entscheidende Punkt: Bot und Testfall bestehen aus denselben Bausteinen. Dieselben Selektoren identifizieren UI-Elemente, derselbe Credential Store verwaltet Anmeldedaten, derselbe Orchestrator plant die Ausführung. Bei getrennten Werkzeugen (RPA in UiPath, Tests in Tricentis oder Selenium) existieren zwei parallele Infrastrukturen mit doppelter Wartung.
Drei Szenarien zeigen, wo das praktisch relevant wird.
Ein RPA-Bot prüft sich selbst. Eine Versicherung betreibt einen Bot, der Schadenmeldungen aus E-Mails in ein Kernsystem überträgt. Nach einem Update des Kernsystems muss geprüft werden, ob der Bot noch funktioniert. Ohne RPA-Testing bräuchte das QA-Team ein separates Test-Tool, das die gleiche Oberfläche mit eigenen Selektoren und eigener Verbindung ansteuert. Mit RPA-Testing wird derselbe Workflow um Assertions ergänzt (etwa «Schadenfall-ID ist nicht leer» oder «Status nach Übertragung = angelegt») und als Testfall über den Orchestrator eingeplant. Keine doppelte Infrastruktur, keine doppelte Selektor-Pflege.
SAP-Regressionstests ohne Spezialtool. Ein Industrieunternehmen führt monatlich SAP-Transporte durch. Vor jedem Transport sollen 80 Testfälle über SAP GUI laufen. Die RPA-Plattform kennt die SAP-Oberfläche bereits, weil andere Bots dort Buchungen automatisieren. Dieselben UI-Elemente, Anmeldedaten und Verbindungen werden für Tests wiederverwendet. Die Change-Impact-Analyse zeigt, welche Testfälle vom Transport betroffen sind. Ohne den RPA-Kontext müsste ein separates SAP-Test-Tool dieselben Objekte nochmals modellieren.
Legacy-Anwendungen ohne API. Ein Logistikunternehmen betreibt eine Mainframe-Anwendung aus den 1990er-Jahren. Es gibt keine API, keine Weboberfläche, keinen Testansatz ausser Bildschirmabgleich. RPA-Tools beherrschen genau diesen Zugang: Terminal-Emulation, Zeichenvergleich, Cursor-Steuerung. Für diese Nische liefert RPA-basiertes Testing einen Zugang, den klassische Test-Frameworks nicht abdecken.
Wo der Ansatz an Grenzen stösst
RPA-basiertes Testing funktioniert dort gut, wo UI-Interaktion der einzige Weg zur Anwendung ist. Sobald andere Möglichkeiten existieren, verliert der Ansatz seinen Vorteil.
API-Tests laufen schneller und stabiler. Wer eine REST-API testen kann, gewinnt durch UI-Automatisierung nichts. Ein API-Testfall braucht Millisekunden, ein UI-Testfall Sekunden bis Minuten. Die Fehlerquelle «Selektor-Änderung» entfällt komplett.
Selektor-Fragilität bleibt ein Problem. Trotz Fortschritten wie Self-Healing (GenAI passt defekte Selektoren zur Laufzeit an) berichten Anwender in Reviews auf PeerSpot und Gartner Peer Insights von instabilen Tests nach UI-Redesigns. Self-Healing repariert einzelne Selektoren, nicht geänderte Workflows.
Vendor Lock-in ist strukturell bedingt. RPA-Testfälle werden in proprietären Formaten gespeichert (bei UiPath etwa XAML-Workflows oder UiPath-spezifischer C#-Code). Es gibt keinen Export zu anderen Test-Plattformen. Wer 500 Testfälle aufgebaut hat, kann diese nicht zu Tricentis, Katalon oder Playwright migrieren.
Kosten skalieren mit der Plattform. RPA-basiertes Testing erfordert Lizenzen für die gesamte Plattform, nicht nur für ein Test-Tool. Bei UiPath umfasst das Studio Pro, Test Manager, Test Robots und seit 2025 zusätzliche Platform Units. Für Organisationen, die RPA nicht anderweitig nutzen, ist das eine teure Test-Infrastruktur.
Wann RPA-basiertes Testing sinnvoll ist, wann nicht
Drei Konstellationen, in denen der Ansatz seine Stärke ausspielt: Das Unternehmen betreibt bereits RPA-Bots und will diese systematisch testen. Die Zielanwendung bietet keinen API-Zugang (Mainframe, Legacy-Desktop, Citrix). Oder SAP GUI ist die primäre Testoberfläche, und die RPA-Plattform bringt Heatmaps und Change-Impact-Analyse mit.
Drei Konstellationen, in denen spezialisierte Test-Frameworks die bessere Wahl sind: Die Anwendung bietet APIs oder ist webbasiert (Playwright, Cypress). Das Team arbeitet code-zentriert und braucht Git-Integration, parallele Ausführung und Sub-Sekunden-Feedback. Oder die Organisation will kein Vendor-Lock-in eingehen und bevorzugt Open-Source-Werkzeuge.
Die Entscheidung ist keine Grundsatzfrage. Sie hängt von der bestehenden Infrastruktur, der Zielanwendung und dem Teamprofil ab.
Für QA-Leads hat das eine konkrete organisatorische Konsequenz: Wenn RPA und Testing auf derselben Plattform laufen, braucht das Testteam RPA-Kompetenzen. Das kann ein Vorteil sein, wenn ohnehin RPA-Entwickler im Haus sind. Es kann aber auch bedeuten, dass Test-Engineers eine Plattform lernen müssen, die primär für Prozessautomatisierung gebaut wurde. Umgekehrt gilt: Wer ein erfahrenes Test-Engineering-Team hat, das mit Playwright, pytest oder JUnit arbeitet, gewinnt durch den Umstieg auf eine RPA-Plattform wenig.
Wer RPA bereits einsetzt und Legacy-Anwendungen testen muss, findet in RPA-basiertem Testing einen pragmatischen Weg. Wer eine Teststrategie auf grüner Wiese aufbaut, fährt mit spezialisierten Frameworks in der Regel günstiger und flexibler.