Wiederholungen sind einfach. Zu wissen, was sie dir gesagt haben, nicht. 

Wenn Sie Appium-Tests ausführen, können Sie einen fehlgeschlagenen Test bereits wiederholen. Frameworks wie TestNG verfügen über einen Wiederholungsanalysator. JUnit-Teams fügen eine Erweiterung oder eine Build-Plugin-Einstellung hinzu. Ein Entwickler kann dies innerhalb eines Nachmittags einrichten. Daher ist es berechtigt zu fragen, was ein Team sonst noch benötigt. 

Der Wiederholungsversuch selbst ist nicht das Schwierige. Schwierig ist alles drumherum: wo die Wiederholungslogik implementiert ist, wie der Rest des Ablaufs konfiguriert ist und ob jemand im Nachhinein sehen kann, was passiert ist. 

Drei Probleme im Zusammenhang mit einem Wiederholungsversuch 

1. Die Logik für Wiederholungsversuche befindet sich im Testcode. In TestNG werden Wiederholungsversuche über einen Analyzer oder Listener implementiert. In JUnit erfolgt dies über eine Erweiterung oder die Build-Konfiguration. Jedes Team wählt seinen eigenen Ansatz, und die Änderung der Wiederholungsanzahl erfordert Codeänderungen und einen erneuten Build.
2. Der Rest des Programmablaufs wird an anderer Stelle konfiguriert. Welche Cloud-Verbindung soll hergestellt werden, welche App-Version, welche Geräte, welche Tests – all diese Einstellungen verteilen sich oft über Capabilities, CI-Skripte und Annotationen. Wenn ein Testlauf unerwartet verläuft, muss zunächst die Herkunft der einzelnen Einstellungen ermittelt werden.
3. Wiederholungsversuche hinterlassen kaum Spuren. Ein Test, der beim ersten Versuch fehlschlägt und beim zweiten Mal erfolgreich ist, sieht oft fälschlicherweise nach einem erfolgreichen Test aus. Der fehlgeschlagene Versuch ist zwar in der lokalen Build-Ausgabe vorhanden, erscheint aber nicht im Testbericht neben den übrigen Testergebnissen. Das Team kann daher nicht ohne Weiteres zwischen einem fehlerfreien Testlauf und einem Testlauf mit Fehlern unterscheiden. Genau diese Information deutet aber auf einen fehlerhaften Test oder eine instabile Testumgebung hin.

Keiner dieser Punkte ist für sich genommen dramatisch. Zusammengenommen erklären sie jedoch, warum ein Team, das „Wiederholungsversuche bereits berücksichtigt hat“, in der Release-Woche dennoch Tests manuell wiederholt, um herauszufinden, was tatsächlich funktioniert. 

Warum dies mit zunehmender Anzahl der Suiten teurer wird 

Schätzungsweise 40–50 % des Unternehmenscodes werden mittlerweile von KI generiert (Digital.aiMehr Code bedeutet mehr Angriffsfläche für Fehler, und die Testsuiten wachsen entsprechend. 

Fehlerhafte Tests sind ein bekanntes Problem bei großem Umfang: Atlassian führt etwa 15 % der Ausfälle im Jira-Backend-Repository auf fehlerhafte Tests zurück, wobei die daraus resultierenden Wiederholungen über 150,000 Entwicklerstunden pro Jahr verschwenden.Atlassian, 2025). 

Falls Sie noch an der Feinabstimmung von Ortungspunkten und Wartezeiten arbeiten, beginnen Sie mit Wiederholte Versuche beheben keinen fehlerhaften Locator.Im Folgenden geht es um die verbleibenden Fehler. 

Test Orchestrator: eine Zwischenschicht für die Ausführung von Tests 

Test Orchestrator in Digital.ai Die Testphase befindet sich zwischen Ihren Appium-Tests und dem Digital.ai Testplattform. Sie steuert die Testausführung und wiederholt fehlgeschlagene Tests automatisch, ohne die Tests selbst zu ändern oder einen Build manuell neu zu starten. Es handelt sich um einen Java-basierten Agenten, der als JAR-Datei bereitgestellt wird. Sie fügen ihn Ihrem bestehenden Testprojekt hinzu und verwenden ihn bei der Testausführung. 

Eine YAML-Datei für den Lauf. Cloud-Verbindung, App- und Geräteauswahl, die auszuführenden Tests und die Anzahl der Wiederholungsversuche werden zentral in einer YAML-basierten Konfiguration festgelegt. Die Anzahl der Wiederholungsversuche wird als Konfigurationswert definiert, ohne dass eine Codeänderung erforderlich ist, und alle Einstellungen für einen Testlauf befinden sich an einem zentralen Ort. 

Sie können die Wiederholungsversuche sehen. Wird ein fehlgeschlagener Test wiederholt, sind alle Versuche und deren Ergebnisse im Test Reporter sichtbar. Das Team kann erkennen, welche Fehler erneut auftraten, welche Tests beim Wiederholungsversuch erfolgreich waren und ob ein kritischer Test den Testlauf abgebrochen hat. Ein erfolgreicher Test im zweiten Versuch ist nun nicht mehr von einem fehlerfreien Testlauf zu unterscheiden. 

Ihre Tests bleiben unverändert. Sie fügen Test Orchestrator als Zwischenschicht hinzu. Bestehende Testmethoden bleiben unverändert. Es ist kompatibel mit JUnit und TestNG, lässt sich als Qualitätssicherung in CI/CD-Pipelines integrieren und ist sowohl für SaaS- als auch für On-Premise-Kunden verfügbar. 

Was sich von Tag zu Tag ändert 

• QA-Ingenieure Weniger Zeitaufwand für das manuelle Wiederholen fehlgeschlagener Tests, um festzustellen, ob ein Fehler erneut auftritt. Im Test Reporter bieten die Testversuche einen klareren Ausgangspunkt. 

• QA-Manager Vor der Freigabe muss klar sein, was Aufmerksamkeit erfordert. Wiederholte Fehler werden zuerst untersucht, Tests, die beim Wiederholungsversuch bestanden wurden, werden protokolliert, und ein kritischer Test, der den Lauf abgebrochen hat, ist leicht zu erkennen, sodass das Team nicht jeden fehlgeschlagenen Lauf gleich behandelt. 

Wenn ein Framework-Wiederholungsversuch ausreicht 

Wenn Ihre Testsuite klein ist, von einem Team verwaltet wird und eine einfache Erfolgs- oder Fehleranzeige in der Konsole ausreicht, ist möglicherweise ein Retry Analyzer ausreichend. Test Orchestrator richtet sich an Teams mit so vielen automatisierten Tests, dass die Fehleranalyse und das erneute Ausführen einzelner Tests bei jedem Release Echtzeitzeit in Anspruch nehmen. 

Es beseitigt auch nicht die Ursache für ein fehlerhaftes Testergebnis. Ein Test, der im zweiten Anlauf erfolgreich ist, liefert dennoch eine Information, sei es eine instabile Umgebung oder ein Ortungsgerät, das zu driften beginnt. Wichtig ist, dass das Signal sichtbar bleibt, damit man darauf reagieren kann. 

Von „Hat es letztendlich geklappt?“ bis „Was geschah bei jedem Versuch?“ 

Das Hinzufügen eines Wiederholungsversuchs dauert einen Nachmittag. Die Bedeutung der Wiederholungsversuche zu verstehen und die Konfiguration jedes einzelnen Testlaufs zu verwalten, wird mit zunehmender Anzahl an Testsuiten immer schwieriger. Test Orchestrator vereint beides an einem Ort und lässt Ihre Tests unberührt. 

Erfahren Sie mehr in der Test Orchestrator-Dokumentation.