Legacy-Testautomatisierung mit KI bezeichnet den Ansatz, Anwendungen ohne zugängliche Element-IDs per visuellem Modell zu testen. Ein KI-Tool analysiert Screenshots und findet Elemente anhand natürlichsprachiger Beschreibungen, ohne Referenzbilder auszuschneiden. So lassen sich manuelle Testzyklen von mehreren Wochen auf wenige Stunden reduzieren.
Das Wichtigste in Kürze
- Manuelle Regressionstests der Mobile-Kasse-App der Deutschen Bahn banden zwei bis drei Personen über zwei Wochen, die Automatisierung mit AskUI reduziert denselben Testlauf auf etwa drei Stunden.
- AskUI erkennt UI-Elemente rein visuell per Screenshot und KI-Modell, ohne auf Element-IDs zuzugreifen, was das Tool für Anwendungen nutzbar macht, die klassische Frameworks wie Appium oder Selenium nicht automatisieren können.
- Wer keine Element-IDs im Code verankert, verbaut sich spätere Testautomatisierung, weshalb die Deutsche Bahn heute für alle neuen oder zugekauften Anwendungen Automatisierbarkeit bereits als Anforderung an Dienstleister stellt.
- Das größte offene Problem beim KI-basierten UI-Testing ist die Ausführungsgeschwindigkeit: Jeder Schritt erfordert einen Inferenz-Call gegen ein Modell, was die Suite deutlich langsamer macht als konventionelle Frameworks.
Warum Legacy-Software bei der Testautomatisierung scheitert
Legacy-Anwendungen lassen sich mit klassischen Automatisierungstools oft nicht ansteuern, weil ihnen die technischen Anker fehlen. Selenium, Appium oder TestComplete greifen auf Element-IDs zu. Fehlen diese IDs, läuft der ganze Ansatz ins Leere.
Genau das passierte bei der mobilen Kasse der Deutschen Bahn. Auf dieser Anwendung verkaufen Mitarbeitende im Fernverkehr Kaffee, Bier oder andere Artikel und buchen Kartenzahlungen. Die Software ist Android-basiert, läuft mit .NET 6 und wurde eingekauft, nicht selbst entwickelt. Über Automatisierung hat damals niemand nachgedacht.
Das Resultat: keine sauber adressierbaren Elemente, kein Standard-Tool, das greift. Mehrere Proof of Concepts mit Open-Source-Werkzeugen schlugen fehl, schlicht weil die Anwendung keine Element-IDs liefert.
Manuelles Testen kostet zwei bis drei Wochen
Der manuelle Regressionstest der mobilen Kasse bindet zwei bis drei Personen über zwei Wochen. Das ist der Ausgangspunkt, an dem der Leidensdruck entsteht.
Das Problem verschärft sich bei jedem Fund. Tauchen nach zwei Wochen Bugs auf und kommt eine neue Version, muss die Regression erneut laufen. Dieser Zyklus ist in der Praxis kaum noch tragbar, wenn Releases schnell aufeinanderfolgen sollen.
Bei neu eingekaufter oder selbst entwickelter Software setzt die Deutsche Bahn inzwischen früher an. Dienstleister und Teams müssen von Unit-Tests über Schnittstellentests bis zu allen weiteren Ebenen Qualität sichern, bevor die Abnahmetests greifen. Bei Altanwendungen wie der mobilen Kasse existiert dieses Fundament nicht, deshalb das Problem.
Wie visuelle KI-Selektoren Legacy-Oberflächen ansteuern
Der Ansatz von AskUI verzichtet vollständig auf Element-IDs und arbeitet stattdessen über Screenshots. Ein Controller, das sogenannte AgentOS, ist mit einer Inferenz verbunden, die mehrere Modelle bündelt: OCR, Bilderkennung, ein LLM und multimodale Modelle.
Das Werkzeug macht zur Laufzeit einen Screenshot vom Betriebssystem und findet darauf die Bedienelemente. Es gibt kein Element-Matching und kein aufgezeichnetes Klick-Recording wie bei älteren Tools.
Der Unterschied zu früheren bildbasierten Ansätzen ist wichtig. Alte Tools schnitten einzelne Element-Bilder aus und verglichen sie pixelgenau. Sobald sich am Screen etwas änderte, brach die ganze Strecke. AskUI schneidet keine Elemente aus.
Stattdessen hat das Modell vorab gelernt, wie ein Login-Button aussieht. Du beschreibst nur die Aktion, nicht das Aussehen. Jonas Menesklou bringt es auf den Punkt:
Wie ChatGPT Text versteht, verstehen wir Bilder.
Jonas Menesklou
Vom Testfall zur Ausführung: zwei Wege
Es gibt zwei Wege, Testfälle aufzubauen, je nach technischem Anspruch. Die Deutsche Bahn nutzt für die mobile Kasse den Code-Weg über ein Framework mit TypeScript und Node.js.
Im Code ist der AskUI-Selektor nur ein anderer Selektor in der Library. Statt einer Element-ID schreibst du eine sprachliche Beschreibung: klick auf den grünen Login-Button links oben in der Ecke. Diese Beschreibung wird zur Laufzeit zum Selektor. Die Library lässt sich in PyTest, TypeScript-Test und andere Runner einbinden.
Für weniger technische Anwender gibt es einen No-Code-Weg über eine CSV. Liegen die Testfälle in einem Testmanagement-Tool mit Test-Case-ID und natürlichsprachiger Schritt-für-Schritt-Beschreibung, liest ein LLM diese Beschreibung aus und überführt jeden Schritt in eine Aktion. Du lädst die Datei hoch und startest die Suite.
Der Selektor funktioniert dabei wie ein virtueller Tester mit Verständnis für Oberflächen. Du beschreibst das Element so, wie du es einem Menschen erklären würdest, der den Screen zum ersten Mal sieht.
Wartung über Training statt Code-Umbau
Ändert sich die Oberfläche, fällt der Anpassungsaufwand gering aus, weil nicht der ganze Code angefasst werden muss. Das Tool nimmt die neuen Bilder automatisch auf und übernimmt einen Teil der Änderung selbst. Die Testlogik wird nur für den geänderten Fall angepasst.
Für Erkennungsfehler gibt es ein eigenes Training-Tool. Liefert ein Screenshot ein unscharfes Element und das Modell erkennt etwa “Registrierung” nicht, kannst du dem Tool genau diese Zuordnung beibringen. Damit erweiterst du das zugrunde liegende Modell manuell, wenn die automatische Erkennung versagt.
Diese Möglichkeit, das Modell selbst nachzuschärfen, hebt den Ansatz von reinen Black-Box-Tools ab. Du bist nicht darauf angewiesen, dass der Hersteller jeden Sonderfall abdeckt.
Was Zahlen aus der Praxis zeigen
Die mobile Kasse umfasst 270 längere Testfälle auf Abnahmeebene, von denen aktuell 60 automatisiert sind. Diese 60 Fälle laufen in rund drei Stunden automatisiert durch. Manuell braucht ein Tester für etwa 50 Fälle mindestens acht Stunden.
Das Ziel ist deutlich ambitionierter. Werden 210 bis 220 der 270 Testfälle automatisiert und laufen parallel über mehrere Geräte, soll die gesamte Suite in ein bis eineinhalb Stunden durchlaufen. Damit ließe sich etwa die Hälfte der bisherigen Ressourcen einsparen.
Vollständig automatisierbar ist die mobile Kasse nicht. Sie nutzt Peripheriegeräte: einen Drucker für den Kassenbon und ein Gerät zum Scannen der Kreditkarte. Diese Peripherie-Tests sind noch nicht abgedeckt, machen aber den kleineren Teil aus.
Eine zusätzliche Hürde sind bahnspezifische Geräte mit eigenen Zertifikaten. Die App läuft nicht auf beliebiger Hardware, und das Testen gegen Emulatoren scheitert ebenfalls an diesen Zertifikaten.
Geschwindigkeit ist die offene Baustelle
Die größte Schwachstelle des KI-gestützten Ansatzes ist die Performance. Weil jeder Schritt einen Screenshot verarbeitet und visuell einen Selektor findet, läuft die Ausführung spürbar langsamer als bei einem klassischen Werkzeug. Umar Usman Khan formuliert es klar: Wäre die Anwendung mit Appium automatisierbar gewesen, hätte er Appium genommen, obwohl AskUI weniger Code verlangt.
Daran wird aktiv gearbeitet. Die Modelle laufen auf eigener Inferenz-Infrastruktur der Deutschen Bahn statt in der Cloud, was Datenkontrolle bringt, aber Kommunikationszeit zwischen Server und Tool kostet. Ein neu gebautes Caching-System hält Befehle lokal, statt jeden Command an den Server zu schicken.
Weitere Hebel sind Kompression, kleinere Modelle und möglichst wenige Inferenz-Calls pro Lauf. Die Stoßrichtung: so viel wie möglich vor Ort verarbeiten, weniger Request-Response-Verkehr.
Warum die Partnerschaft mit einem Startup hier funktioniert
Die enge Zusammenarbeit mit einem jungen Anbieter zahlt sich für beide Seiten aus. Fehlende Features oder Probleme aus dem Betrieb fließen direkt zurück, und der Anbieter liefert Fixes und neue Funktionen schneller, als es bei einem etablierten Tool üblich wäre.
Damit so etwas trägt, braucht es Rückendeckung im Unternehmen. Proof of Concepts kosten Investition, und diese Investition muss intern jemand mittragen. Genau das war hier der Fall, getragen von Teamleitung und Abteilungsleitung.
Für dich als Tester heißt das: Ein neues, noch unfertiges Werkzeug kann der richtige Weg sein, wenn das etablierte Tooling an der Anwendung schlicht scheitert. Der Sprung von zwei bis drei Wochen manuellem Aufwand auf wenige Stunden rechtfertigt es, ein wachsendes Produkt aktiv mitzugestalten, statt auf die perfekte Lösung von der Stange zu warten.
