Testen im Lebenszyklus
Kurz gesagt: Das Entwicklungsmodell ändert, wann getestet wird, nicht ob. Im Wasserfall ist das Testen eine Phase am Ende, in Agile steckt es in jeder Story, in DevOps in der Pipeline bei jeder Änderung. Shift-left verschiebt das Prüfen zur Anforderung hin. Die Pyramide sagt, wie viele Tests auf welcher Stufe, und die Quadranten, welche Arten.
Problem
Die Tester bekamen den Shop im letzten Monat
Das Projekt für den neuen Shop liegt im Plan: 3 Monate Anforderungen, 6 Monate Programmierung, dann Testen. Im letzten Monat finden die Tester 140 Fehler. 30 davon stecken nicht im Code, sondern in den Anforderungen: „innerhalb von 14 Tagen“, ohne zu sagen, ab wann; „über 50 €“, ohne zu sagen, ob einschließlich.
Eine Anforderung im Monat 10 zu korrigieren heißt, Code anzufassen, der im Monat 4 geschrieben wurde. Die Freigabe verschiebt sich um 3 Monate.
Die Idee
Das Modell ändert, wann, nicht ob
Jedes Modell des Softwarelebenszyklus hat Testen. Der Unterschied ist, wann und wie:
| Modell | Wo das Testen sitzt |
|---|---|
| Wasserfall | Eine eigene Phase am Ende, nach dem gesamten Code. |
| V-Modell | Jede Phase hat ihre eigene Teststufe, von Anfang an geplant: Anforderungen → Abnahme, Architektur → Integration. |
| Iterativ, inkrementell | In jeder Iteration wird der neue Teil getestet und alles Alte mit Regressionstests. |
| Agile (Scrum, Kanban) | In jeder Story. QA ist im Team, und „fertig“ heißt auch getestet (Definition of Done). |
| DevOps | In der Pipeline (CI/CD): Jede Änderung geht automatisch durch die Tests, bevor sie die Kunden erreicht. |
Eine Regel gilt für alle: Zu jeder Entwicklungsaktivität gibt es eine passende Testaktivität. Eine Anforderung hat ein Review, Code hat einen Test, eine Story hat Akzeptanzkriterien.
Genauer, für Neugierige
Das steht im CTFL v4.0.1, Abschnitt 2.1. Der Lehrplan listet bewährte Vorgehensweisen auf, die für jedes Modell gelten: Zu jeder Entwicklungsaktivität gibt es eine entsprechende Testaktivität; jede Teststufe hat ihre eigenen Ziele; Testanalyse und Testentwurf beginnen schon in der entsprechenden Entwicklungsphase; Tester prüfen Arbeitsergebnisse, sobald Entwürfe vorliegen. DevOps steht in 2.1.4 und Shift-left in 2.1.5.
Probier es aus
Welches Modell?
Die Idee
Shift-left: nach links in der Zeit
Zeichne das Projekt als Linie: Anforderung, Entwurf, Code, Test, Freigabe. Shift-left heißt, das Prüfen nach links zu verschieben, zum Anfang hin.
Im Shop sind das Dinge, die du im Kurs schon gesehen hast:
- die Anforderung „kostenlose Lieferung über 50 €“ vor dem Code prüfen: Ist 50,00 € eingeschlossen?
- Example Mapping und Beispiele für jede Regel, bevor die Story in Arbeit geht;
- Szenarien, die vor dem Code geschrieben werden und später zu automatisierten Tests werden;
- Komponententests, die der Entwickler bei jeder Änderung laufen lässt.
Shift-left heißt nicht weniger Testen am Ende. Es heißt, dass du am Ende weniger findest, weil die meisten Fehler dort gefangen wurden, wo sie am wenigsten kosten.
Genauer, für Neugierige
Shift-left hat einen Preis: Schulung, Zeit am Anfang, Automatisierung. Der CTFL v4.0.1 sagt das auch: Der Ansatz braucht früh Aufwand, und die Einsparungen kommen später. Die Gegenidee, Shift-right, ist Testen und Überwachen nach der Freigabe: Messen mit echten Kunden, neue Funktionen schrittweise ausrollen. Darum geht es im Modul „Validieren mit dem Kunden“.
Die Idee
Die Pyramide: wie viele Tests auf welcher Stufe
Die Testpyramide sagt, wie viele Tests es auf jeder Stufe geben sollte:
- Die Basis: viele Komponententests. Tausende, in Sekunden ausgeführt, die genau auf den Fehler zeigen.
- Die Mitte: weniger Integrations- und Servicetests. Sie prüfen die Verträge zwischen den Teilen.
- Die Spitze: wenige End-to-End-Tests durch den ganzen Shop und den Browser. Sie sind langsam, gehen kaputt, wenn sich ein Button ändert, und wenn sie fehlschlagen, weißt du noch nicht, wo der Fehler ist.
Je höher du gehst, desto langsamer, teurer und zerbrechlicher sind die Tests, und desto weniger davon sollte es geben. Die umgekehrte Pyramide, mit Tausenden von Browsertests und wenigen Komponententests, heißt Eistüte (ice cream cone).
Genauer, für Neugierige
Die Pyramide stammt von Mike Cohn („Succeeding with Agile“, 2009). Sie ist kein Gesetz: Die Zahl der Stufen und ihre Namen variieren. Der CTFL v4.0.1 beschreibt sie in Abschnitt 5.1.6 als Modell, das zeigt, dass Tests auf niedrigeren Stufen kleiner, schneller und zahlreicher sind, auf höheren langsamer, größer und weniger.
Die Idee
Die Quadranten: welche Arten
Die Pyramide zählt. Die Testquadranten ordnen die Arten nach zwei Fragen: Ist der Test geschäftsorientiert oder technologieorientiert, und unterstützt er das Team beim Bauen oder kritisiert er das fertige Produkt?
| Das Team unterstützen | Das Produkt kritisieren | |
|---|---|---|
| Geschäft | Q2: Szenarien und Beispiele, Prototypen, funktionale Tests | Q3: exploratives Testen, Usability, UAT, Demos |
| Technologie | Q1: Komponenten- und Integrationstests | Q4: Leistung, Last, Informationssicherheit |
Q1 und Q2 werden meist automatisiert. Q3 ist manuell: Ein Mensch betrachtet das Produkt. Q4 wird mit Werkzeugen gemacht. Ein Team, das nur Q1 hat, hat schnellen Code, weiß aber nicht, ob es das richtige Produkt ist.
Genauer, für Neugierige
Die Quadranten stammen von Brian Marick (2003) und wurden durch die Bücher von Lisa Crispin und Janet Gregory über agiles Testen bekannt. Im CTFL v4.0.1 stehen sie in Abschnitt 5.1.7.
Übung
Die Quadranten im Shop
1. Welcher Quadrant? Sortiere die Tests des Shops.
Test