„Shift Left on the Right” bezeichnet einen kombinierten Testansatz, der frühe Parallelisierung von Entwicklung und Test mit aktivem Monitoring nach dem Go-live verbindet. Testfälle entstehen bereits vor dem Coding, werden im Sprint mehrfach genutzt und anschließend als synthetisches Monitoring in der Produktion wiederverwendet. So deckt derselbe Artefakt-Pool Fehler ab, bevor Kunden sie bemerken.
Das Wichtigste in Kürze
- Synthetisches Monitoring mit wiederverwendeten UI-Testfällen ermöglicht proaktive Fehlererkennung in Produktion, bevor echte Kunden einen Ausfall bemerken.
- Testautomatisierung vor Go-live und synthetisches Monitoring in Produktion nutzen dieselben Artefakte, statt parallel zwei getrennte Testsets aufzubauen und zu pflegen.
- Der Fast-Feedback-Loop im Sprint wird durch ein bewusst verkleinertes Testset erreicht: Feature-relevante Tests plus priorisierte Regressionstests, bis die selbst gewählte Zeittoleranz des Teams erreicht ist.
- In Produktion dürfen nur vorab definierte synthetische Daten genutzt werden, und der Testfall muss als Monitoring-Lauf erkennbar sein, damit Kundenauswertungen und Web-Tracking nicht verfälscht werden.
Warum sich Testaktivitäten trotz agiler Arbeitsweise am Ende stauen
Auch in agilen Teams und im DevOps-Modell sammeln sich die Testaktivitäten kurz vor dem Go-live. Das ist kein Wasserfall-Problem, das mit der Agilität verschwunden wäre. Jedes Feature durchläuft für sich betrachtet einen linearen Ablauf: irgendwann beginnt das Team mit der Arbeit daran, irgendwann geht es live, dazwischen wird entwickelt und getestet.
Das Team beschäftigt sich nicht von Anfang an mit allen Features gleichzeitig. Es startet mit einem, bringt es zur Reife, geht zum nächsten über. Genau dadurch entsteht vor dem Go-live ein Stau der Prüfaktivitäten. Und am Ende ist meist der Test schuld, der nicht fertig wird.
Björn Scherer, der aus dem Versicherungsumfeld bei Cosmos Direct kommt, beschreibt zwei gegensätzliche Antworten auf dieses Muster: Shift Left zieht Aktivitäten nach vorn, Shift Right verschiebt einen Teil der Beobachtung in die Produktion. Beide Ansätze haben Charme. Die interessante Frage ist, wie man sich aus beiden Welten bedient.
Shift Left heißt parallelisieren, nicht nur früher anfangen
Früher anfangen allein bringt nichts. Wer dieselbe Mechanik nur vorverlegt, erzeugt den Stau an einer anderen Stelle. Der Hebel liegt darin, Themen klein zu schneiden, damit sie parallel bearbeitbar werden.
Statt eine User Story als Block fertigzustellen und dann im Team weiterzureichen, lohnt es sich, einzelne Akzeptanzkriterien so weit zu bringen, dass das erste schon parallel betrachtet werden kann, während das zweite noch entsteht. Sobald das erste getestet ist, wird das zweite entwickelt.
Ein größerer Schritt ist, mit mehreren Disziplinen gleichzeitig auf ein Feature zu schauen. Auf Codeebene führt das Richtung Test-Driven Development, auf fachlicher Ebene Richtung Acceptance Test-Driven Development. Das Prinzip bleibt dasselbe: Entwicklung und Test parallelisieren, statt sie hintereinanderzuhängen.
Die fachliche Definition lässt sich vorziehen, der technische Glue-Code nicht
Der wertvolle Teil eines Tests ist seine fachliche Definition, und die kennst du von Anfang an. Bevor jemand ein Feature baut, steht fest, was es können soll. Diesen Teil kannst du schon ausführbar formulieren oder so schreiben, dass er später ausführbar wird.
Was sich nicht vorziehen lässt, ist der technische Anteil. Ein Feld in Selenium zu selektieren funktioniert erst, wenn die UI existiert. Aber dieser Glue-Code ist der letzte Schritt, nicht der erste. Die fachlich motivierten Testfälle entstehen vorher.
Das Ziel sind Testfälle, die auf der obersten Ebene keine Technik mehr enthalten, sondern rein fachlich motiviert sind. Über einen Keyword-Driven-Ansatz lässt sich das erreichen. Welche Form ein Team wählt, ob Gherkin oder Keyword-Driven, bleibt dabei dem Team überlassen.
Fast Feedback braucht abgestufte Testsets nach Schmerzgrenze
Schnelles Feedback für die Entwicklungsteams setzt eine höhere Deployment-Häufigkeit voraus, mindestens auf der Testumgebung. Ein Deployment erlaubt höhere Teststufen: nicht nur Unit-Tests in der Build-Pipeline, sondern auch API-Tests und darüber hinaus UI- oder End-to-End-Tests. So werden Fehler gefunden, die im Unit-Test nicht auffallen.
Niemand führt in zehn Minuten tausende UI-Tests durch. Deshalb arbeitet jedes Team mit einem Subset. Den Kern bilden die Testfälle zum aktuellen Feature. Dieses Set wird mit Regressionstests aufgefüllt, bis die Schmerzgrenze für schnelles Feedback erreicht ist.
Die Zeitgrenze gibt das Team selbst vor. Zehn Minuten, eine Viertelstunde, eine halbe Stunde, je nach Toleranz. Daran orientiert sich die Größe des Testsets, und es lässt sich pro Sprint neu zuschneiden. Die Auswahl der Regressionsfälle läuft über Tagging und Priorisierung, nicht über automatische Generierung.
Bei größeren Anwendungen lässt sich das stufen: tagsüber das fokussierte Set, nachts ein breiteres Regressionsset, bei Bedarf ein noch größeres im Wochenrhythmus. So bleibt das schnelle Feedback erhalten, ohne die Breite der Abdeckung dauerhaft zu opfern.
Synthetisches Monitoring schließt die Lücke, wenn keine Kunden auf dem System sind
Klassisches Monitoring wertet aus, was reale Nutzer auf dem System tun. Es schreibt Logs weg und stellt darauf basierende Auswertungen bereit. Der Haken: Es funktioniert nur, solange Kunden aktiv sind. In der Mittagspause oder nachts fehlt die Datenbasis.
Synthetisches Monitoring führt deshalb proaktiv Use Cases aus, zyklisch und unabhängig davon, ob gerade jemand das System nutzt. So fällt ein Defekt auf, bevor der erste Kunde ihn bemerkt. Im besten Fall ist er behoben, bevor überhaupt jemand etwas merkt.
Der entscheidende Unterschied zu reinen Backend-Werkzeugen liegt in der Perspektive. Werkzeuge wie Dynatrace zeigen, in welchem Service ein Fehler liegt oder wo es langsamer wird. Aus Business-Sicht bleibt dann die Frage offen, wo der Kunde gestört ist.
Wir zäumen das Pferd von der anderen Richtung auf. Weil wir es aus Kundensicht ausführen, wissen wir das direkt, und nutzen das andere dann zur Fehleranalyse. Björn Scherer
Bestehende Testartefakte in die Produktion weiterverwenden
Der Kern des Ansatzes ist Wiederverwendung. Die Artefakte, die links vom Go-live entstehen, sollen nicht beim Release liegen bleiben, sondern rechts davon in der Produktion weiter Nutzen bringen.
Aus dem Regressionsset, das spätestens zur Abnahme vorliegen muss, wählt das Team ein bis drei besonders relevante Use Cases aus. Diese laufen anschließend im synthetischen Monitoring weiter. Spätestens zur Abnahme müssen die Tests ohnehin zur Anwendung passen, sonst stellst du eine Anwendung live, deren Tests nicht mehr greifen.
Die Logik schließt sich: Ist ein Use Case wichtig genug, um in Produktion zu laufen, ist er auch wichtig genug für den Fast-Feedback-Loop. Solche Use Cases werden bei Änderungen zuerst angepasst. Die meisten Anwendungen haben ein bis zwei Kern-Use-Cases, die dafür infrage kommen.
Bei Cosmos Direct sind das Online-Antragsstrecken. Am Ende einer Strecke ist die Versicherung abgeschlossen, nicht nur ein Antrag verschickt. In einer Kfz-Versicherung gibt es rund 1,4 Millionen Wege durch die Strecke. Vollständig testen lässt sich das nicht. Für den Betrieb reicht der Nachweis, dass der Happy Path und zwei, drei Varianten durchlaufen.
Warum UI-Tests, obwohl sie als anfällig gelten
Die naheliegende Frage lautet, warum man dafür anfällige UI-Tests nimmt statt stabilerer API-Tests. Die Antwort hat mehrere Gründe, und Stabilität ist einer davon, an dem das Team unabhängig viel gearbeitet hat.
- Wiederverwendung: Die UI- und End-to-End-Tests existieren bereits aus dem Entwicklungsprozess. Es muss nichts Neues aufgebaut werden.
- User-Sicht: UI- und End-to-End-Tests bilden echte User Journeys ab. Diese Perspektive lässt sich über reine API-Tests deutlich schlechter erzeugen.
- Kein Extra-Tooling: Ein zusätzliches Monitoring-Werkzeug bräuchte jemanden im cross-funktionalen Team, der es beherrscht. Wenn das eine Person ist, liegt der Busfaktor bei eins. Mit dem bestehenden Test-Stack entfällt dieses Risiko.
- Früher Einstieg: Die Tests lassen sich früh in den Standardtestprozess einbinden, sodass Probleme an den Monitoring-Use-Cases früh auffallen.
Test-Flakiness bleibt das große Thema. Wer Tests in die Produktion verlängert, muss vorher in deren Stabilität investiert haben. Langsamere Antwortzeiten fallen dabei indirekt auf: Reagiert die UI träger als das eingestellte Timeout, schlägt der Test fehl. Die Toleranzen wurden bewusst erhöht, um nicht durch Flakiness ständig Fehlalarme auszulösen.
Testdaten in der Produktion sind die eigentliche Hürde
Tests in der echten Produktion auszuführen, war intern ein langer Kampf. Reale Kundendaten sind dabei tabu. Für jeden Use Case wird definiert, welche Daten er braucht und welche im System vorhanden sein müssen. Diese synthetischen Daten werden einmalig in Produktion eingelegt, und die Tests dürfen ausschließlich darauf arbeiten.
Der Use Case muss zur Datenlage passen. Eine Antragsstrecke verhält sich für einen bestehenden Account anders als für einen Neukunden. Bevor ein Use Case überhaupt im Produktionsmonitoring laufen darf, muss er auf Pre-Production nachweisen, dass er nichts kaputt macht.
Dafür müssen die Anwendungen den synthetischen Verkehr vom echten unterscheiden können. Der Use Case signalisiert, dass er der Monitoring-Lauf ist. Sonst verfälschst du Auswertungen: Bei einem Nischenprodukt kann ein Monitoring alle 15 Minuten ein Vielfaches der echten Kundenzahl erzeugen und damit jede fachliche Statistik verzerren.
Auch Web-Tracking aus dem E-Commerce darf nicht verfälscht werden, etwa per Cookies abgeschaltet. Praktisch heißt das: Dein Testframework braucht einen Monitoring-Modus. Derselbe Testfall nutzt auf der Testumgebung andere Daten als in Produktion. Das erfordert etwas Tuning, ist aber machbar.
Alerting und Reporting machen die Ergebnisse handhabbar
Synthetisches Monitoring ist nur so nützlich wie die Reaktion darauf. Ein zentrales Control Center ist ohnehin aktiv und nimmt die Alerts entgegen, integriert in die bestehenden Unternehmensprozesse. Das greift besonders nachts, wenn das Team nicht vor Ort ist.
Der nächste Schritt dreht den Weg um und alarmiert die Teams direkt. Verantwortlich für eine Anwendung ist das Team, das sie entwickelt. Eine Fastlane spielt das Problem direkt dorthin zurück, während der offizielle Alerting-Weg bestehen bleibt.
Ob ein Team das synthetische Monitoring überhaupt nutzt, bleibt ihm freigestellt. Der Gedanke aus der DevOps-Migration lautet: Zeig Verantwortung für deine Anwendung. Sagt ein Team, es habe alles im Griff, ist auch das in Ordnung. Die zentrale Aufgabe ist, Infrastruktur und Methodik bereitzustellen, in die Teams ihre Use Cases einhängen können.
Ein Dashboard zeigt einem zentralen Bereitschaftsdienst schnell, ob eine einzelne Anwendung betroffen ist oder ein Flächenbrand vorliegt. Die nächste Ausbaustufe geht tiefer: Ursachen aus User-Sicht bewerten, erkennen, in welchen Schritten es schiefläuft, und das über die Historie aggregieren.
