Wiederholen ist keine Reparatur
Ein Erfolg im zweiten Versuch löscht den ersten Fehler nicht. Halten Sie ihn fest, zählen Sie die wiederholte Arbeit und benennen Sie einen Verantwortlichen.
Übersetzte Ausgabe. Technische Kennungen bleiben in ihrer ursprünglichen Form.
Stellen Sie sich einen veranschaulichenden Release-Lauf vor: Ein Checkout-Test schlägt fehl, wird erneut ausgeführt und besteht. Das Ergebnisübersicht ist grün. Niemand untersucht. Die nächste Veröffentlichung wiederholt das Muster. Sie haben die Anzahl der roten Dashboards reduziert, ohne zu erfahren, ob der Checkout zuverlässig ist.
Playwright unterscheidet in seinem Leitfaden zu Wiederholungsversuchen drei Ergebnisse: beim ersten Versuch bestanden, nach einem fehlgeschlagenen Versuch, gefolgt von einem Erfolg, unzuverlässig und nach den verfügbaren Versuchen gescheitert. Das sind unterschiedliche Beweisstücke. Eine generierte Suite sollte die Unterscheidung bewahren, anstatt jeden eventuellen Durchgang zum Erfolg zu machen. Das praktische Artefakt für diesen Artikel ist ein Wiederholungsbuch, das die endgültige Dashboard-Farbe beibehält.
Was sich durch einen erneuten Versuch tatsächlich ändert
Bei einem erneuten Versuch wird derselbe Test noch einmal ausgeführt. Es behebt keine schwache Prüfung, repariert keinen Selektor und trennt auch nicht zwei Konten, die die Einstellungen des anderen überschreiben. Playwright verwirft einen fehlgeschlagenen Arbeitsprozess und startet einen anderen. Die dokumentierten Beispiele zeigen, wie der beforeAll-Hook im neuen Worker erneut ausgeführt wird. Aufbau und Aufräumarbeiten gehören daher in die Kostenkalkulation, nicht nur die Sekunden, die im Prüfkörper verbracht werden.
Ein neuer Browser ist nicht unbedingt eine neue Datenbank. Wenn beim ersten Versuch eine Bestellung erstellt wurde, bevor sie fehlschlug, kann es sein, dass der nächste Versuch auf diese Bestellung stößt. Überprüfen Sie die generierten Tests auf externe Nebenwirkungen und stellen Sie fest, ob die Bereinigung sicher wiederholt werden kann. Der erneute Kaufversuch gegen die Produktion ist kein akzeptables Experiment; Verwenden Sie Staging-Daten und ein begrenztes Testkonto.
Das Hauptbuch, das neben CI geführt werden soll
Notieren Sie für jeden Test seine stabile Kennung, das Ergebnis des ersten Versuchs, das Endergebnis, die Anzahl der Versuche, den Beweislink, die vermutete Ursache, den Eigentümer und das Datum der nächsten Überprüfung. Behalten Sie den Fehler des ersten Versuchs bei, auch wenn der letzte Versuch erfolgreich ist. Ein Team ohne dedizierten QA-Ingenieur kann die Eigentümerschaft dem Entwickler zuweisen, der Eigentümer des Flows ist, anstatt die Automatisierung eine Warteschlange ohne Eigentümer erstellen zu lassen.
Das Hauptbuch ist auch eine nützliche Überprüfungsoberfläche für von Agenten verfasste Tests. Bitten Sie den Agenten, ein Szenario zu entwerfen, und lassen Sie dann von einem Menschen dessen Einrichtung, Durchsetzung und Bereinigung überprüfen. Eine Wiederholungsrichtlinie ist eine Läufereinstellung und kein Ersatz für diese Überprüfung. Die öffentliche Seite von AnyTest beschreibt URL-gesteuerte Erkundungen und eine Suite-Überprüfung durch Menschen; Es legt nicht fest, wie Ihr spezielles CI-Wiederholungsbudget ausgewählt werden sollte.
Zahlen Sie die wiederholten Arbeiten ein
Verwenden Sie eine anschauliche Berechnung mit expliziten Annahmen. Angenommen, zehn Tests benötigen jeweils einen zusätzlichen Versuch, der zwanzig Sekunden dauert, und ein Neustart des Setups fügt fünf Sekunden pro Versuch hinzu. Das sind zehn mal fünfundzwanzig Sekunden oder 250 Sekunden zusätzliche Ausführungsarbeit. Es handelt sich nicht unbedingt um eine Verzögerung von 250 Sekunden, da sich parallel arbeitende Mitarbeiter überlappen können. Zeichnen Sie sowohl die Läuferarbeit als auch die verstrichene Pipeline-Zeit auf, wenn der Unterschied für Ihre Rechnung oder Ihr Release-Fenster von Bedeutung ist.
Fügen Sie dann noch die Zeit hinzu, die jemand damit verbringt, unzuverlässige Berichte zu lesen. Wenn ein Agent eine Stunde bei der Erstellung einspart, aber eine Stunde bei wiederkehrenden Untersuchungen übrig bleibt, stellt die Erstellungszahl allein keine Einsparung dar. Für ein bestehendes QA-Team besteht das Ziel darin, weniger Wiederholungsarbeit zu leisten und mehr Zeit für die Risikoanalyse zu haben. Für ein kleines Team ohne Qualitätssicherung ist das Ziel eine nützliche Abdeckung, die ein Entwickler tatsächlich aufrechterhalten kann.
Eine Freigaberegel, die Sie erklären können
Beginnen Sie mit einer kleinen begrenzten Wiederholungseinstellung und einer sichtbaren, flockigen Kategorie. Eskalieren Sie wiederholte Fehler beim ersten Versuch, anstatt das Limit stillschweigend zu erhöhen. Der richtige Schwellenwert hängt vom Produkt und dem Freisetzungsrisiko ab; Es gibt keine allgemeingültige Zählung, die eine unzuverlässige Kaufabwicklung akzeptabel macht. Fügen Sie einen Reparatureigentümer und einen Nachweis bei, bevor Sie eine Ausnahme akzeptieren.
Die Frage bei der Überprüfung ist einfach: Hat der zweite Versuch neue Beweise erbracht oder lediglich eine Farbe, die wir bevorzugten? Behalten Sie den fehlgeschlagenen Versuch bei, bis jemand antworten kann.
Häufige Fragen
Ist ein Test, der beim erneuten Versuch bestanden wird, ein bestandener Test?
Playwright klassifiziert einen Fehlschlag beim ersten Versuch, gefolgt von einem erfolgreichen Wiederholungsversuch, als unzuverlässig und nicht als einen Pass beim ersten Versuch. Behalten Sie diese Unterscheidung bei der Release-Berichterstattung bei.
Wie sollte ein Team die Wiederholungskosten messen?
Zählen Sie zusätzliche Versuche, Testausführungen, wiederholte Einrichtungs- und Überprüfungszeiten. Die Runner-Arbeit und die Verzögerung der Wall-Clock-Pipeline unterscheiden sich, wenn sich Versuche überschneiden.
Setzen neue Playwright-Mitarbeiter Serverdaten zurück?
Ein Ersatz-Worker und ein Browser löschen den externen Anwendungsstatus nicht automatisch. Entwerfen Sie eine wiederholbare Einrichtung und Bereinigung für die Bereitstellung von Daten.