Automatisierte UI-Tests: Wählen Sie danach, was unbemerkt kaputtgeht

Ein besseres Kriterium für automatisierte UI-Tests

Sortieren Sie Abläufe danach, wie lange ein Ausfall unbemerkt bliebe, nicht danach, wie wichtig sie sind. Ein Export, eine Einladung, eine Einstellungsseite, eine geplante Zusammenfassung. Jedes davon ist für irgendjemanden wichtig, und bei keinem schaut eine Menge Leute zu – also sitzt eine Regression dort einen Monat lang.

Zweites Kriterium: Wie häufig ändert sich der Ablauf. Ein Screen, der in jedem Sprint neu gestaltet wird, kostet mehr Wartung, als er einbringt. Decken Sie ihn ab, sobald er sich stabilisiert hat.

Die drei Kostenfaktoren

Die ersten beiden lassen sich mit Disziplin in den Griff bekommen. Der dritte ist struktureller Natur: Manuell erstellte Abdeckung ist durch die Zeit der Testautoren begrenzt, und diese Zeit wächst nicht.

Drei Gewohnheiten, die am meisten sparen

• Verankern Sie Tests an stabilen Attributen. Ein eigenes Test-Attribut statt eines CSS-Pfads. Das allein beseitigt die meisten Ausfälle durch Redesigns.

• Warten Sie auf Zustände, niemals auf Zeit. Warten Sie auf das Element oder die Antwort. Eine feste Wartezeit ist langsam und unzuverlässig zugleich.

• Prüfen Sie das, was ein Neuladen bestätigen würde. Ein Erfolgs-Toast ist kein Beleg dafür, dass etwas persistiert wurde.

Warum Suites gelöscht werden

Nicht, weil sie nichts finden. Sondern weil das Verhältnis von echten Fehlern zu Wartungsfehlern so schlecht wird, dass niemand mehr die Ergebnisse liest. Sobald ein roter Build „wahrscheinlich ein Selektor" bedeutet und nicht „wahrscheinlich ein Bug", funktioniert die Suite nicht mehr – auch wenn sie weiterhin läuft.

Dieses Verhältnis zu schützen ist die eigentliche Aufgabe, und dabei geht es mehr darum, wie Schritte formuliert sind, als darum, wie viele Tests Sie haben.

Abdeckung, die nicht von der Zeit der Testautoren abhängt

Als Absichten formulierte Schritte überleben kosmetische Änderungen, und eine Abdeckung, die aus dem Produkt statt aus dem Gedächtnis einer Person entsteht, enthält Abläufe, die niemand geschrieben hätte. Genau dieser Kostenanteil lässt sich nicht mit Disziplin beheben.

Das Dashboard deckt dasselbe ab, wenn Sie keine lokale Installation möchten, und der vollständige Befehlsumfang liegt im CLI-Repository.

Die Suite-Größe, die nützlich bleibt

Es gibt eine Größe, ab der eine Browser-Suite mehr kostet, als sie einbringt – und die liegt niedriger, als die meisten Teams erwarten.

Der begrenzende Faktor ist nicht die Laufzeit, sondern die Aufmerksamkeit. Eine Suite mit dreißig Abläufen produziert Fehler, denen jemand nachgeht. Eine Suite mit dreihundert produziert eine tägliche Liste, und Listen werden triagiert, nicht gelesen. Sobald triagiert wird, fügt jeder weitere Test Rauschen hinzu statt Abdeckung – egal, wie gut er geschrieben ist.

Die nützliche Frage beim Hinzufügen eines Tests ist deshalb nicht, ob der Ablauf wichtig ist. Sie lautet: Würden Sie diesem Test nachgehen, wenn er an einem Freitagnachmittag fehlschlägt? Wenn die ehrliche Antwort ist, dass Sie ihn einfach noch einmal laufen lassen und weitermachen, dann ist der Test bereits Rauschen – und ihn zu schreiben macht die Suite schlechter.

Führen Sie sie bei jeder Änderung aus

Der Auslöser ist wichtiger als der Mechanismus. Wenn Sie die Tests an Ihr Deployment-Event koppeln, wird jede Änderung geprüft, ohne dass es jemand entscheiden muss; die GitHub App erledigt das aus dem Dashboard heraus, und ein Schritt mit GitHub Actions erledigt es innerhalb Ihres Workflows.

Wo TestSprite die Rechnung verändert

Der dritte Kostenfaktor – Abdeckung, die durch die Zeit der Testautoren begrenzt ist – ist der, den Disziplin nicht beheben kann, und genau den nimmt TestSprite weg. Die Testfälle werden aus Ihrem Produkt generiert und in einfacher Sprache verfeinert, sodass die stillen Abläufe abgedeckt werden, ohne dass jemand einen Nachmittag dafür findet, sie zu schreiben.

Die ersten beiden Kostenfaktoren verbessern sich als Nebeneffekt. Schritte werden als Absichten gespeichert, nicht als Pfade durch das DOM – ein Redesign, das einen Button verschiebt, färbt die Suite also nicht rot – und das Warten wird übernommen, statt pro Test justiert zu werden. In diese beiden fließt die meiste Wartungszeit.

Geschützt wird damit die Zahl, die darüber entscheidet, ob eine Suite überlebt: der Anteil roter Builds, die echte Bugs sind. Halten Sie ihn hoch, dann lesen die Leute die Ergebnisse weiter – und das ist der Unterschied zwischen Abdeckung und einem Job, der nachts läuft.