Shift Left

Shift Left bedeutet, Qualitätssicherung so früh wie möglich in den Entwicklungsprozess zu integrieren, statt sie nachgelagert zu betreiben. Das beginnt bei sauber geschnittenen User Stories, zieht sich über toolgestützte Codequalität direkt in der Entwicklungsumgebung und endet bei einer breiten Unit-Test-Abdeckung als Basis für alle weiteren Teststufen.

Das Wichtigste in Kürze

• Unit Tests sind die Grundvoraussetzung für jede Shift-Left-Strategie: Ohne dieses feinmaschige Fallnetz auf Code-Ebene lässt sich keine ausreichende Abdeckung auf höheren Teststufen wirtschaftlich realisieren.
• Consumer Driven Contract Testing mit Tools wie PACT ermöglicht es, API-Kompatibilität zwischen Services bereits lokal gegen automatisch generierte Mocks zu prüfen, ohne eine vollständige Integrationsumgebung aufzubauen.
• Qualitätsfeedback direkt in der IDE, zum Beispiel zyklomatische Komplexität inline angezeigt, ist einem späteren Build-Server-Report überlegen, weil der Entwickler sofort reagiert, statt einen zusätzlichen Korrekturzyklus zu drehen.
• Teams, die jeden Entwickler eine eigene User Story alleine umsetzen lassen und die Tester erst am Sprintende einschalten, bauen einen Mini-Wasserfall im Sprint nach und riskieren, am Sprintende keine einzige Story vollständig fertigzustellen.
• Eine pauschale 100-Prozent-Unit-Test-Abdeckung als Ziel ist kontraproduktiv; sinnvoller ist es, kritische Geschäftslogik explizit zu annotieren und für genau diesen Code vollständige Abdeckung verbindlich einzufordern.

Was Shift Left in der Qualitätssicherung wirklich bedeutet

Shift Left heißt, Qualität so früh wie möglich im Entwicklungsprozess abzusichern, nicht nachgelagert am Ende. Das Links-Rechts bezieht sich auf den Prozess von der Anforderung bis zur Auslieferung. Qualität nach links zu ziehen bedeutet, die Dinge so früh wie möglich zu tun.

Der Grundgedanke ist mehrstufig: In der User Story lässt sich bereits Qualität sichern. Im Team folgt eine breite Abdeckung auf Unit-Test-Ebene. Darauf bauen die weiteren Qualitätsebenen auf, die ineinandergreifen, sich ergänzen und möglichst nicht redundant sind. Über eine Continuous-Integration- und Delivery-Pipeline wird das Ergebnis qualitätsgesichert ausgeliefert.

Dieses Wissen ist nicht neu. Die Erfahrung aus Jahrzehnten Softwareentwicklung hat zu agilen Prozessen geführt, in denen die Zusammenarbeit zwischen Entwicklung und Test wieder selbstverständlich wurde. Mit DevOps wächst nun auch Operations in diesen integrierten Ansatz hinein.

Die Anforderung ist der größte Hebel für Qualität

Der größte Hebel liegt am Anfang: gut beschriebene und umsetzbare Anforderungen. Agile Prozesse bieten dafür längst etablierte Methoden, wie sich User Stories schneiden, reviewen und gegen Qualitätskriterien prüfen lassen, und zwar genau dann, wenn es am kostengünstigsten ist.

Der eigentliche Knackpunkt liegt eine Ebene über den einzelnen Stories, im Mindset des Teams. In vielen Teams treibt die historisch gewachsene Struktur das Slicing der User Stories. Ein klassisches Muster: Jeder Entwickler schnappt sich am Sprint-Anfang eine eigene Story, setzt sie allein um, und zwei Tester prüfen in den letzten zwei Tagen alles auf einmal. Das ist ein Mini-Wasserfall im Sprint.

Die Begründung dafür klingt harmlos, ist aber das Problem. “Wir wollen uns nicht gegenseitig im Weg stehen” ist ein Zugang, mit dem echte Zusammenarbeit schwierig wird. So wird der Schnitt einer Story danach ausgerichtet, was eine einzelne Person allein erledigen kann, nicht danach, welchen Wert das Ergebnis liefert.

Schneide User Stories vertikal, nicht nach Bequemlichkeit

Nicht die Bequemlichkeit der Entwickler sollte das Slicing treiben, sondern die Werthaltigkeit des Ergebnisses. Ein vertikaler Schnitt umfasst alle Ebenen einer Funktion und liefert am Ende des Sprints etwas Lauffähiges, das sich testen und nutzen lässt.

Ein horizontaler Schnitt erzeugt dagegen tote Zwischenstände. Wer nur die Oberfläche einer Funktion in eine Story packt und die zugehörige Datenbank erst drei Sprints später entwickelt, hat etwas gebaut, das sich weder testen noch verwenden lässt. Es hat keinen Mehrwert.

Das Ziel jeder Iteration ist ein fertiges Stück Mehrwert: qualitätsgesichert, funktionsfähig, auslieferbar. Vertikal geschnittene Stories sind besser absicherbar, weil sich eine abgeschlossene Funktion auch abgeschlossen testen lässt.

Scrum sieht ein priorisiertes Sprint-Backlog vor. Theoretisch arbeitet das gesamte Team zuerst an der höchstprioren Story und stellt sie fertig, dann an der nächsten. Von fünf committeten Stories sind am Ende vielleicht nur drei fertig, aber diese drei sind wirklich fertig. Beim Mini-Wasserfall dagegen ist am Ende potenziell nichts fertig, weil alle Stories gleichzeitig angefangen und keine abgeschlossen wurde.

Stop starting, start finishing.

Alexander Vukovic

Warum sich Teams gegen Zusammenarbeit sperren

Hinter dem Festhalten am alten Vorgehen steckt oft Angst, kein Unwissen. Häufig sind es gerade die größten Know-how-Träger, die seit Jahrzehnten im Unternehmen sind und fürchten, sich ersetzbar zu machen, wenn sie ihr Wissen teilen.

Für solche Menschen ist ein cross-funktionales Team eine potenzielle Gefahr, weil andere dort dasselbe Wissen erlangen sollen. Das Mindset zu verändern, gelingt nur durch Begleitung über mehrere Iterationen und durch Vorzeigen, dass die Befürchtung unbegründet ist.

Das Argument lässt sich entkräften: Ein Junior wird nie in drei Monaten nachholen, was sich jemand in dreißig Jahren erarbeitet hat. Wenn er aber bestimmte Tätigkeiten übernehmen kann, falls der Erfahrene ausfällt, profitieren alle. Eigentlich ist das eine Aufgabe für den Scrum Master. In der Praxis ist diese Rolle in vielen Scrum-Implementierungen schon zu Beginn wegoptimiert worden.

Die Entwicklungsumgebung bringt Qualität direkt in den Code

Die IDE spielt eine größere Rolle, als viele erwarten. Über die Entwicklungsumgebung lässt sich bereits sehr viel Qualität in das Coding selbst bringen, lange bevor der Build-Server überhaupt anläuft.

Refactoring-Funktionen sind ein Beispiel. Eine Klassenmethode projektweit konsistent umbenennen zu können, statt sich in jeder Datei die Finger zu brechen, ist eine Kleinigkeit, die moderne IDEs heute leisten. Im Java-Umfeld ist IntelliJ am verbreitetsten, auf der .NET- und C#-Seite Visual Studio, dazwischen das kostenlose, schlanke und schnelle Visual Studio Code.

Plugins liefern unmittelbares Qualitätsfeedback im Editor. Ein Plugin für Visual Studio Code misst die zyklomatische Komplexität einer Methode inline, während du sie schreibst. Schreibst du zu viele verschachtelte Bedingungen hinein, meldet es direkt über dem Code, dass die Komplexität zu hoch ist.

Dieses Feedback gehört zu Shift Left. Würde dieselbe statische Code-Analyse erst auf einem Jenkins oder GitLab laufen, hättest du eine Schleife mehr gedreht: warten, hineinschauen, Tadel bekommen, umbauen. Im Editor siehst du das Problem im Moment des Schreibens. Das spart dem gesamten Prozess Zeit.

Werkzeuge wie SonarQube sind im Enterprise-Umfeld für statische Code-Analyse etabliert. Doch wenn dasselbe Feedback sofort verfügbar ist, sollte es auch sofort genutzt werden, statt auf Server-Analysen und befüllte Dashboards zu warten.

Codequalität lässt sich nicht nachträglich hineintesten

Codequalität ist entweder da oder sie ist nicht da. Über das Testing lässt sich keine Codequalität in eine Software hineintesten, das Testing kann so gut sein, wie es will. Wer Qualitätskriterien wie Naming, Coding Conventions oder fehlende Code-Duplizierung ignoriert, baut auf einer Basis, auf der sich später schlecht weiterarbeiten lässt.

Der Mechanismus ist absehbar. Steht das Team unter Druck, möglichst viel Funktionalität in kurzer Zeit zu liefern, wird ohne Rücksicht auf Qualität rausgehauen, was geht. Das funktioniert, aber nicht lange. Irgendwann fällt es zurück, und ausbaden müssen es meist die Entwickler, weil der Lieferdruck bleibt und bei erfolgreicher Software sogar steigt.

Daraus folgt eine einfache Regel für die tägliche Arbeit: Was sich werkzeuggestützt und ohne nennenswerten Zeitaufwand investieren lässt, solltest du investieren. Für die langfristige Werthaltigkeit der Software ist das Grundvoraussetzung.

Wie viel Unit-Test-Abdeckung sinnvoll ist

Unit-Tests sind die Basis von Shift Left, das feinmaschige Fallnetz. Sie sind isoliert lauffähige Regressionstests im Kleinen, die sicherstellen, dass der Code weiterhin dasselbe tut wie zuvor. Mit diesem Fallnetz lassen sich Änderungen, auch große Architektureingriffe, mit der Sicherheit durchführen, dass eingebaute Fehler auffallen.

Diese Abdeckung leistet keine andere Teststufe. Wer dieselbe Coverage auf höheren Ebenen erreichen wollte, müsste unverhältnismäßig viel mehr investieren, was kommerziell nicht tragbar ist.

Die ideale Unit-Test-Abdeckung ist nicht 100 Prozent. Viele Dinge sind nicht sinnvoll auf Unit-Ebene testbar. Ein Unit-Test soll isoliert laufen, eine kleine Einheit prüfen und in Millisekunden bis maximal Sekunden durchlaufen, nicht in Stunden. End-to-End- und Integrationstests gehören deshalb auf die Stufen darüber.

Das Standardbeispiel sind Getter- und Setter-Methoden. Testest du eine Setter-Methode nur, um die Quote zu erreichen, hast du erfolgreich die Zuweisungsfunktionalität von Java oder .NET getestet. Das bringt keinen Mehrwert, es ist Waste.

Dazu kommt Legacy Code. Wer zehn Jahre lang ohne Unit-Tests entwickelt hat, startet bei null Prozent Abdeckung. Kein Management und kein Kunde wird bezahlen, dass jahrelang gewachsener Quellcode nachträglich unter vollständige Abdeckung gebracht wird. Eine Vorgabe von 100 Prozent ist hier kein Ziel, und auch eine Steigerung von sieben auf zehn Prozent motiviert niemanden.

Der bessere Weg führt über kritischen Code. Definiere taxativ, welche Codeteile auf jeden Fall unter Abdeckung stehen sollen, etwa Business-Logik, die mit monetären Werten rechnet. Diesen kritischen Code annotierst du, misst ihn und forderst dort 100 Prozent. Das ist unabhängig von Legacy Code und von Gettern und Settern und löst den Zielkonflikt auf.

API- und Contract-Tests schließen die Lücke zwischen Unit und Oberfläche

Bei Architekturen mit Microservices und APIs muss als Nächstes der API-Level abgesichert werden. Ein API-Test prüft nicht die grafische, sondern die programmierte Schnittstelle: Er schickt API-Calls und prüft das Ergebnis.

Zwischen Unit-Test und API-Test lässt sich eine weitere Ebene einziehen, das Consumer Driven Contract Testing. Eine API besteht immer aus einem Provider, der sie anbietet, und einem bis vielen Consumern, die sie nutzen. Damit sie sich unabhängig voneinander weiterentwickeln lassen, einigen sich beide Seiten auf einen Vertrag: welche Anfragen erlaubt sind und welche Antworten erwartet werden.

Das Open-Source-Werkzeug PACT zeichnet solche Verträge consumer-getrieben auf und legt sie zentral ab. Aus den Verträgen lassen sich automatisiert Mocks erzeugen, die Consumer oder Provider simulieren. So lässt sich ohne aufwendiges Setup mit Datenbank und Docker-Images bereits auf dem Entwicklungsrechner oder im CI-System gegen den Vertrag testen.

Der Gewinn ist frühes Feedback. Du erfährst sofort, ob alle Consumer noch zu einem geänderten Provider kompatibel sind. Gerade in Microservice-Architekturen und in Enterprise-Umgebungen mit Enterprise Service Bus oder Kafka, in denen viele Services Daten austauschen, ist diese Interaktion zentral.

Die folgende Schichtung verteilt die Verantwortung sinnvoll:

Die Testpyramide statt des Ice-Cone

Shift Left bedeutet auch, die Testpyramide zu schaffen statt des Testing-Ice-Cone. Die Pyramide hat unten viele Unit-Tests und oben wenig Oberflächenautomation. Der Ice-Cone als Anti-Pattern dreht das um: oben alles über die Oberfläche automatisiert, unten nichts.

Moderne Oberflächen werden meist mit React, Vue oder Angular gebaut, Svelte kommt auf. Sie holen ihre Daten über HTTP-, REST- oder GraphQL-Calls aus dem Backend. Häufig aggregiert ein Backend for Frontend diese Calls zu einer UI-API. Auf dieser API-Ebene, eine Stufe unter der Oberfläche, lässt sich Kombinatorik prüfen, ohne hundert Varianten durch die UI zu klicken. Das ist schneller und weniger änderungsanfällig.

Die UI selbst muss trotzdem getestet werden, sowohl auf korrektes Layout als auch auf Funktion. Doch die Oberflächenautomation ist nur ein kleiner Baustein. Wer die unteren Ebenen ernst nimmt, kann sich oben auf das beschränken, wofür diese Ebene gedacht ist: fachliche End-to-End-Tests.

Automatisiertes Ausliefern setzt die ganze Kette voraus

Häufige Releases lassen sich nur über eine durchgängig automatisierte Continuous-Integration-, -Delivery- und -Deployment-Pipeline bewältigen. Der Idealzustand, den große Anbieter erreicht haben: Auf Knopfdruck läuft die gesamte Qualitätssicherung, das Ergebnis wird automatisch in Produktion deployed, dort erneut geprüft und überwacht, mit sofortigem Rückschluss, ob es funktioniert.

Dieser Automatisierungsgrad bringt neue Risiken. CI-Systeme sind zum Angriffsziel geworden, weil sich über sie direkt in den Code eingreifen lässt. Die Security automatisierter Pipelines ist ein eigenes großes Thema, für das es inzwischen sogar eine eigene OWASP-Top-10-Liste gibt. Kein Vorteil ohne potenziellen Nachteil, aber die Richtung ist eindeutig.