Die Entdeckung-Phase gab uns die Gewissheit, dass es möglich war, im Rahmen des Pilotprojekts eine doppelt so hohe Geschwindigkeit zu erreichen, und wir konnten die kritischen Punkte klar identifizieren.

Leiter der Qualitätssicherung

Der Kunde ist ein großes Unternehmen aus der Lebensmittel- und Einzelhandelsbranche, das das gesamte Kundenerlebnis auf einer einzigen E-Commerce-Plattform verwaltet und über verschiedene Kanäle verkauft. Sein internes QA-Team war für eine Regressions-Suite mit etwa 5.000 Tests verantwortlich, die auf verschiedene Regionen und Rollen verteilt waren. Das Unternehmen strebte eine Steigerung seines Marktanteils an und musste neue Funktionen schneller auf den Markt bringen, weshalb sich die Qualitätssicherung weiterentwickeln musste, anstatt zu einem Hemmnis zu werden.

Die Qualität war nie das Problem. Das Problem war die Geschwindigkeit. Der Kunde wollte keinen weiteren Pilotversuch mit verschiedenen Tools. Er benötigte ein stufenweises, evidenzbasiertes Programm mit klaren Validierungskriterien. a1qa wurde beauftragt, herauszufinden, wo innerhalb des Zyklus tatsächlich Zeit verloren ging, einen schnelleren Mechanismus in einem begrenzten Umfang zu demonstrieren und diesen nur dort zu skalieren, wo die Daten dies rechtfertigten.

Die Herausforderung

Da es keinen klar definierten Verantwortlichen gab, dauerte die Entscheidung über die Veröffentlichung etwa zwei Wochen, und die Testsuite war so umfangreich geworden, dass bereits das Hinzufügen eines einzigen Tests den nächsten Regressionstestzyklus verlangsamte. Die üblichen Lösungen hatten bereits ihre Grenzen erreicht. Eine stärkere Automatisierung, die Einbindung weiterer Mitarbeiter oder die Ausführung der Testsuite über Nacht machten keinen Unterschied mehr.

Der Engpass lag nicht in der Anzahl der Tests. Er lag in der Struktur des Zyklus. Vor jeder Überprüfung wurden komplexe Konfigurationen der Benutzeroberfläche durchgeführt. Die gleichen, aus Sicht der Konfiguration äquivalenten Fälle wiederholten sich immer wieder. Die Triage führte dazu, dass die Ingenieure die Fehler manuell erneut überprüfen mussten, ohne dass es einen klaren Verantwortlichen gab. Und jede Entscheidung über die Freigabe basierte auf Schätzungen statt auf Daten.

KI verändert die Wirtschaftlichkeit dieser vier Faktoren, jedoch nur dann, wenn sie in den Prozess selbst integriert wird, anstatt als externes Element hinzugefügt zu werden. Das Programm befasste sich gleichzeitig mit diesen vier Kostenfaktoren: der anfänglichen Konfiguration, redundanten Ausführungen, der manuellen Fehleranalyse und dem Fehlen eines klaren Signals für Entscheidungen über Markteinführungen.

Das Projekt wurde nach einem Festpreis-Modell und in Phasen mit Validierungspunkten durchgeführt, sodass der Kunde es in jeder dieser Phasen stoppen konnte: Jede Phase endete mit einem Validierungspunkt, und die nächste Phase wurde nur dann finanziert, wenn die Ergebnisse durch Belege untermauert wurden. Die Investition erfolgte niemals vor der Validierung, und das Team trug vom ersten Tag an gemeinsam die Verantwortung für jedes Unterstützungstool, jede Kennzahl und jeden Triage-Prozess, wodurch sichergestellt wurde, dass das Wissen nach Beendigung der Zusammenarbeit mit a1qa innerhalb der Organisation verblieb. Die Arbeit erfolgte nach einem agilen Modell mit iterativen Lieferungen und wurde von einem multidisziplinären Team durchgeführt, das sich aus einem QA-Leiter, zwei Automatisierungsingenieuren, einem Testdesigner und einem DevOps-Ingenieur zusammensetzte, der für die Ausführung in der Cloud verantwortlich war.

Entdeckung

Diagnose kritischer Punkte. In einer Entdeckung-Phase mit festgelegtem Umfang wurden die Hypothesen unter Verwendung des kundeneigenen Codes und der Pipeline validiert. Anschließend wurde die Entscheidungsfindung bezüglich der Releases in neun konkrete kritische Punkte unterteilt, die sich auf die Definition des Umfangs, die automatisierte Ausführung, die Triage, die erneute Ausführung und die endgültige Entscheidung bezogen. Anstatt zu versuchen, alles auf einmal anzugehen, definierte a1qa gemeinsam mit dem QA-Leiter bewusst einen begrenzten Umfang, der sich auf eine bestimmte Kombination aus Rolle und Region beschränkte. Dieser Ansatz ist leichter messbar, im Fehlerfall kostengünstiger und liefert dem Kunden konkrete Daten, bevor er größere Verpflichtungen eingeht.

Pilot

KI-gestütztes Testdesign. Ein LLM unterstützte das Testdesign. Es generierte Kandidatenfälle aus vorhandenen User Stories und Spezifikationen, identifizierte Abdeckungslücken gegenüber Codeänderungen und erstellte realistische Testdaten für Szenarien mit mehreren Regionen und Rollen. Ein QA-Ingenieur überprüfte jedes KI-generierte Artefakt vor der Aufnahme in die Suite und stellte sicher, dass die Abdeckung dort wuchs, wo tatsächlich Risiko bestand.

KI-gestützte Testautomatisierung. Die langsamen Konfigurationsschritte der Benutzeroberfläche wurden durch KI-vorbereitete API-basierte Vorbedingungen ersetzt, die das System in Millisekunden statt Minuten in den erforderlichen Zustand versetzen konnten. Die vor jeder Ausführung benötigte Anfangskonfiguration wurde zwischen Testgruppen geteilt, die Ausführungen wurden für verschiedene Kombinationen aus Region, Rolle und Modus parallel durchgeführt, und selbstheilende Lokalisatoren absorbierten die üblichen Änderungen der Benutzeroberfläche und verhinderten Testfehler. Das Ergebnis war eine leichtere, schnellere und vom eigenen Team des Kunden leichter wartbare Automatisierungsschicht.

KI-gestützte Triage und Fehlerklassifizierung. Die Triage stellte einen der größten versteckten Kostenfaktoren dar. a1qa wies jedem Fehler in jeder Prozessphase einen bestimmten Verantwortlichen zu und trainierte Klassifizierungsmechanismen auf der Grundlage von Fehlermustern, um die Fehler als Umgebungs-, Test- oder Produktprobleme einzustufen. Die Erkennung instabiler Tests reduzierte die Anzahl der Fehlalarme, während automatische Wiederholungsläufe die umgebungsbedingten Fehler bearbeiteten. Infolgedessen mussten die Ingenieure die Protokolle nicht mehr manuell überprüfen und konnten sich wieder auf die Behebung von Produktproblemen konzentrieren.

Phase 2

Intelligenz für fundierte Entscheidungen. Jede Entscheidung zur Veröffentlichung war mit einem bestimmten Build verknüpft und wurde zu Zwecken der Rückverfolgbarkeit und der Prüfung gespeichert. Anstatt sich auf Schätzungen zu stützen, nutzten die Teams tatsächliche Test- und Qualitätsdaten. Für jeden Build konnten die Verantwortlichen einsehen, was freigegeben, was zurückgestellt worden war und warum.

Phase 3

Skalierbare Ausführung in der Cloud. Die Suite wurde auf einer elastischen Cloud-Infrastruktur ausgeführt, die Web- und Mobile-Abläufe abdeckte, einschließlich der Auslieferungs- und Checkout-Prozesse. a1qa beseitigte konfigurationsbedingte Wiederholungsläufe, unterteilte die geschäftskritische Suite so, dass sie ausschließlich bei relevanten Ereignissen im Zusammenhang mit Kundenversionen ausgeführt wurde, und skalierte die Kapazität bei Bedarf für parallele Ausführungen. Aus einem festen nächtlichen Ausführungsfenster wurde eine flexible Kapazität, die das Team bei Bedarf erweitern konnte, wenn eine Version dies erforderte.