UI-Automatisierungstools: Drei Kategorien und welche Annahme jede trifft

Die drei Kategorien von UI-Automatisierungstools

• Code-Frameworks. Sie schreiben Tests in einer echten Programmiersprache. Setzt voraus: Entwickler, die Zeit zum Schreiben und Pflegen haben.

• Aufzeichnung und Low-Code. Eine Person baut Abläufe in einem Editor. Setzt voraus: jemanden, dessen Aufgabe es ist, Testabläufe zu bauen.

• Agentenbasiert. Die Abdeckung wird generiert und in natürlicher Sprache verfeinert. Setzt voraus: dass Sie Abdeckung prüfen, die Sie nicht selbst geschrieben haben.

Welche Annahme am häufigsten scheitert

Die zweite. Low-Code-Plattformen sind auf eine eigene Testfunktion im Team ausgelegt, und viele Teams haben die nicht mehr. Die Plattform ist in Ordnung, die Lizenz ist bezahlt, und niemand erstellt Abläufe – die Abdeckung wächst ab dem Monat nicht mehr, in dem der letzte Tester gegangen ist.

Die erste Annahme scheitert langsamer. Entwickler können Tests schreiben, aber das konkurriert mit dem Ausliefern von Features: Die Suite wächst im ersten Quartal und kommt dann zum Stillstand.

Fragen, die mehr bringen als eine Feature-Matrix

• Wer schreibt den zweihundertsten Test? Die ersten zehn entstehen während der Evaluierung. Fragen Sie nach Monat sechs.

• Was passiert, wenn die UI neu gestaltet wird? Das sind die wiederkehrenden Kosten, und die Antwort fällt je nach Kategorie sehr unterschiedlich aus.

• Wie sieht ein Fehlschlag für die Person aus, die ihn behebt? Zunehmend ist das ein Coding-Agent, der einen Screenshot nicht interpretieren kann.

• Wird ein Lauf, der seine Assertions nie erreicht hat, als bestanden gemeldet? Das sollten Sie gezielt ausprobieren, denn die Antwort lautet manchmal ja.

Die Kosten, die im Vergleich nicht auftauchen

Jede dieser Kategorien verursacht laufende Kosten, die Anbieter nicht beziffern, weil sie von Ihnen abhängen und nicht von ihnen: die Kosten der Entscheidung, was abgedeckt werden soll.

Bei einem Code-Framework schreibt jemand den Test, also hat vorher jemand entschieden, dass es diesen Test geben soll. Bei einem Low-Code-Editor genauso. Bei generierter Abdeckung verlagert sich die Entscheidung auf das Prüfen eines Plans – das geht schneller, ist aber nicht umsonst und wird oft übersprungen. Das Ergebnis ist der Fehlermodus „Abdeckung, die niemand gelesen hat".

Wofür Sie sich auch entscheiden: Planen Sie diesen Aufwand ausdrücklich ein. Eine Stunde pro Woche, in der jemand prüft, was abgedeckt ist und was nicht, macht den Unterschied zwischen einer Suite, die Ihr Produkt abbildet, und einer, die abbildet, was sich vor achtzehn Monaten gerade bequem automatisieren ließ.

So evaluieren Sie

Machen Sie absichtlich etwas kaputt. Bauen Sie eine echte Regression ein, etwa ein Speichern, das nicht mehr persistiert, und beobachten Sie, was jeder Kandidat meldet. Ob der Test fehlschlägt, ob der Fehlschlag die Abweichung benennt und ob derjenige, der sie behebt, mit dieser Ausgabe starten kann. Diese eine Übung sagt Ihnen mehr als ein Monat Feature-Vergleich.

Wenn Sie lieber nichts installieren möchten: Das Dashboard leistet dasselbe. Alles Weitere, was die Kommandozeile kann, finden Sie im CLI-Repository.

Zwei Wege, und die Entscheidung dreht sich im Kern darum, wem die Pipeline gehört. Wenn Sie die GitHub App über das Dashboard verbinden, ist dafür keinerlei Änderung an Ihrem Repository nötig, denn sie reagiert auf das Deployment, das Ihr Build ohnehin erzeugt. Ein Schritt mit GitHub Actions legt die Prüfung dagegen ins Repository, wo sie im Review genauso behandelt wird wie der Rest des Builds.

Welche Annahme TestSprite trifft

Dass Sie Abdeckung prüfen, die Sie nicht selbst geschrieben haben. Das ist der Tausch: Es braucht niemanden, der die Tests schreibt, dafür liest jemand den Plan und korrigiert ihn.

Konkret heißt das: Testfälle werden aus Ihrem Produkt generiert, Schritte sind als Absichten formuliert und überstehen damit Redesigns, und ein Fehlschlag kommt zurück als das, was versucht wurde, was die Anwendung getan hat und wo beides auseinanderging – womit ein Coding-Agent genauso arbeiten kann wie ein Mensch.

Für ein Team ohne eigene Testfunktion ist diese Annahme leichter zu erfüllen als die beiden anderen, denn das Prüfen eines Plans kostet eine Stunde pro Woche, das Schreiben einer Suite dagegen eine ganze Stelle. Wenn es diese Stelle bei Ihnen gibt, fahren Sie mit einem Code-Framework möglicherweise besser. Die ehrliche Entscheidungsfrage lautet: Welche Annahme kann Ihr Team in einem Jahr tatsächlich erfüllen?