QA-Automatisierung und Release Engineering für eine B2B-SaaS-Plattform aus den USA

Der Kunde ist ein in Boston ansässiges B2B-Softwareunternehmen, das eine Workflow-Automatisierungsplattform für Kunden im Mittelstand und im Enterprise-Segment in Nordamerika bereitstellt. Zu Beginn des Engagements verfügte das Unternehmen nach einer Series-C-Runde über einen jährlich wiederkehrenden Umsatz von rund 68 Millionen USD, mit einer Engineering-Organisation von 82 Personen. Sein Wachstumsplan erforderte eine deutliche Steigerung der Release-Geschwindigkeit ohne einen entsprechenden Anstieg der Produktionsstörungen.

Die Release-Geschwindigkeit war zur bindenden Beschränkung der Roadmap geworden. Das Unternehmen brachte rund 3,4 Produktions-Releases pro Monat aus, gegenüber einem Ziel von wöchentlichen Releases pro Team. Der Engpass war ein manueller Regressionszyklus, der vor jedem Release fünf bis sieben Tage in Anspruch nahm. Testautomatisierung war vorhanden, aber es wurde ihr nicht vertraut. Die Abdeckung lag bei rund 35 Prozent, und die Suite wies eine so hohe Flakiness-Rate auf, dass Ingenieure Fehlschläge erneut ausführten, statt ihnen nachzugehen, sodass echte Fehlschläge manchmal verworfen wurden. Eine Suite, der nicht vertraut wird, ist schlimmer als gar keine, denn sie kostet Zeit und liefert zugleich eine trügerische Sicherheit.

Entwichene Defekte nahmen mit dem Release-Volumen zu, mit sechs kritischen und achtzehn hochkritischen entwichenen Defekten im Quartal vor dem Engagement, von denen mehrere Enterprise-Kunden erreichten.

Einstellungen hatten das Problem nicht gelöst. QA-Automatisierungsingenieure in Boston verlangten eine Vergütung, die das Unternehmen gegenüber Feature-Einstellungen schwer rechtfertigen konnte, und zwei QA-Einstellungen waren beide innerhalb weniger Monate in Feature-Teams gewechselt.

Der Kunde wählte Corpshore Colombia in erster Linie aufgrund von Zeitzone und Talent. Medellín ist ein anerkannter Technologiestandort mit einer starken Engineering-Basis, und QA und Release Engineering sind kollaborationsintensive Funktionen, bei denen der Kunde aus einer früheren Offshore-Erfahrung geschlossen hatte, dass asynchrone Übergaben und nicht mangelndes Können die eigentliche Ursache des Scheiterns waren. Corpshore schlug vor, das Engagement als Fähigkeitstransfer statt als Kapazitätsmiete zu behandeln, und verpflichtete sich, dem Kunden eine vertrauenswürdige, dokumentierte Testsuite und einen Release-Prozess zu hinterlassen, den seine eigenen Ingenieure betreiben können, mit definierten Wissenstransfer-Meilensteinen. Der von Corpshore vorgeschlagene Lead verbrachte zwei Tage mit dem Plattformteam des Kunden und identifizierte die Flakiness-Rate und nicht die Abdeckung als das primäre Problem, was das Verständnis des Kunden neu ausrichtete.

Zweiundzwanzig Ingenieure in Medellín: zwei Technical Leads, sechs Senior, zehn Mid-Level und vier Junior, verteilt auf QA-Automatisierung, DevOps und Release Engineering. Das Team arbeitet von 09:00 bis 18:00 Uhr US Eastern, auf derselben Uhr wie Boston, und nimmt live an den Standups teil. Stack: TypeScript, Playwright, Jest, GitHub Actions, Terraform, AWS, Datadog. Alle Ingenieure sind dem Account fest zugeordnet.

Flakiness beheben, bevor Abdeckung hinzukommt. Die ersten acht Wochen befassten sich mit der Zuverlässigkeit der Suite statt mit der Abdeckung, ausgehend von der Überlegung, dass das Hinzufügen von Tests zu einer nicht vertrauenswürdigen Suite das Problem verstärkt. Die Flakiness-Rate fiel von 32 Prozent auf unter 3 Prozent, bevor die Abdeckungsarbeit begann. Abdeckung dort, wo das Risiko ist. Die Erweiterung der Abdeckung wurde nach der Historie der Produktionsstörungen und dem Code-Churn priorisiert statt nach Modul, und konzentrierte den Aufwand dort, wo entwichene Defekte tatsächlich ihren Ursprung hatten.

Infrastruktur für Progressive Delivery. Feature-Flagging und eine Canary-Release-Infrastruktur entkoppelten Releases von Deployments und ermöglichten ein Rollback ohne einen vollständigen Release-Zyklus, wodurch die Häufigkeit steigen konnte, ohne dass die Störungsschwere entsprechend zunahm.

Dokumentierter Wissenstransfer. Vier definierte Transfer-Meilensteine mit Dokumentation und Freigabe durch den Kunden stellen sicher, dass das eigene Team des Kunden die Pipeline betreiben kann.

Release-Häufigkeit

Die Produktions-Releases stiegen bis zum Monat 12 von 3,4 pro Monat auf 24,6 und übertrafen das Ziel von wöchentlichen Releases pro Team. Der manuelle Regressionszyklus fiel von fünf bis sieben Tagen auf unter vier Stunden. Entwichene Defekte fielen trotz des Volumenanstiegs in jedem Schweregrad, wobei kritische von sechs pro Quartal auf eins und hochkritische von achtzehn auf vier fielen.

Die Testabdeckung stieg von 35 Prozent auf 87 Prozent bei einer unter 3 Prozent gehaltenen Flakiness-Rate, und die eigenen Ingenieure des Kunden erweitern die Suite nun selbstständig, das erklärte Ziel des Fähigkeitstransfers.

Die Testsuite, die Release-Pipeline und die Infrastruktur für Progressive Delivery gehören dem Kunden und werden gemeinsam betrieben. Alle vier Wissenstransfer-Meilensteine wurden abgeschlossen. Der Kunde hat das Engagement auf Platform Reliability Engineering ausgeweitet, was sein VP als eine Wahl statt einer Abhängigkeit beschreibt.