Shift Left Testing

Vorteile, Umsetzung und Unterschiede zum traditionellen Wasserfall-Testansatz

Definition Shift Left Testing

Beim Shift Left Testing werden Testprozesse an einen früheren Zeitpunkt des Entwicklungsprozesses gelegt. Shift Left bedeutet in diesem Fall, dass der Tester seine Aktivität innerhalb eines Projektes – dargestellt an einem Zeitstrahl – weiter nach links verlagert. Damit kann das Testen effizienter durchgeführt und die Entwicklung erleichtert werden.

Shift Left Testing, Qualitätssicher prüft Code

Traditioneller Testansatz

Ein Ziel der agilen Softwareentwicklung ist es, den Entwicklungszyklus zu verkürzen und somit dem Endnutzer iterativ Features in kürzeren Zeitabständen zur Verfügung zu stellen. Das hat viele Vorteile für Unternehmen – beispielsweise kann schneller auf Markttrends oder Nutzerbedürfnisse reagiert werden.

Die größten Herausforderungen bei der Umsetzung sind neben der Anpassung der Entwicklungs- und Projektmanagementprozesse auch die Adaption der Testprozesse. Denn auch bei kürzeren Releasezyklen muss weiterhin eine gute Qualität des Produkts gewährleistet sein – gerade hinsichtlich der Regressionstests kann das zeitlich zu einer Herausforderung werden.

Bevor agile Entwicklungsmethoden und damit auch das Shift Left Testing Einzug in Softwareprojekte nahmen, war das Wasserfallmodell vorherrschend – und auch heute arbeiten viele Teams noch in wasserfallartigen Projektsetups.

Tester nehmen dort meist eine eher passive Rolle ein und kommen erst gegen Ende des Entwicklungszyklus ins Spiel. In einem solchen Testprozess kann es zu mehreren Problemen kommen. Viele Tester haben sicherlich bereits in einem folgenden Setup gearbeitet und finden sich in den folgenden Punkten wieder:

  • Entwickler und Tester arbeiten in unterschiedlichen Teams
  • Entwickler und Tester analysieren unabhängig voneinander Anforderungen auf dessen Basis die Programmierung oder die Testfälle aufgebaut sind
  • Testfall-Reviews finden nur innerhalb des QS-Teams statt
  • Das Testen von Features kommt zuletzt im Entwicklungszyklus und Tester werden angehalten, die Tests innerhalb eines kurzen Zeitraums unmittelbar vor dem Release der Software durchzuführen
  • Das Hauptaugenmerk richtet der Tester darauf, Testfälle abzuarbeiten und Fehler in der Software zu finden
  • Testautomatisierung findet zu geringem Teil oder gar nicht statt – Regressionstests werden manuell ausgeführt
Wasserfall-Ansatz Testing

Höhere Kosten der Fehlerbehebung

Dadurch, dass der Fokus meist erst nach der Entwicklungsphase auf die Qualität gelegt wird und Tests aufgrund fehlender Testautomatisierung nicht kontinuierlich ausgeführt werden, können Fehler oft erst spät entdeckt werden. Das hat zur Folge, dass die Fehlerbehebung aufwändiger und damit gleichzeitig auch teurer wird. Eine Studie von IBM brachte hervor, dass die Kosten eines in der Entwicklungsphase gefundenen Fehlers etwa sechsmal so hoch sind wie in der Konzeptionsphase und in der der Testphase sogar 15-mal so hoch.

Diagramm Relative Kosten einer Fehlerbehebung

Wenn Fehler bereits in der Design- oder Konzeptionsphase gefunden werden, entsteht weitestgehend nur der Aufwand, der gebraucht wird, um die Anforderung umzuschreiben oder das Design anzupassen. Wenn ein Fehler allerdings erst in der Testausführung entdeckt wird, summieren sich die Aufwände eines Testers wie die Dokumentation des Fehlers, das Abstimmung mit den Entwicklern und das erneute Testen nach der Fehlerbehebung. Auch die Aufwände des Entwicklers nehmen zu – dieser muss sich wiederum mit dem Tester abstimmen und den Fehler beheben.

Engpässe im Testen

Die Hauptaufgaben des Testers liegen in diesem Testprozess in der Testfallausführung, die erst nach der Implementierung stattfinden kann. Bei Verzögerungen im Entwicklungsprozess – zum Beispiel, weil Fehler erst in der Entwicklung auftauchen und nicht in der Konzeptphase – und Release-Deadlines, die dennoch gehalten werden müssen, kann es häufig dazu kommen, dass die Zeit für die Tests knapp wird. Gerade manuell ausgeführte Regressionstests sind sehr ressourcenintensiv, wodurch in der Testausführung häufig Engpässe entstehen.

Geringere Testabdeckung

Aufgrund der Engpässe im Testen und auch weil Tester eine endliche Ressource sind, muss man sich im Laufe der Produktentwicklung das Testset verkleinern und Testfälle mit geringerer Priorität oder Risiko entfernen. Dadurch kann es passieren, dass beispielsweise weniger hoch priorisierte Features oder Teile von Features ungetestet bleiben. Mit dem Einzug von agilen Entwicklungsmethoden und schnelleren Releasezyklen hat sich also die Rolle des Testers vom „Fehlerfinder“ zum „Fehlervorbeuger“ verändert und genau dieser Aspekt findet sich auch im Shift Left Testing wieder.

Shift Left Testing vs. Wasserfall-Testansatz

Traditioneller Ansatz vs. Shift Left Testing

Der Qualitätsfokus des Teams und die Hauptaktivitäten eines Testers liegen hier nicht mehr hinter der Entwicklungsphase, sondern am Anfang des Releasezyklus – dort, wo Anforderungen analysiert und das Konzept sowie Design erstellt werden. Damit wird Fehlern vorgebeugt, anstatt sie kostenintensiver innerhalb der Entwicklungs- oder Testphase zu finden. Außerdem werden Tester früher in den Gesamtprozess miteinbezogen, können ihre Erfahrungen und tiefgreifendes Wissen über das Produkt einfließen lassen und wissen gleichzeitig aber auch viel früher über die Details der Anforderungen Bescheid. Dadurch können Testfälle dann auch vorab präziser erstellt werden. Der Fokus eines Testers verschiebt sich also vom Testen der entwickelten Software vielmehr in die Richtung Konzept- beziehungsweise Design-Testing.

Die Entwicklungsphase können Tester dann nutzen, um automatisierte Testfälle zu erstellen, die kontinuierlich über den gesamten Releasezyklus ausgeführt werden. Damit lassen sich wiederum zum Beispiel Regressionsfehler ebenfalls zu einem früheren Zeitpunkt finden. Die Hauptaktivitäten eines Testers sollten dadurch weitestgehend mit dem Ende der Entwicklungsphase abgeschlossen sein. Nach Fertigstellung der Implementierung helfen die automatisierten Tests dem QS-Team, eine schnelle Rückmeldung über Fehler an die Entwicklung zu geben. Im Anschluss können sich die Tester dann auf die Aufgaben konzentrieren, die nicht durch automatisierte Tests abgedeckt werden können. Hierzu zählen beispielsweise exploratives Testen, erfahrungsbasiertes Testen oder Usability Tests.

Wie schafft man nun aber die ersten Schritte der Transformation eines Wasserfall-Testansatzes hin zum agilen Shift Left Testing? Wichtig im agilen Umfeld ist grundsätzlich auch, dass die Softwarequalität nicht ausschließlich in der Verantwortung des QS-Teams liegt. Alle Teammitglieder sind gleichermaßen daran beteiligt, qualitativ hochwertige Software zu liefern und Fehlern vorzubeugen. Eine Methode, die dabei hilft, ist „Behaviour Driven Development“. Gleichzeitig spielt aber auch Testautomatisierung eine große Rolle, um kontinuierlich durch den gesamten Releaseprozess hinweg zu testen.

Was ist Behaviour Driven Development?

Behaviour Driven Development ist eine Methode in der agilen Softwareentwicklung und fördert die Zusammenarbeit aller Rollen, die an der Software beteiligt sind. Außerdem wird das gemeinsame Verständnis darüber, wie sich ein Feature verhalten soll, geschaffen, indem vor Entwicklungsstart gemeinsam im Team konkrete Beispiele für jeden Anwendungsfall erörtert werden.

Der Gesamtprozess teilt sich in drei Phasen auf, die im Folgenden näher beschrieben werden.

Behaviour Driven Development, Shift Left Testing

Phase 1: Discovery

Bei der ersten Phase handelt es sich um die Erarbeitung konkreter Beispiele mit den für eine User Story relevanten Rollen – mindestens aber den drei Amigos: Entwickler, Tester und Product Owner. Um hier eine strukturierte Konversation zu ermöglichen, eignen sich sogenannte „Discovery Workshops“, die sich auf Praxisbeispiele aus Endnutzer-Perspektive fokussieren.

Phase 2: Formulation

Die zweite Phase beinhaltet die Dokumentation der in der Discovery-Phase erarbeiteten Beispiele in einer menschen- aber auch maschinenlesbaren Sprache. Das hat den Vorteil, dass man die daraus entstehenden Szenarien in der nächsten Phase zur Automatisierung nutzen kann. Dazu nutzt man die Gherkin-Syntax, die von speziellen Tools (zum Beispiel Cucumber, SpecFlow oder Behave) ausgeführt werden kann.

Gherkin-Szenarien sollten von allen, auch weniger technisch affinen, Teammitgliedern verstanden werden können. Hier ein klassisches Beispiel:

Shift Left Testing: Gherkin Szenario, Code

Die speziellen Schlüsselwörter werden dazu genutzt, um das Szenario zu strukturieren.

  • Given beschreibt die Vorbedingung für den Test
  • When beschreibt die Aktion, die ausgeführt werden soll
  • Then validiert, dass die ausgeführte Aktion das gewünschte Ergebnis hervorruft

Phase 3: Automation

In der dritten Phase geht es um die Implementierung der automatisierten Tests auf Basis der Testszenarien aus der Formulation-Phase. Hier wird der eigentliche Code zur Ausführung der Tests in Browsern oder Apps für die einzelnen Schritte (Given, When, Then) der Gherkin-Szenarien implementiert.

Behaviour Driven Development hilft uns also unter anderem dabei, frühzeitig innerhalb des Teams Konversationen über das Verhalten einer Funktionalität zu führen, was gleichzeitig dazu beiträgt, dass man das Testdesign bereits vor dem Entwicklungsstart abgeschlossen hat und das gesamte Team miteinbezogen wird. Dadurch entstehen die folgenden Vorteile:

  • Konzept-/Designfehler werden früher erkannt und können bereinigt werden
  • Einheitliches Verständnis darüber, was implementiert und getestet werden soll
  • Identifizierung und Vorbereitung der zu automatisierenden Testfälle
  • „Living Documentation“ über die Funktionalitäten in der Applikation

Testautomatisierung

Testautomatisierung ist ein elementarer Bestandteil des BDD-Prozesses und unterstützt den Testprozess dahingehend, dass die Engpässe im Testing minimiert werden, eine hohe Testabdeckung erreicht wird und durch kontinuierliches Testen Regressionsfehler frühzeitig im Releasezyklus entdeckt werden können.

Die Strategie zur Testautomatisierung beziehungsweise die zu verwendenden Methoden und Werkzeuge hängen stark von der Applikation ab, die entwickelt wird. Sofern eine Backend-Architektur implementiert wird, eigenen sich automatisierte API-Tests. Entwickelt man ein Frontend, sollte man automatisierte funktionale UI-Tests und visuelles Regressionstesting in Betracht ziehen. Grundsätzlich sollte man sich aber an der Testpyramide orientieren:

Testautomatisierung

Unit Tests stellen die Basis dar und sollten den größten Anteil in der Testsuite haben. Unit Tests decken in der Regel nur eine einzige Methode ab und werden direkt auf der Code-Ebene ausgeführt.

Langsamer in der Ausführung sind die Integrationstests, die sich auf der mittleren Ebene der automatisierten Tests befinden. Diese Tests decken die Integration verschiedener Software-Teile (z. B. Datenbanken, Frameworks oder Drittsysteme) ab. Das können zum Beispiel API-Tests sein, die das Backend inklusive der angebundenen Datenbanken, Frameworks oder Drittsysteme testen.

Die dritte Ebene wird durch User Interface Tests abgebildet. Diese Tests decken (End-to-End) den gesamten Fluss durch das System ab. Sie beschäftigen sich mit den Tests aus Endnutzerperspektive und emulieren das Userverhalten auf der Webseite oder innerhalb der App. Im Gegensatz zu den Unit Tests sind diese Tests reine Black-Box-Tests und insgesamt wesentlich langsamer in der Ausführungszeit – daher sollte hier auch weise entschieden werden, welche UI Tests automatisiert werden und welche bereits durch Unit oder Integrationstests abgedeckt sind.

An der Spitze der Pyramide stehen die manuellen Tests. Warum werden manuelle Tests weiterhin benötigt, obwohl wir bereits eine stabile Testabdeckung über die automatisierten Tests erreicht haben?

Manuelles, sitzungsbasiertes Testen wird zum Beispiel aus den folgenden Gründen weiterhin notwendig sein:

  • „Menschliche Tester“ können schnell identifizieren, wenn etwas nicht korrekt funktioniert oder aussieht – automatisierte Tests führen nur exakt das aus, wozu sie programmiert sind
  • Automatisierte Tests sind auch Code und auch hier verstecken sich, trotz aller Sorgfalt, Fehler. Mit manuellem Testen kann man hier nochmal ein zusätzliches Sicherheitsnetz schaffen.
  • Manche Szenarien sind technisch nicht umsetzbar oder die Automatisierung zu aufwändig

Der Anspruch sollte also sein, repetitive Aufgaben zu automatisieren, sodass sich die Tester auf relevante Testmethoden konzentrieren können, um die Qualität zu erhöhen. Exploratives oder erfahrungsbasiertes Testen hinsichtlich der Usability einer Applikation – eben das, was eine Maschine nicht erledigen kann.

Automatisiertes Testen hilft uns grundlegend bei den folgenden Punkten:

  • Schnellere Markteinführung: Tests werden kontinuierlich über den gesamten Releasezyklus hinweg ausgeführt, womit speziell Regressionsfehler früher gefunden werden können. Ein ressourcenintensiver manueller Regressionstest gegen Ende des Zyklus wird minimiert und manuelles Testing findet nur noch im Rahmen von sessionbasierten explorativen Test Sessions oder Sanity Testing statt.
  • Kürzerer Feedbackzyklus: Automatisierte Tests sind schneller und können zum Beispiel auch über Nacht ausgeführt werden – damit wird der Feedbackzyklus massiv verkürzt.
  • Höhere Testabdeckung: Wenn kontinuierlich neue Funktionalitäten zur Applikation hinzugefügt werden, wird man bei rein manuellen Tests aufgrund der höheren Aufwände langfristig eine Entscheidung über die Reduzierung des Test-Sets in Betracht ziehen müssen und weniger hoch priorisierte oder Tests mit geringerem Risiko entfernen. Automatisierte Tests lassen sich wesentlich einfacher skalieren und bieten dadurch eine höhere Testabdeckung.
  • Kosteneinsparung: Im Hinblick auf automatisierte Regressionstests spart man langfristig an Testaufwänden

Broschüre „Shift Left Testing“ jetzt herunterladen

×
Telefon

Sie sind auf der Suche nach einem Experten im Bereich App-Entwicklung? Wir freuen uns auf Ihre Nachricht!

+49 231 99953850
×