Shift-Left – (nie mehr) schlaflos in DevOps

3 Uhr nachts. Ein fieser Piepton reißt Sie aus dem Schlaf. Ihr Handy klingelt. Und nein, es ist nicht privat, es ist der Job. Sie arbeiten in einem Online-Entwicklungsteam und machen jetzt DevOps. Das heißt, Sie haben neben der Entwicklung auch die Verantwortung für den Betrieb übernommen. Das wiederum bedeutet, dass Sie nun auch für die Entstörung von nächtlichen Supportfällen zuständig sind.

Und so starren Sie nun auf Ihr Handy mit einer kryptischen Fehlermeldung, die das Monitoring automatisch gesendet hat. Sie verstehen auf den ersten Blick nur so viel, dass es wohl dringend ist. Irgendjemand am anderen Ende der Welt kann einen Ihrer Services nicht nutzen. Eilig begeben Sie sich an den PC und wühlen sich durch Logfiles. Immer auf der Suche nach dem Auslöser bzw. der Fehlerursache. Parallel rattert es in Ihrem Kopf: Vielleicht war es doch keine gute Idee, dass wir am Freitagnachmittag noch das neue Feature released haben? Die Zeit saß uns aber im Nacken! Oder liegt der Fehler in der Änderung der API von letzter Woche? Das muss doch aber jemand getestet haben!?

Die ganzheitliche Verantwortung für Entwicklung und Betrieb

Eines möchte ich vorwegschicken: DevOps ist großartig.¹ Ein Team übernimmt gesamtheitliche Verantwortung für Entwicklung und Betrieb ihres Produkts. Mit den entsprechenden Praktiken und Prinzipien wird schneller, sicherer und stabiler Software entwickelt. Mit den damit einhergehenden Veränderungen in Denkweise, Verhalten und Kultur werden auch noch historisch gewachsene Organisationsstrukturen und -hürden überwunden.

Abbildung 1: Der DevOps Lifecycle

• Weniger Abhängigkeiten,
• höhere Geschwindigkeit und
• dabei trotzdem höhere Stabilität

sind nicht nur Schlagworte im DevOps-Kontext, sondern gleichzeitig auch die Dinge, die für einen geruhsameren Schlaf sorgen.

Shift-Left – Die Verlagerung der Testaufwände

Höhere Geschwindigkeit verspricht auch die Continuous Integration (CI)² – ein Prozess der kontinuierlichen Zusammenführung von Komponenten zu einer Anwendung und ein wichtiger Bestandteil der DevOps-Vorgehensweise. Eine gute CI erreicht man u. a. durch automatisierte Tests. Sprechen wir von einer guter Testautomatisierung, dann meinen wir nicht stumpf eine möglichst hohe Zahl von Testfällen, sondern eher möglichst qualitativ hochwertige Testfälle. Qualitativ hochwertig bedeutet nicht, dass sich die überwiegenden Testaktivitäten nach Implementierung in der Phase Test abspielen, sondern das Gros viel weiter vorne und dann verteilt auf die anderen Phasen stattfindet. Dieses Verlagern der Testaufwände in frühere Phasen des DevOps-Zyklus bezeichnet man auch als den sog. “Shift-Left”. 

Abbildung 2: Shift-Left – Verlagerung der Aktivitäten nach links

Die Kombination von DevOps mit Shift-Left

Aus Perspektive der Qualitätssicherung (QS) möchte ich sogar die These aufstellen, dass es nur die Kombination aus den DevOps-Prinzipien und einem gleichzeitigen Shift-Left ist, die uns erholsam schlafen lässt. Um das zu verstehen, muss aber erstmal der Shift-Left-Ansatz erklärt werden. Dazu klappen wir die “DevOps-Acht” auf und erhalten somit eine Strecke.

Abbildung 3: Shift-Left-Left im aufgespannten DevOps Lifecycle

Einerseits geht es um das Verlagern von QS-Aktivitäten und -Aufwänden im Zyklus nach links, also zeitlich früher. Testen ist nunmehr nicht mehr eine Phase nach dem Build und vor dem Release, sondern muss in allen Zyklus-Phasen stattfinden.

Neben der zeitlichen gibt es aber auch noch eine “örtliche” Bedeutung. Man könnte fast von einem Shift-Down sprechen. Rufen wir uns dazu mal die vielzitierte Testpyramide ins Gedächtnis. Und zwar die Ur-Pyramide von Mike Cohn³ in der Ausführung mit den Stufen Unit, Service und UI.

Abbildung 4: Ausführungsform vs. Integration

Cohn und auch Martin Fowler⁴ illustrieren damit die idealtypische Verteilung von Testaufwänden. Fowler selbst aber spricht auch davon, dass die Pyramide in der Realität gern einer Eistüte gleicht, weil Testaktivitäten meist spät und über die Oberfläche der Anwendung stattfinden.

Lösen wir uns für einen Moment von der Definition der Pyramide, die mit den Stufen auch die Ausführungsart der Testautomatisierung abbilden möchte, und weisen den Stufen nun die Bedeutung des Isolationsgrads des Testobjekts zu.

Je weiter unten, umso kleinere Testobjekte werden isoliert betrachtet. Wie beim Thema Testautomatisierung bereits angerissen, bedeutet der Shift-Left eben auch eine Verschiebung der Tests auf der Pyramide von oben nach unten. Weg von komplexen, langlaufenden und wartungsintensiven Tests über das UI, hin zu den früheren, weil lokaleren Tests von isolierten Testobjekten mit schnellen Durchlaufzeiten.

Früheres Testen heißt, wir finden Fehler häufiger und schneller. Kleinere und unabhängigere Testobjekte heißt außerdem, dass wir Fehler auch noch deutlich schneller beheben können. Durch die wenigen oder nicht vorhandenen Abhängigkeiten der Testobjekte lässt sich auch die Wartung der Testfälle aufwandsärmer durchzuführen. Diese Effekte ergeben zusammen eine deutliche Kostenreduktion oder um Kent Beck zu zitieren: “Most defects end up costing more than it would have cost to prevent them”.⁵

Die Isolierung bei Shift-Left

Die Isolierung möchte ich noch etwas ausführlicher erläutern. Shift-Left ist eben nicht nur eine große Menge an isolierten Unit-Tests, sondern es geht auch um das autonome Testen von (Micro-)Services und Schnittstellen mittels Techniken wie Mocking, Service-Virtualisierung⁶ und Contract-Testing⁷.

Kann man auf diesen Stufen eine hohe Testabdeckung realisieren, entfällt automatisch die Notwendigkeit, die mit diesen Testfällen überprüften Anforderungen auf höheren Stufen zu testen oder auch implizit, wie zum Beispiel in aufwändigen End2End-Tests, zu wiederholen. Damit bekommen wir einen weiteren großen Vorteil praktisch geschenkt: schnelles Feedback.

Wenn wir auch kleinere Änderungen immer wieder schnell testen sollen, dann ist ein manueller Testansatz wenig sinnvoll. Durch das frühe entwicklungsbegleitende, häufige und automatisierte Testen können wir zu nahezu jedem Zeitpunkt Feedback zu Zustand und Fortschritt unseres Entwicklungsartefakts bekommen. Und dieses Feedback ist aufgrund der reduzierten Komplexität durch die fehlenden Abhängigkeiten auch meist kostengünstiger.

Fazit

Aus dem Blickwinkel der Qualitätssicherung und des Testens bedeutet Shift-Left: Fast Feedback durch test early und test often.

Eine Ergänzung möchte ich an dieser Stelle noch erwähnen: Sie haben eben gesehen, dass Sie die starre Verankerung der Phase Test nach der Codierung auflösen und ihre Inhalte und Aktivitäten nach links bis zur Phase Plan sinnvoll verteilen können. Das linke Ende des Shift-Left beginnt also ab Ende der Plan-Phase. Erweitern Sie den Scope nun um eben diese Phase und machen sozusagen einen weiteren Schritt nach links, sprechen wir vom sogenannten Shift-Left-Left (vgl. Abbildung 3).

Auch die Phase der Anforderungsdefinition kann durch die zusätzliche QS-Perspektive profitieren.

• Wie können die Akzeptanzkriterien einer User Story überhaupt getestet werden?
• Können neben den funktionalen Anforderungen auch testbare Qualitätsanforderungen abgeleitet werden?
• Wie passt das geplante Vorgehen zu Testarchitektur und Teststrategie?

Dies sind nur einige wenige Fragen, deren möglichst frühzeitige Beantwortung im späteren Entwicklungsverlauf hilfreich sind.

Zusätzlich stärkt die Kollaboration der verschiedenen Disziplinen (hier im Regelfall: Requirements-, Test- und Software Engineering) den whole-team-quality-Gedanken und verringert die Reibung, die bei den Übergaben zwischen den Gewerken entstehen kann. Verbreitete Vorgehensweisen, wie Behaviour Driven Development (BDD)⁸ und Aktivitäten wie dem 3-Amigo-Gespräch sind hier sicherlich zu erwähnen. Dies alles bietet allerdings genügend Stoff für einen separaten Blogbeitrag.

Zurück zu meiner These: Wie lässt Sie nun der Shift-Left durchschlafen? Vereinfacht ausgedrückt: durch das kleinteiligere und gleichzeitig umfassendere Testen können Sie ein stärkeres Vertrauen in die Stabilität Ihrer Anwendung und deren Funktionalität aufbauen. Sie reduzieren damit die blinden Flecken vor dem Release und minimieren den “release pain” im Sinne des Auslieferungsrisikos. Kommt es, wie im Eingangsszenario beschrieben, trotzdem zu einer Fehlersituation in der Produktion, können Sie diese schneller analysieren, da Sie die Ursachen schneller lokalisieren können. Schlussendlich können Sie früher mit der Fehlerbehebung und der Wiederherstellung des Systems bzw. der Funktionalität beginnen. Zusätzlich beeinflussen Sie auch eine der DevOps-Schlüsselmetriken⁹ für die Performance der Softwarebereitstellung, die “mean time to recover” (MTTR)¹⁰, nachhaltig positiv.

In diesem Sinne: Schlafen Sie gut! 😴

Hinweise:

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!

[1] Was ist DevOps?
[2] Continuous Integration: Improving Software Quality and Reducing Risk (Duvall, Matyas & Glover)
[3] The Forgotten Layer of the Test Automation Pyramid
[4] TestPyramid
[5] Extreme Programming Explained: Embrace Change
[6] Mocks Aren’t Stubs
[7] ContractTest
[8] Introducing Behaviour-Driven Development
[9] Accelerate: The Science Behind Devops: Building and Scaling (Forsgren, Humble, Kim)
[10] What Is Mean Time to Repair? MTTR Explained

Veit Joseph hat einen weiteren Beitrag im t2informatik Blog veröffentlicht:

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.