Was ist Shift-Left-Testing?

Waren Sie schon einmal an einem Softwareprojekt beteiligt, bei dem das Budget und alle Fristen überschritten wurden? Das hast du, das haben wir alle. Wenn nicht, sind Sie ein „Einhorn“, und ich würde gerne von Ihnen hören.

In den frühen Phasen meiner Karriere als Softwareentwickler habe ich gelernt, wie wichtig es ist, von einer Deadline aus rückwärts zu arbeiten. Wenn ein Projekt eine bestimmte Deadline hat und die Tests eine bestimmte Zeit in Anspruch nehmen, dann können wir mit diesen Informationen rückwärts rechnen und einen Fälligkeitstermin für unser Projekt festlegen. Perfekt, oder?

Nun, nicht wirklich. Obwohl die rechtzeitige Fertigstellung für manuelle Tests den Stress in den letzten Tagen der Projekte etwas reduzierte, gab es immer noch zu viele Überraschungen.

Das Einplanen von Zeit für QA-Tests klingt in der Theorie gut, bricht aber in der Praxis schnell zusammen, wenn der erste Fehler oder Defekt identifiziert wird.

Wie lange dauert die Behebung dieses Fehlers? Wie stark wird es sich auf den Zeitplan auswirken? Werden neue Fehler eingeführt? Wie stellen wir sicher, dass jeder Fix so lange verifiziert wird, dass wir auch eventuelle Fehler beheben können, die wir beim Fix des ersten Fehlers verursacht haben?

Letztendlich war ich nie in der Lage, die richtige Zeit für die Qualitätssicherung aufzuwenden. Unweigerlich wurden überhastete Fixes in letzter Minute zusammengeführt. Ich habe gelernt, mir nach wichtigen Produkteinführungen ein paar Wochen lang Zeit in meinem Kalender freizuhalten. Dieser Ansatz erlaubt es mir, alle Probleme zu priorisieren, die wir in unserem hektischen Endspurt übersehen (oder verursacht) haben.

Das Problem war letztendlich nicht die für die Tests verfügbare Zeit, sondern das Timing der Tests. Ich musste früher und häufiger testen. Ich benötigte einen Shift-Left-Ansatz.

Wenn wir uns unseren Softwareentwicklungsprozess als eine Zeitachse vorstellen, die von links nach rechts verläuft, dann wird „Shift-Left-Testing“ (Testen durch Verschieben nach links) selbsterklärend. Einfach ausgedrückt, es ist die Praxis, frühere Phasen zu testen und Teammitglieder, einschließlich Tester, Entwickler und Stakeholder, in die Strategie einzubeziehen. Außerdem müssen Tests für bestehende und neue Funktionen häufiger in den Entwicklungszyklus integriert werden.

Das V-Modell ist eine nützliche Methode, um Softwareentwicklungszyklen zu konzipieren. Wenn wir den traditionellen Wasserfallfluss nehmen und die Y-Achse in der Umsetzungsphase „umdrehen“, erhalten wir das V-Modell.

Ein Entwicklungszyklus beginnt mit allgemeinen Anforderungen. Diese Anforderungen werden mit jedem Schritt nach unten im „V“ weiter eingegrenzt, bis wir die Implementierung auf Code-Ebene selbst erreichen. Anschließend überprüfen wir die Implementierung, beginnend mit den detailliertesten Komponententests und arbeiten uns dann entlang des „V“ zu den abstrakteren Benutzerakzeptanztests vor.

In einem Wasserfallprozess besteht das gesamte Projekt aus einem einzigen „V“. Als Branche haben wir gelernt, dass man sich im Grunde selbst zum Scheitern verurteilt, wenn man die gesamte Validierung bis zum Ende eines komplexen Projekts aufschiebt.

In einem iterativen Prozess können wir uns jeden Sprint oder jede Iteration als ein kleineres „V“ vorstellen. Wir haben theoretisch unsere Shift-Left-Ziele erreicht: früher und häufiger testen. Problem gelöst, oder? Nun, nicht wirklich.

Sie haben vielleicht bemerkt, dass der in das V-Modell integrierte Feedback-Kanal zwei Bezeichnungen hat: Verifizierung und Validierung. Beide Bezeichnungen sind wichtig.

Wir müssen validieren, ob unsere Benutzeranforderungen die Probleme lösen, die wir lösen wollten. Wir müssen auch sicherstellen, dass unsere Umsetzung den Spezifikationen entspricht, die wir aus diesen Benutzeranforderungen erhalten.

Automatisierte Tests können sowohl für Validierungen als auch für Verifizierungen eingesetzt werden. BDD (Behavior Driven Design) hat zur Entwicklung von Technologien wie Cucumber geführt, die einige Teile des Validierungsprozesses automatisieren können. In diesem Artikel konzentrieren wir uns auf automatisierte Tests zur Verifizierung.

Modultests überprüfen die Funktionalität eines bestimmten Moduls innerhalb einer größeren Anwendung. Das Modul wird isoliert getestet und jegliche Kommunikation mit anderen externen Prozessen wird simuliert oder nachgeahmt. Unit-Tests und TDD stellen die erste Entwicklungsphase im Shift-Left-Testing dar.

Integrationstests dienen dazu, die Gesamtfunktionalität eines Dienstes oder einer Anwendung zu überprüfen, einschließlich der Nebeneffekte. Dieser Prozess ist aus Gründen, die wir später besprechen werden, ein Anti-Muster.

API-Tests überprüfen die externen Endgeräte eines einzelnen Services. Der Umfang von API-Tests ähnelt dem von Integrationstests. In einem SOA- oder Microservices-Kontext können wir uns API-Tests jedoch als die neuen Unit-Tests vorstellen.

UI-Tests überprüfen die vollständige Funktionalität einer Anwendung von der Benutzeroberflächenebene aus. Tools wie Selenium machen automatisierte UI-Tests allgemein zugänglich.

Bei Shift-Left geht es nicht nur um Automatisierung. Eine weitere Möglichkeit, früher und häufiger zu testen, besteht darin, sicherzustellen, dass Ihre Qualitätssicherungsspezialisten in jeden Schritt Ihres Prozesses eingebunden sind, beginnend mit der Ermittlung und Erfassung der Anforderungen. Testingenieure können bessere Arbeit leisten, wenn sie ein besseres Verständnis für die Gesamtimplementierung haben, und ihre Erkenntnisse können dazu beitragen, die Architektur offener und widerstandsfähiger zu machen.

Wenn wir an „früher und häufiger“ testen denken, fällt uns ein bestimmtes Wort ein: kontinuierlich. Viele (die meisten) Softwareentwicklungsteams praktizieren eine Form der kontinuierlichen Integration und kontinuierlichen Bereitstellung. Kontinuierliches Testen ist eine wichtige Feedback-Schleife in diesem DevOps-Zyklus.

Wenn wir TDD als „Shift-Left für Monolithen“ betrachten, dann ist kontinuierliches Testen „Shift-Left für verteilte Architekturen“.

TDD hat uns geholfen, uns auf Unit-Tests zu konzentrieren. Bei kontinuierlichen Tests sollten wir uns auf API- und Vertragstests konzentrieren. API-Tests bieten einige Vorteile:

• API-Tests können eine der häufigsten Ursachen für Fehler in einer Microservice-Anwendung verhindern: die Änderung einer Abhängigkeit, die nicht mit den vor- oder nachgelagerten Diensten synchronisiert ist.
   

• API-Tests können von demselben Team ausgeführt werden, von dem auch der Service ausgeführt wird.
   

• API-Tests vermeiden die Brisanz der Prüfung von Nebenwirkungen und Implementierungsdetails.

Idealerweise werden diese API-Tests kontinuierlich sowohl in Produktions- als auch in Vorproduktionsumgebungen durchgeführt. Tools zur Vertragsprüfung können dabei helfen, diesen Prozess zu automatisieren, aber dafür ist mehr Infrastruktur erforderlich.

Was wäre, wenn wir kontinuierliche API-Tests verwenden könnten, die in unser Observability-Tool integriert sind? Die kommende Funktion für synthetische API-Tests von Instana ermöglicht es Ihnen, kontinuierlich und mit minimalem Aufwand API-Tests für alle Ihre Umgebungen durchzuführen.

Shift-Left bedeutet, dass die Testaktivitäten näher an den Anfang des Softwareentwicklungszyklus verschoben werden, wodurch schnelleres Feedback ermöglicht und der Zeit- und Arbeitsaufwand für die Fehlerbehebung reduziert wird. Hier sind einige Best Practices für das Shift-Left-Testing in der agilen Entwicklung:

1. Frühe Einbindung: Testaktivitäten sollten so früh wie möglich im Entwicklungsprozess beginnen. Tester sollten bereits in der Phase der Anforderungserhebung einbezogen werden, um den Projektumfang, die Ziele und die Erwartungen der Benutzer zu verstehen.
    

2. Zusammenarbeit und Kommunikation: Fördern Sie eine enge Zusammenarbeit und Kommunikation zwischen Entwicklern, Testern und anderen Stakeholdern. Fördern Sie tägliche Stand-up-Meetings, Sprint-Planungssitzungen und regelmäßige Retrospektiven, um ein gemeinsames Verständnis und eine gemeinsame Ausrichtung sicherzustellen.
    

3. Testautomatisierung: Investieren Sie in Testautomatisierung, um häufige und effiziente Tests zu ermöglichen. Automatisierte Tests sollten parallel zum Entwicklungsprozess erstellt und in die kontinuierlichen Integrations- und Bereitstellungs-Pipelines integriert werden. Dies unterstützt die frühzeitige Erkennung von Fehlern, reduziert Regressionsprobleme und beschleunigt Feedback-Zyklen.
    

4. Testgetriebene Entwicklung (TDD): Fördern Sie die Praxis von TDD, bei der Entwickler Testfälle schreiben, bevor sie den eigentlichen Code schreiben. Dieser Shift-Left-Testansatz hilft dabei, das gewünschte Verhalten und die erwarteten Ergebnisse im Voraus zu definieren, was zu einem robusteren und besser testbaren Code führt.
    

5. Kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD): Implementieren Sie CI/CD-Pipelines, um die Prozesse für Erstellung, Test und Bereitstellung zu automatisieren. Durch diese Vorgehensweise wird sichergestellt, dass jede Codeänderung gründlich getestet und schnell und häufig in Produktionsumgebungen eingesetzt wird, wodurch das Risiko von Integrationsproblemen verringert wird.
    

6. Shift-Left-Sicherheitstests: Erwägen Sie, Sicherheitstestverfahren frühzeitig in den Entwicklungsprozess zu integrieren. Führen Sie Sicherheitscode-Überprüfungen, statische Code-Analysen und sicherheitsorientierte Tests durch, um Schwachstellen zu identifizieren und diese proaktiv zu beheben.
    

7. Explorative Tests: Fördern Sie neben automatisierten Tests auch explorative Tests, um die Anwendung aus der Perspektive der Benutzer zu untersuchen. Erfahrene Tester können potenzielle Probleme bei der Benutzerfreundlichkeit, Grenzfälle und Szenarien identifizieren, die bei automatisierten Tests möglicherweise übersehen werden.
    

8. Leistungstests: Führen Sie frühzeitig Leistungstests durch, um potenzielle Engpässe und Probleme bei der Skalierbarkeit zu erkennen. Dies trägt dazu bei, die Leistung der Anwendung zu optimieren und sicherzustellen, dass sie die erforderlichen Leistungskriterien erfüllt.
    

9. Testumgebungen und Daten: Stellen Sie Testumgebungen bereit, die den Produktionsumgebungen sehr ähnlich sind, um realistische Softwaretests zu gewährleisten. Stellen Sie außerdem sicher, dass ausreichend und repräsentative Testdaten zur Verfügung stehen, um reale Szenarien zu simulieren.
    

10. Kontinuierliches Lernen und kontinuierliche Verbesserung: Fördern Sie eine Kultur des kontinuierlichen Lernens und der kontinuierlichen Verbesserung. Fördern Sie regelmäßige Retrospektiven, um über Testprozesse nachzudenken, Engpässe zu identifizieren und Änderungen umzusetzen, um die Effektivität des Shift-Left-Testing zu verbessern.

Durch die Umsetzung dieser Best Practices können agile Teams eine bessere Zusammenarbeit, schnelleres Feedback und hochwertigere Softwareprodukte durch Shift-Left-Tests erreichen.

Die kürzeren Feedback-Schleifen, die in die Shift-Left-Prozesse integriert sind, unterstützen uns in mehrfacher Hinsicht. Mängel können schneller gefunden werden, Korrekturen können effizienter vorgenommen werden und die in einem Durchlauf gewonnenen Erkenntnisse können im nächsten Durchlauf angewendet werden, um nur einige zu nennen.

Unabhängig von der Projektmanagement-Methode oder dem Veröffentlichungsrhythmus Ihres Teams können Sie von den kürzeren Feedbackschleifen für die Verifizierung durch Shift-Left-Tests profitieren.

Die Identifizierung und Behebung eines Fehlers, der bei einem automatisierten Komponententest auf dem lokalen Computer eines Entwicklers festgestellt wird, kostet weniger. Ein Fehler, der durch einen automatisierten Komponententest auf dem lokalen Rechner eines Entwicklers gefunden wird, ist kostengünstiger zu identifizieren und zu beheben.

Wenn sie richtig durchgeführt werden, können automatisierte Tests und CI das Vertrauen schaffen, das Software-Ingenieure benötigen, um Software häufig bereitzustellen – sogar freitags. Je schneller Mängel erkannt werden, desto weniger panische „Alle Hände an Deck“-Momente entstehen. Da die Releases so reibungslos verlaufen, lassen sich die wenigen Fehler, die dennoch auftreten, schneller und einfacher beheben.

Da mehr zugängliche Software für uns alle leichter zu bedienen ist, kann besser testbare Software leichter zu verstehen und zu pflegen sein. Wenn Sie frühzeitig über Tests nachdenken, kann dies zu einer besseren Trennung der Anliegen und einer widerstandsfähigeren Gesamtarchitektur führen.

Die Verbesserung der Customer Experience ist unser Ziel. Durch den Shift-Left-Ansatz können einige Vorfälle, die bei Benutzern auftreten können, vermieden und die Auswirkungen anderer Vorfälle reduziert werden. Wir können Observability nutzen, um diese Feedbackschleife zu vervollständigen und den Gesamtzustand unserer Software zu verbessern.

Da uns leistungsstarke Automatisierungstools zur Verfügung stehen, kann es verlockend sein, jede Art von Test auf jede Codezeile anzuwenden. Dieser Ansatz ist ein gefährlicher Weg.

Das Testen von Nebeneffekten – wurde dieser Datensatz in der Datenbank gespeichert? – ist eine attraktive Idee. Das Testen von Implementierungsdetails ist jedoch ein Anti-Pattern, da diese Art von Tests fehleranfällig ist. Möglicherweise müssen diese jedes Mal geändert werden, wenn Ihre Anwendung geändert wird. Die Benutzeroberfläche ist ebenfalls ein Implementierungsdetail, sodass UI-Tests unter die gleiche Kategorie fallen.

Bei Verifizierungstests geht es nur um das „Was“, nicht um das „Wie“ oder das „Warum“. Im Idealfall wurden die Benutzeranforderungen so konzipiert, dass das „Warum“ validiert wird. Um die Frage nach dem „Wie“ zu beantworten, können wir auf eine leistungsfähigere Automatisierung in Form einer Observability-Plattform zurückgreifen.

Beim Shift-Right-Testing werden die Tests zu einem späteren Zeitpunkt im Entwicklungsprozess durchgeführt, in der Regel in der Produktionsumgebung. Auch wenn es seltsam erscheinen mag, ergänzen sich Shift-Left- und Shift-Right-Tests gegenseitig.

Durch Shift-Right-Tests können wir Produktionsprobleme erkennen, bevor unsere Kunden dies tun. Die kürzeren Feedbackschleifen von Shift-Left-Tests ermöglichen es uns, schnell auf diese Produktionsprobleme zu reagieren und sie zu beheben.

Synthetische API-Tests als Teil Ihrer Observability-Plattform sind die perfekte Möglichkeit, die Vorteile von Shift-Left- und Shift-Right-Praktiken zu kombinieren.