Eine große Anzahl von Tests half nichts, da jeder fehlgeschlagene Durchlauf eine neue Untersuchung auslöste

Leiter der Technikabteilung

Die Kundenplattform umfasste etwa 1.100 automatisierte Tests, doch die Entwicklerteams hatten das Vertrauen in die Suite verloren. a1qa wurde beauftragt, eine abgegrenzte Teilmenge von 420 Tests zu bewerten, die die kritischen E-Commerce-Abläufe abdeckten, für jeden Test eine Entscheidung über Beibehaltung, Ersatz oder Entfernung zu dokumentieren und nachzuweisen, dass die daraus resultierende Testmenge Entscheidungen zur Bereitstellung stützen konnte.

El desafío

Die kritische Teilmenge wies eine Quote von 18 % instabiler Tests (Flaky Tests) auf. Zudem entsprachen 24 % der gemeldeten Fehler keinen reproduzierbaren Produktfehlern. Veraltete Selektoren, doppelte Vorbereitungslogik, inkonsistente Daten und eine mangelhafte Fehlerklassifizierung zwangen die Ingenieure dazu, Testläufe zu wiederholen und Störsignale zu untersuchen, bevor sie das tatsächliche Risiko für das Produkt einschätzen konnten.

Wartungsarbeiten und Wiederholungsläufe nahmen wöchentlich etwa 45 Stunden Entwicklungszeit in Anspruch. Nur 52 % der CI-Läufe wurden innerhalb der vereinbarten Frist von 90 Minuten und ohne Wiederholungslauf abgeschlossen. Die Entscheidungsfindung bezüglich der Regression für den ausgewählten Umfang dauerte etwa zwei Arbeitstage, was den Produktbereich auf zwei geplante Releases pro Monat beschränkte.

Der Kunde benötigte eindeutige Belege dafür, welche Elemente weiterhin gültig waren, welche modernisiert werden mussten und welche am kostengünstigsten zu ersetzen waren.

Über einen Zeitraum von 12 Wochen führte a1qa mithilfe eines strukturierten Ansatzes zur Wiederherstellung und Stabilisierung die Schritte von der Evaluierungsphase bis zur Umsetzung eines Pilotprojekts durch. Das Team bestand aus drei Automatisierungsingenieuren, einem leitenden Quality-Engineering-Architekten und einem Teilzeitmitarbeiter für den DevOps-Support.

Das Projekt begann mit der Fehleranalyse anhand zahlreicher wiederholter Testläufe, der Überprüfung der Codestruktur und ihrer Abhängigkeiten sowie der Unterscheidung zwischen instabilen Tests, Umgebungsfehlern, Datenproblemen und reproduzierbaren Produktfehlern. Für jeden der 420 Tests, die zum kritischen Umfang gehörten, wurde auf der Grundlage technischer und wirtschaftlicher Kriterien entschieden, ob er beibehalten, ersetzt oder entfernt werden sollte.

Nachdem 170 Tests, deren Geschäftszweck und Architektur weiterhin gültig waren, stabilisiert worden waren, optimierten die QA-Ingenieure die Selektoren, Assertions, Wartezeiten, die Datenaufbereitung und die wiederverwendbaren Komponenten, wobei sie gleichzeitig die Rückverfolgbarkeit zu den kritischen Kundenabläufen sicherstellten.

Anschließend ersetzte das Team 150 Tests, deren Reparatur nicht rentabel war. Die KI wurde eingesetzt, um sich wiederholende Aufgaben bei der Vorbereitung und Umwandlung von Code auf der Grundlage zuvor genehmigter Szenarien zu unterstützen. Die QA-Ingenieure wandten die Konventionen des Frameworks an, überprüften die Geschäftslogik und schlossen alle Ergebnisse aus, die nicht den festgelegten Akzeptanzkriterien entsprachen.

Schließlich wurden 100 veraltete oder doppelte Tests aus dem Pilotumfang entfernt. Die 320 akzeptierten Tests wurden in den kundeneigenen CI-Workflow integriert, wiederholt validiert und hinsichtlich Laufzeit, Stabilität, Falschausfallrate und Wartbarkeit überprüft.

Der für die Bewertung festgelegte Umfang umfasste die Authentifizierung und Benutzerkonten, die Suchfunktion, den Warenkorb und den Bestellvorgang (Checkout) sowie den Bestellstatus und Kundenbenachrichtigungen. Probleme im Umfeld und Produktmängel, die außerhalb dieses Umfangs lagen, wurden als Abhängigkeiten erfasst.

Die QA-Ingenieure stellten sicher, dass sowohl die bestehenden als auch die neu erstellten Tests die geschäftlichen Anforderungen, die Vorgaben des Frameworks und die Regeln zur Rückverfolgbarkeit erfüllten, die manuelle Überprüfung bestanden und während des Validierungszeitraums stabil blieben. Vor der Annahme eines Tests mussten Fehler als Probleme des Tests selbst, der Daten, der Umgebung oder des Produkts klassifiziert werden. Diese Vorgehensweise sorgte dafür, dass das Endergebnis von 320 Tests die tatsächliche Wartbarkeit der Testsuite widerspiegelte und nicht lediglich deren Umfang.

Als Projektleistungen erhielt der Kunde das Klassifizierungsverzeichnis, den korrigierten Code, die CI-Konfiguration, ein Betriebshandbuch und ein technisches Backlog. Im Rahmen der Übergabe wurde zudem ermittelt, welche Umgebungsabhängigkeiten Maßnahmen seitens des Kunden erforderten und welche zukünftigen Automatisierungsinitiativen in einer separaten Skalierungsphase angegangen werden sollten.