Entdecken Sie das TÜV-zertifizierte GoogleTest mit Agentic AI für C/C++-Tests!
Details ansehen »
Zum Abschnitt springen
Parasoft-Blog
„Shift-Left“ klingt einleuchtend, bis man merkt, dass die meisten Teams einfach nur ihre fehlerhaften Testgewohnheiten vorverlegen. Lesen Sie weiter, um zu erfahren, wie es wirklich funktioniert, wo Fehler auftreten und wie es aussieht, wenn Teams es richtig machen.
Zum Abschnitt springen
Shift-Left-Testing bedeutet, Fehler frühzeitig im Entwicklungsprozess zu erkennen, idealerweise noch während der Codeentwicklung. Ziel ist es, Fehler frühzeitig im Entwicklungszyklus zu finden und zu verhindern, wenn sie am einfachsten und kostengünstigsten zu beheben sind und der Code noch frisch im Gedächtnis ist.
Irgendwann wurde „Shift Left“ zum Lieblingsausdruck der Softwarebranche in Planungsbesprechungen und gleichzeitig zu dem, was die meisten Teams am schlechtesten beherrschen.
Die Idee ist wirklich gut: Mängel frühzeitig erkennen, anstatt sie später zu beheben, wenn sie teuer und peinlich sind. Ganz einfach.
Warum scheitern also so viele Shift-Left-Initiativen, führen zu mehr Reibungsverlusten für Entwickler und lassen die Qualität im Wesentlichen auf dem Ausgangsniveau zurück?
Meistens liegt es daran, dass „Shifting Left“ als „die gleichen Tests früher ausführen“ interpretiert wurde, anstatt als „Qualität von Anfang an einbauen“. Diese Unterscheidung ist von großer Bedeutung.
Die wirtschaftlichen Vorteile von Shift-Left-Testing sind gut belegt. Fehler, die während der Programmierung entstehen, aber erst beim Systemtest entdeckt werden, sind deutlich teurer zu beheben als Fehler, die bereits in der Programmierphase gefunden werden. Die Gründe dafür liegen auf der Hand:
Die Zahlen bestätigen dies.
Das Systems Sciences Institute von IBM stellte fest, dass die Behebung von Fehlern in der Testphase sechsmal so teuer ist wie in der Entwicklungsphase und in der Produktion sogar 15-mal so teuer. Das CISQ schätzte die Kosten mangelhafter Softwarequalität in den USA im Jahr 2022 auf 2.41 Billionen US-Dollar. Das sind keine Rundungsfehler.
Shift-Left-Testing ist eine praktische Antwort auf diese wirtschaftlichen Gegebenheiten – die hohen Kosten von Fehlern in späten Testphasen.
Hier ist die Variante des Shift-Left-Prinzips, die nicht funktioniert: Man nimmt seine bestehende Integrationstestsuite und plant deren Ausführung früher ein.
Das ist keine Linksverschiebung. Das sind lediglich langsame Tests im späten Entwicklungszyklus für unausgereiften Code. Das Ergebnis?
Ein subtilerer Fehler liegt darin, Shift Left lediglich als Testproblem zu betrachten, obwohl es sich eigentlich um ein Problem im Entwicklungsprozess handelt.
Wenn es nur darum geht, möglichst schnell mehr Fehler zu finden, hat man bereits akzeptiert, dass Fehler unvermeidlich sind. Diese Zielsetzung ist zu niedrig.
Das eigentliche Ziel von Shift-Left-Testing ist es, die Anzahl der Fehler von vornherein zu reduzieren , nicht sie nur schneller zu finden. Weniger Fehler zu finden, sollte ein Erfolgskriterium sein, kein Grund zur Sorge. Wenn Ihr statisches Analysetool im Laufe der Zeit weniger Probleme aufdeckt, funktioniert Shift-Left.
Die Fehlererkennung kann am weitesten nach links verlagert werden, nämlich in die Codierungsphase selbst, bevor irgendetwas eingecheckt oder getestet wird. Statische Analysetools untersuchen den Quellcode, ohne ihn auszuführen, und prüfen ihn auf Verstöße gegen Codierungsstandards, häufige Fehlermuster, Sicherheitslücken und strukturelle Probleme.
Der entscheidende Unterschied, den es hier zu verstehen gilt, liegt darin, was einen echten Fehlerfinder von einem prädiktiven Prüfprogramm unterscheidet.
Fehlerfinder verfolgen tatsächliche Datenabhängigkeiten und Kontrollflüsse, um reale, reproduzierbare Fehler zu identifizieren. Prädiktive Prüfer kennzeichnen Bedingungen, die möglicherweise ein Problem verursachen könnten, das zwar weiterhin wertvoll ist, aber einen anderen Interpretationsrahmen erfordert.
Entwickler, die die Ergebnisse von Predictive-Checkern als Fehlalarme einstufen, verkennen oft den Kern der Sache: Das Ergebnis ist real, selbst wenn der spezifische Fehler noch nicht aufgetreten ist. Die richtige Reaktion besteht darin, den Fehler zu beheben, nicht die Warnung zu ignorieren.
Für Compliance-orientierte Organisationen (Automobilindustrie, Luft- und Raumfahrt, Medizintechnik, Verteidigungssoftware) ist die statische Analyse der Durchsetzungsmechanismus für Codierungsstandards wie MISRA C, AUTOSAR C++14, DO-178C und andere.
Diese Standards existieren, weil bestimmte Codierungsmuster grundsätzlich unsicher sind, unabhängig davon, ob sie bereits einen sichtbaren Fehler verursacht haben. Die statische Codeanalyse wendet sie systematisch und umfassend an, ohne sich auf menschliche Prüfer verlassen zu müssen, die im Rahmen einer Codeüberprüfung alle Fehler aufdecken.
Durch die Integration in die IDE und CI-Pipeline eines Entwicklers verlagert die statische Analyse die Fehlererkennung bis zum Zeitpunkt der Codeerstellung. Der Entwickler sieht das Problem in derselben Sitzung, in der er den Code geschrieben hat, mit dem vollständigen Kontext und kann es innerhalb von Minuten statt Tagen beheben.
Unit-Tests, die tatsächlich frühzeitig in die Entwicklung integriert werden, sind nicht etwas, das Entwickler erst nach Fertigstellung einer Funktion durchführen. Sie erfolgen während der Entwicklung.
Ob Teams testgetriebene Entwicklung praktizieren (zuerst den Test schreiben) oder einfach nur eine hohe Unit-Test-Abdeckung als Disziplin aufrechterhalten, das Ergebnis ist dasselbe: Fehler treten sofort auf Funktionsebene zutage, ohne die Störungen einer vollständigen Integrationsumgebung.
Die Softwaretestpyramide bietet hier das richtige Denkmodell. Unit-Tests sind kostengünstig, schnell und spezifisch. Sie bilden die Basis. Funktions- und API-Tests stehen darüber. Langsame, teure UI- und manuelle Tests bilden die Spitze und dienen der Funktionsbestätigung, nicht der Fehlersuche. Ein Team, das diese Pyramide umkehrt und sich primär auf Tests am Ende des Testzyklus verlässt, um Fehler aufzudecken, betreibt kein Shift-Left-Testing, unabhängig davon, wann diese Tests ausgeführt werden.
Eine der praktischen Hürden für die Verlagerung des Testprozesses nach links besteht darin, dass Funktionstests häufig Abhängigkeiten erfordern, die nicht verfügbar sind:
Das Warten auf die Verfügbarkeit dieser Abhängigkeiten verschiebt das Testen standardmäßig nach rechts.
Servicevirtualisierung beseitigt diese Einschränkung. Durch die Simulation abhängiger Systeme können Teams Funktionstests, API-Tests und sogar Leistungs- und Sicherheitstests in einer realistischen Umgebung durchführen, lange bevor die reale Umgebung existiert. Tests, die bisher erst in einer späten Integrationsphase stattfanden, können nun direkt auf dem Entwicklungsrechner durchgeführt werden.
Das hat einen interessanten Nebeneffekt für Sicherheitstests. Wenn die abhängigen Systeme simuliert werden, können sie sich absichtlich bösartig verhalten: Sie können sie mit fehlerhaften Daten überfluten, unerwartete Fehlerzustände auslösen oder Grenzfälle testen, die in einem realen Testlabor schwer oder gar nicht realisierbar wären. So erreichen Sie nicht nur eine frühere Abdeckung, sondern auch eine umfassendere Sicherheitsabdeckung.
Denselben Ansatz speziell für Performance-Tests finden Sie unter „ Performance-Tests mit einem Shift-Left-Ansatz optimieren“.
Aggressive Shift-Left-Programme geben Anlass zu einer berechtigten Sorge. Diese Sorge besteht darin, dass sie zu viel Verantwortung auf die Entwickler abwälzen, die eigentlich Funktionen schreiben und nicht einen Testbetrieb durchführen sollen.
Die Bedenken sind berechtigt. Entwicklerzeit ist teuer und knapp. Eine Shift-Left-Implementierung, die jeden Entwickler zu einem Teilzeit-QA-Analysten macht, verfehlt das Ziel genauso wie das Team, das Integrationstests einfach früher durchführt.
Die Lösung liegt in Automatisierung und Tool-Integration, nicht in manuellem Aufwand. Statische Codeanalysen sollten nach jedem Commit automatisch ausgeführt werden. Unit-Tests sollten im Hintergrund laufen. Ergebnisse sollten direkt in den Tools angezeigt werden, die Entwickler bereits verwenden – und zwar während der Codeentwicklung –, nicht erst später in einer separaten Review-Warteschlange.
Die Reibungsverluste sind entscheidend. Wenn die Verlagerung von Entwicklungsprozessen nach links den Workflow spürbar erschwert, ohne dass sich dies unmittelbar und klar im Entwicklererlebnis auszahlt, wird die Akzeptanz bestenfalls passiv ausfallen. Die Tools müssen sich ihren Platz im Workflow verdienen, d. h. schnelles Feedback, geringe Störanfälligkeit und Ergebnisse, die Entwickler direkt umsetzen können, ohne Experten im Analysetool selbst werden zu müssen.
Shift-Left-Testing wird manchmal als Migration dargestellt, als ob Teams den Übergang einmalig vollziehen und dann fertig wären. Das ist nicht ganz richtig. Es ist eine Vorgehensweise. Und Vorgehensweisen erfordern kontinuierliche Investitionen.
Die Testabdeckung muss mit dem Umfang der Codebasis wachsen. Codierungsstandards müssen im Zuge der Weiterentwicklung der Codebasis und der Entstehung neuer Standards angepasst werden. Virtuelle Service-Assets müssen bei Änderungen realer Abhängigkeiten gepflegt werden.
Und Teams brauchen Kennzahlen, die das messen, was wirklich zählt:
Die Anzahl der von Ihrem statischen Analysetool gefundenen Fehler zu messen, ist weniger sinnvoll als zu messen, wie viele Fehler tatsächlich in die Praxis gelangen.
Die Shift-Left-Testing-Lösungen von Parasoft bieten eine integrierte Plattform für Shift-Left-Testing über den gesamten Entwicklungslebenszyklus hinweg.
Die statische Analyse unterstützt C/C++, Java, .NET und weitere Sprachen mit standardmäßiger Unterstützung für gängige Sicherheitsstandards. Die automatisierte Unit-Test-Funktion generiert, führt aus und pflegt Unit-Tests in großem Umfang.
Die Servicevirtualisierung ermöglicht kontinuierliche Funktions- und Leistungstests ohne vollständige Verfügbarkeit der Umgebung.
Und KI-gestützte Analysen helfen Teams dabei, Ergebnisse in großem Umfang zu verwalten, ohne die Anzahl der Analysten erhöhen zu müssen.
Wenn Sie beurteilen, wo Ihre statischen Analyse- und SAST-Tools tatsächlich einen Mehrwert bieten, ist es ratsam, zusätzlich zu diesem Artikel den Begleitartikel zu lesen, der die Unterschiede zwischen sinnvoller SAST-Analyse und reiner Checklisten-Konformität erläutert. Ebenso wichtig ist dieser Kontext für die Entwicklung einer umfassenden Shift-Left-Strategie, wenn Ihre Teams mit der spezifischen Herausforderung der Abwägung zwischen IAST und SAST konfrontiert sind, insbesondere im Hinblick darauf, was IAST strukturell nicht abdecken kann.
Eine detaillierte Implementierungsanleitung nach SDLC-Phasen – einschließlich der Rollenverteilung zwischen Entwicklern und QA, nichtfunktionalem Testen und Servicevirtualisierung – finden Sie unter „ How to Shift Left Testing Across the SDLC“.
Shift-Left-Testing funktioniert. Die wirtschaftlichen Vorteile liegen auf der Hand, die Tools sind ausgereift, und Teams, die es erfolgreich anwenden, verzeichnen durchweg geringere Fehlerraten, kürzere Korrekturzyklen und niedrigere Gesamtkosten für die Qualitätssicherung.
Was nicht funktioniert, ist, das Problem als reines Terminplanungsproblem zu behandeln. Schlechte Testgewohnheiten durch das Vorverlagern in einen früheren Entwicklungszyklus werden dadurch nicht zu guten. Entscheidend ist der Wandel von der Fehlererkennung zur Fehlervermeidung, von reaktiven Qualitätskontrollpunkten hin zu einem proaktiven Qualitätsmanagement, das direkt in den Entwicklungsprozess integriert ist.
Weniger Fehler in der Produktion finden. Das ist das entscheidende Kriterium. Alles andere dient diesem Ziel.
Shift-Left-Testing bedeutet, Fehler frühzeitig im Softwareentwicklungszyklus zu finden und zu beheben, also möglichst nahe am Zeitpunkt der Codeerstellung, anstatt bis zum Integrationstest, der Qualitätssicherung oder der Produktion zu warten. „Left“ bezieht sich hier auf die linke Seite einer Zeitleiste, die die Entwicklungsphasen darstellt.
Shift Left konzentriert sich auf die frühzeitige Fehlererkennung während der Entwicklung. Shift Right hingegen fokussiert auf die Beobachtung und das Testen von Software in Produktionsumgebungen anhand realer Nutzerdaten. Beide Ansätze haben ihren Platz in einer ausgereiften Qualitätsstrategie und schließen sich nicht gegenseitig aus.
Nein. Die „Verschiebung nach links“ verändert die Aufgaben der Qualitätssicherung. Werden mehr Fehler während der Entwicklung entdeckt, kann sich die Qualitätssicherung auf die funktionale Verifizierung auf höherer Ebene, die Untersuchung von Grenzfällen und die Abnahmetests konzentrieren, anstatt Probleme zu beheben, die bereits früher hätten erkannt werden sollen. Die Rolle entwickelt sich weiter, sie verschwindet nicht.
Die wichtigsten Werkzeuge für Shift Left:
Die Integration von CI/CD ist für alle drei Bereiche unerlässlich, um den kontinuierlichen, reibungslosen Feedback-Kreislauf zu gewährleisten, der Shift-Left in der Praxis ermöglicht.
Die aussagekräftigste Kennzahl ist die Fehlerquote: Wie viele Fehler gelangen in die Produktion und wie viele werden während der Entwicklung entdeckt?
Zu den sekundären Kennzahlen gehören:
Wenn Ihr statisches Analysetool im Laufe der Zeit weniger Probleme findet, ist das ein Erfolgssignal und kein Problem, vorausgesetzt, die Fehlerrate sinkt ebenfalls.
Erfahren Sie, wie Sie das Testen im Softwareentwicklungszyklus (SDLC) nach links verlagern.
Weiterführende Inhalte
