Epsilon automatisiert UI-Tests mit Nova Act in von AWS verwalteten Browsern

Was sich bei Epsilons UI-Tests ändert

AWS stellt Epsilons Agentic Platform als verwalteten Dienst für Tests von Benutzeroberflächen vor. Teams beschreiben Tests in natürlicher Sprache; ausgeführt werden sie in von AWS verwalteten Browsern. Der Ansatz soll den Aufwand verringern, den einzelne Teams sonst hätten, um eine eigene Testinfrastruktur aufzubauen und zu warten. Zugleich sollen die Tests ausdrücken, welche Absicht hinter dem zu überprüfenden Ablauf steht.

Die praktische Änderung besteht nicht darin, dass Tests nicht mehr entworfen werden müssen. Vielmehr übernimmt ein System, das Anweisungen interpretiert und einen Browser bedient, einen Teil ihrer Ausführung. In der beschriebenen Architektur automatisiert Nova Act Interaktionen mit der Benutzeroberfläche; Bedrock AgentCore Browser Tool stellt die verwaltete Browserumgebung bereit. AWS beschreibt diese Kombination, veröffentlicht aber keinen unabhängigen Bericht, anhand dessen sich ihre Leistung im Produktivbetrieb beurteilen ließe.

„Intent-driven“ bedeutet hier, zu formulieren, welches Ergebnis ein Test prüfen soll, statt ihn ausschließlich als festgelegte Abfolge technischer Schritte zu beschreiben. Das kann hilfreich sein, wenn sich Abläufe in einer Anwendung häufig ändern. Eine flexiblere Anweisung garantiert jedoch weder, dass der Agent jede Änderung richtig versteht, noch, dass er alle relevanten Fehler erkennt.

Die verfügbaren Informationen geben einen allgemeinen Überblick über das technische und operative Konzept: einen verwalteten Dienst, Teams als Nutzer und von AWS betriebene Browser. Daraus geht nicht hervor, wie viele Teams den Dienst einsetzen, welche Arten von Anwendungen die konkrete Implementierung abdeckt oder welcher Anteil der Tests ohne menschliches Eingreifen läuft.

Wie Nova Act und der verwaltete Browser zusammenspielen

Ein Browsertest verbindet üblicherweise eine Absicht – etwa zu prüfen, ob ein Vorgang abgeschlossen werden kann – mit konkreten Aktionen: eine Seite öffnen, Bedienelemente auswählen, Daten eingeben und das Ergebnis prüfen. Im von AWS beschriebenen System werden die Anweisungen in Alltagssprache formuliert, und Nova Act automatisiert die Interaktion mit der Benutzeroberfläche. Bedrock AgentCore Browser Tool stellt den verwalteten Browser bereit, in dem diese Interaktionen stattfinden.

Diese Aufteilung hilft, die Aufgaben der einzelnen Komponenten zu verstehen, ohne ihnen zusätzliche Fähigkeiten zuzuschreiben. Nova Act ist der modellgestützte Automatisierungsteil; der verwaltete Browser ist die Umgebung, in der die Anwendung beobachtet und bedient wird. Die verfügbaren Informationen erläutern nicht, wie eine Anweisung in einzelne Schritte umgesetzt wird, welche deterministischen Mechanismen das Ergebnis überprüfen oder wie Fehler behandelt werden, wenn die Benutzeroberfläche nicht den Erwartungen entspricht.

Modellgestützte Automatisierung kann eine Anweisung interpretieren und wahrscheinliche Aktionen auswählen. Das ist keine Garantie dafür, dass ein Ablauf korrekt abgeschlossen wird. Explizite Prüfungen – etwa eines erwarteten Textes, eines Status oder einer strukturierten Antwort – unterscheiden sich von der probabilistischen Entscheidung, wo geklickt wird oder was als Nächstes geschieht. Für die Bewertung eines Tests ist daher wichtig, sowohl die Interpretation der Anweisung als auch die abschließenden Bestehenskriterien zu kennen.

Auch die Bezeichnung „von AWS verwalteter Browser“ bedeutet nicht, dass alle Sicherheits- und Isolationsaspekte dokumentiert sind. AWS sagt, dass der Browser verwaltet wird. Aus den verfügbaren Informationen geht jedoch nicht hervor, wie Sitzungen, Zugangsdaten, temporäre Daten oder Protokolle zwischen Kunden getrennt werden.

Was das Beispiel zur QA-Automatisierung zeigt

Ein AWS-Beispielrepository zeigt eine weitere Möglichkeit, Qualitätstests mit dem Nova Act SDK und pytest zu organisieren. Das Projekt kombiniert Browsertests, parallele Ausführung und HTML-Berichte, die Ergebnisse, Laufzeiten und Fehler sowie Screenshots und Protokolle enthalten können. Außerdem veranschaulicht es Assertions für boolesche Werte, Text und Datenstrukturen.

Das Beispiel ist als technische Referenz nützlich: Es zeigt, wie sich ein Agent mit verbreiteten Testwerkzeugen verbinden und wie sich Berichte organisieren lassen. Es ist jedoch keine Bewertung von Epsilons Plattform und belegt nicht, dass beliebige natürlichsprachliche Tests an anderen Einsatzorten stabil oder gültig sein werden. Ein Codebeispiel belegt, dass eine Referenzimplementierung existiert; für sich genommen belegt es weder eine Erfolgsquote noch ein bestimmtes Verhalten im Produktivbetrieb.

Laut Repository gelten bestimmte Anforderungen an die Umgebung. Die Konfiguration nutzt pytest-xdist für parallele Tests und ermöglicht es, Tests, die nacheinander ausgeführt werden müssen, zu gruppieren. Das greift ein häufiges Problem auf: Manche Tests sind voneinander unabhängig, andere teilen Daten oder hängen vom Ergebnis eines vorherigen Tests ab. Parallele Ausführung kann bei bestimmten Arbeitslasten Zeit sparen, beseitigt aber weder Abhängigkeiten noch garantiert sie reproduzierbare Ergebnisse.

Das Projekt sieht außerdem vor, Protokolle und Browserdaten für einzelne Tests zu speichern und einen Ausführungsbericht zu erstellen. Solche Artefakte können Teams bei der Untersuchung von Fehlern helfen. Ihre Verfügbarkeit beweist jedoch nicht, dass das System alle Fehler erkennt; ebenso legen sie nicht von selbst fest, wie lange die Daten gespeichert werden oder wer darauf zugreifen darf.

Was ein verwalteter Mehrkundendienst bedeutet

AWS beschreibt Epsilons Plattform als verwalteten Mehrkundendienst, der auf betriebenen Browsern läuft. Im Betrieb könnte dies bedeuten, dass Produktteams eine gemeinsame Infrastruktur nutzen, statt jeweils eine eigene Browserumgebung zu warten. AWS nennt als Ziel, Infrastrukturaufwand pro Team zu vermeiden. Eine Aufschlüsselung von Kosten, Personalbedarf oder tatsächlich erzielten Einsparungen wird nicht veröffentlicht.

Die Bezeichnung „Mehrkundendienst“ sagt nicht aus, welche Ressourcen gemeinsam genutzt werden oder wie ihre Trennung umgesetzt ist. Gemeinsame Komponenten können mit Isolationsmaßnahmen pro Sitzung oder Kunde kombiniert werden; das konkrete Design wird in den geprüften Informationen jedoch nicht beschrieben. Aus der Darstellung lässt sich nicht ableiten, welcher Schutz für Cookies, Zugangsdaten, Browserprofile, Screenshots, Protokolle oder während eines Tests ausgelesene Daten gilt.

Für Organisationen, die einen solchen Dienst prüfen, sind diese Unterschiede wichtig, weil Tests auf Konten, Testdaten oder Umgebungen mit sensiblen Informationen zugreifen können. Die hier verfügbaren öffentlichen Informationen bestätigen keine Aufbewahrungsrichtlinien, Zugriffskontrollen, Datenstandorte oder Mechanismen zur Trennung von Kunden. Diese fehlenden Angaben beweisen nicht, dass solche Kontrollen nicht existieren; sie bedeuten, dass die geprüften Informationen sie nicht belegen.

Eine zentrale Verwaltung kann außerdem lokale Installations- und Wartungsaufgaben reduzieren. Gleichzeitig verlagert sie einen Teil der betrieblichen Fragen auf den Anbieter und die Konfiguration des Dienstes. Der Komfort, keine eigenen Browser verwalten zu müssen, ist von Belegen zu Sicherheit, Kontinuität, Isolation und Wiederherstellung nach Fehlern zu unterscheiden.

Zuverlässigkeit, Aufsicht und Grenzen der Belege

Die verfügbaren Informationen beschreiben Epsilons Konzept, enthalten aber keine reproduzierbaren, Epsilon-spezifischen Kennzahlen zu Genauigkeit, Testabdeckung, sporadischen Fehlern oder Zeitersparnis. Ebenso wenig wird erläutert, welche Aufgaben autonom ausgeführt werden, welche Ergebnisse eine menschliche Freigabe erfordern oder welcher Mechanismus greift, wenn der Agent eine Anweisung falsch interpretiert.

Amazon hat allgemeine Zuverlässigkeitswerte für Nova Act bei Arbeitsabläufen früher Kunden angekündigt. Diese Unternehmensangabe hat einen anderen Geltungsbereich: Sie ist keine unabhängige Messung von Epsilons Plattform und erlaubt nicht, derselben eine entsprechende Erfolgsquote zuzuschreiben. Zudem hängt ein zusammengefasster Wert von den getesteten Aufgaben, Umgebungen und der Definition von Zuverlässigkeit ab. Ohne diese Einzelheiten ist er keine Garantie für eine bestimmte Anwendung.

Automatisierte UI-Tests müssen mit Designänderungen, variabel erscheinenden Elementen, Ladezeiten und unerwarteten Ergebnissen umgehen. Ein System kann einen Ablauf korrekt ausführen und bei einem ähnlichen scheitern. Deshalb sollten Tests anhand repräsentativer Szenarien, beobachtbarer Akzeptanzkriterien und einer Prüfung fehlgeschlagener Fälle bewertet werden. Eine natürlichsprachliche Anweisung macht einen Test nicht von sich aus robust.

Die belastbare Schlussfolgerung ist begrenzt: AWS beschreibt eine Architektur, die natürlichsprachliche Anweisungen, Nova Act und verwaltete Browser kombiniert, damit Epsilon UI-Tests als Dienst anbieten kann. Das QA-Beispiel liefert eine praktische Referenz zu SDK, pytest und Berichten. Die geprüften Informationen erlauben keine Aussage über eine konkrete Zuverlässigkeit von Epsilon, eine bestimmte Testabdeckung, den Verzicht auf menschliches Eingreifen oder spezifische Eigenschaften der Mehrkundenisolation.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.