UI-Testing-Tools, Prüfung eins: Was bei einem Redesign passiert
Das ist der wiederkehrende Kostenfaktor jeder Browser-Suite, und die Antworten fallen extrem unterschiedlich aus. Ein Tool, dessen Schritte Pfade durch das DOM sind, wird bei einer rein kosmetischen Änderung rot. Ein Tool, dessen Schritte eine Absicht ausdrücken, meistens nicht.
Lassen Sie sich das von jedem Anbieter konkret vorführen, statt es sich nur beschreiben zu lassen.
Prüfung zwei: Wer den zweihundertsten Test schreibt
Die ersten zehn schreibt während der Evaluierung jemand, der motiviert ist. Ein halbes Jahr später, mit vierzig neuen Screens und einem ursprünglichen Fürsprecher, der nicht mehr dabei ist, lautet die ehrliche Antwort oft: niemand. Die meisten aufgegebenen Suites sind an dieser Stelle gescheitert und nicht an einem technischen Grund.
Prüfung drei: Wie ein Fehlschlag aus Sicht derjenigen aussieht, die ihn beheben
Ein Screenshot und ein Stacktrace setzen voraus, dass ein Mensch sie interpretiert. Immer häufiger behebt ein Coding-Agent den Fehler, und der kann das nicht. Ein Fehlschlag, der benennt, was versucht wurde, was die Anwendung getan hat und wo beides auseinanderging, lässt sich von beiden direkt bearbeiten.
Prüfung vier: Gilt ein Lauf, der keine Assertion erreicht hat, als bestanden
Prüfen Sie das in einer Testphase gezielt, denn die Antwort lautet manchmal ja, und das entwertet alles andere. Eine Suite, die Läufe grün meldet, die vor der ersten Assertion in einen Timeout gelaufen sind, ist schlechter als gar keine Suite, weil sie Zuversicht erzeugt statt Information.
Die Übung, die sich lohnt
Machen Sie etwas Echtes kaputt. Ein Speichern, das nicht mehr persistiert, ein Filter, der stillschweigend alles zurückgibt. Dann beobachten Sie jeden Kandidaten. Schlägt der Test fehl, benennt der Fehlschlag die tatsächliche Abweichung, könnte derjenige, der sie behebt, mit dieser Ausgabe anfangen. Ein halber Tag, und das sagt mehr aus als ein Monat Vergleichen.
Was Sie konkret zu Fehlschlägen fragen sollten
Jeder Anbieter zeigt Ihnen einen erfolgreichen Lauf. Die nützlichen fünf Minuten jeder Demo bestehen darin, sich einen fehlgeschlagenen zeigen zu lassen, und dabei achten Sie auf drei Dinge.
Sagt die Ausgabe, was erwartet wurde, oder nur, was passiert ist. Ein Bericht, der einen Screenshot einer kaputten Seite zeigt, ohne zu benennen, was dort hätte stehen sollen, überlässt Ihnen die Interpretation.
Erkennen Sie, an welcher Stelle des Ablaufs es fehlgeschlagen ist, ohne ein Video anzusehen. Video ist eine gute Ergänzung und eine schlechte Hauptquelle, denn sich durch eine zweiminütige Aufzeichnung zu spulen, um den Moment zu finden, ist genau die Arbeit, die Sie sich sparen wollten.
Und könnte ein Agent damit etwas anfangen. Immer häufiger ist es kein Mensch, der den Fehler behebt, und das verändert die Anforderungen an einen guten Fehlerbericht stärker als alles andere im vergangenen Jahrzehnt.
Die Kosten, die bei allen anfallen
Selektoren
Ein Redesign, das funktional nichts ändert, färbt die Suite rot.
Hier geht der größte Teil der Wartungszeit hin.
Warten
Feste Wartezeiten sind langsam und trotzdem flaky. Korrektes Warten setzt voraus, dass man weiß, worauf man wartet.
Die meiste Flakiness lässt sich hierauf zurückführen.
Selbst geschriebene Abdeckung
Abgedeckt ist, was jemand geschrieben hat, also die interessanten Abläufe und nicht die, die kaputtgehen.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Dasselbe Setup gibt es im TestSprite-Dashboard, wenn Sie lokal nichts installieren möchten. Der Rest des CLI-Funktionsumfangs findet sich im CLI-Repository.
Wenn die Pipeline einem anderen Team gehört, ist die GitHub App der Weg des geringsten Widerstands: Es handelt sich um einen Webhook, er ändert nichts in Ihrem Repository und er löst aus, sobald Ihr Build die neue Version als live meldet. Soll der Check stattdessen im Repository sichtbar sein, genügt ein GitHub Actions -Schritt.
Wie TestSprite die vier Prüfungen beantwortet
Bei einem Redesign überstehen Schritte, die als Absichten formuliert sind, kosmetische Änderungen; die Suite wird also nicht rot, weil ein Button verschoben wurde. Der zweihundertste Test wird nicht geschrieben, sondern aus Ihrem Produkt generiert und in natürlicher Sprache verfeinert. Ein Fehlschlag benennt, was versucht wurde, was die Anwendung getan hat und wo beides auseinanderging, und damit können ein Coding-Agent wie auch ein Mensch etwas anfangen. Und ein Lauf, der seine Assertions nie erreicht, wird nicht als bestanden gemeldet.
Den vierten Punkt sollten Sie in jeder Testphase selbst prüfen, auch hier. Machen Sie ein Speichern kaputt, sodass es nicht mehr persistiert, und bestätigen Sie, dass der Check rot wird.
Heraus kommt eine Abdeckung, die mit einem Team Schritt hält, das schneller ausliefert, als es Tests schreiben kann, und ein Fehlersignal, das weiterhin gelesen wird, weil es größtenteils echt ist.
Ist Browser-Unterstützung wichtig?
Schauen Sie zuerst in Ihre Analytics. Viele Teams bezahlen für die Abdeckung von Browsern, die fast keiner ihrer Nutzer verwendet.
Open Source oder kommerziell?
Die Lizenz ist selten der Kostenfaktor. Erstellung und Wartung sind es, und die sind in beiden Fällen ähnlich.
Können wir später migrieren?
Gehen Sie davon aus, dass sich Tests nicht übertragen lassen. Wählen Sie danach, wo Sie in einem Jahr stehen wollen, statt einen Wechsel einzuplanen.
Wie lang sollte eine Testphase sein?
Lang genug, dass ein Redesign oder eine echte Regression hineinfällt. Ohne beides haben Sie die Demo evaluiert.
Was, wenn wir mehr als ein Tool brauchen?
Kommt häufig vor und ist in Ordnung. Ein Code-Framework für gezielte Abläufe plus generierte Abdeckung für die Breite ist eine übliche Aufteilung.
Vier Prüfungen schlagen jede Funktionsmatrix.
Wenn Sie UI-Testing-Tools vergleichen, prüfen Sie, was bei einem Redesign passiert, wer den zweihundertsten Test schreibt, wie ein Fehlschlag aus Sicht derjenigen aussieht, die ihn beheben, und ob ein Lauf ohne erreichte Assertion als bestanden gilt. Machen Sie dann absichtlich etwas kaputt.