Aufstieg und Neuerfindung der Testing Quadranten

Als Tester keinen Platz am agilen Tisch hatten

Extreme Programming war eine Methodik, die von Entwicklern für Entwickler geschaffen wurde. Alles ausserhalb der Programmierung wurde in die Rolle des „XP-Kunden“ gepackt, was sich aus der Entwicklersprache ungefähr mit „nicht mein Problem“ übersetzen lässt. Als Unternehmen Mitte der 2000er Jahre begannen, agile Methoden einzuführen, wurden Business-Analysten zu Product Owners und Projektmanager zu Scrum Masters. Tester, seit jeher die armen Verwandten der Softwarewelt, fragten sich, ob sie überhaupt noch einen Job hatten.

Die Verwirrung war real. In einem grossen Finanzdienstleistungsunternehmen kündigte die gesamte Testabteilung innerhalb einer Woche, nachdem sie erfahren hatte, dass die Organisation Scrum einführen würde. Entwickler weltweit hofften insgeheim, dass ein paar gut geschriebene JUnit-Tests dedizierte Tester überflüssig machen würden.

Ein Framework, das einen Beruf rettete

Brian Marick skizzierte die Testing Quadranten um 2003 und ordnete Testaktivitäten entlang zweier Dimensionen an. Die vertikale Achse trennte geschäftsorientierte Tests von technologieorientierten Tests. Die horizontale Achse trennte Tests, die das Team während der Entwicklung unterstützen, von Tests, die das fertige Produkt bewerten. Es war eine klare, intuitive Taxonomie.

Lisa Crispin und Janet Gregory machten die Quadranten durch ihr Buch Agile Testing von 2009 berühmt. Das Modell wurde zum Herzstück des Buches, das eine Diagramm, das sich jeder von jedem Konferenzvortrag merkte. In weniger als fünf Minuten konnte man mit den Quadranten einem skeptischen Entwickler zeigen, dass Unit-Tests nur eine Ecke einer viel grösseren Qualitätslandschaft besetzten. Das Framework gab Testern eine Sprache, um ihre Rolle zu verteidigen, und half Teams, ausgewogene Teststrategien zu entwickeln.

Warum passt das Modell nicht mehr?

Die Quadranten wurden für eine Welt aus zweiwöchigen Sprints mit einer klaren Grenze zwischen Entwicklung und Release gebaut. Anfang der 2010er Jahre löste sich diese Welt auf. Continuous Delivery bedeutete, dass Teams mehrmals täglich deployen. DevOps verwischte die Grenze zwischen dem Erstellen und Betreiben von Software. Lean-Startup-Praktiken drängten Teams dazu, Produkthypothesen vor dem Schreiben von Code zu testen.

Die horizontale Achse wurde zum Problem. Sie verlangte von Teams, Aktivitäten, die „das Team unterstützen,“ von denen zu trennen, die „das Produkt bewerten.“ In einer Umgebung mit Continuous Delivery bricht diese Trennung zusammen. Performance-Tests, die während der Entwicklung laufen, unterstützen das Team durch das Erkennen von Regressionen und bewerten das Produkt durch das Messen von Antwortzeiten. Funktionale Tests, die durch Specification by Example erstellt werden, sind gleichzeitig Entwickler-Feedback und geschäftliche Abnahme. Explorative Tests, von vielen Praktikern in die „Bewertungs“-Hälfte eingeordnet, liefern ihre wertvollsten Erkenntnisse, wenn sie früh im Zyklus durchgeführt werden.

Gojko Adzic, Autor von Specification by Example und Impact Mapping, formulierte es so: Je mehr er versuchte, moderne Praktiken auf vier Quadranten abzubilden, desto unübersichtlicher wurde das Bild. Aktivitäten, die einst sauber in einem Quadranten sassen, überspannen jetzt zwei oder drei. Das Framework, das Verwirrung reduzieren sollte, hatte begonnen, sie zu erzeugen.

Eine Achse überlebt, die andere muss ersetzt werden

Die vertikale Achse funktioniert weiterhin. Die Unterscheidung zwischen geschäftsorientierten und technologieorientierten Tests bleibt eine nützliche Faustregel. Sie hilft Teams, Kompetenzen zuzuordnen, Werkzeuge zu wählen und Gespräche zwischen technischem Personal und geschäftlichen Stakeholdern zu strukturieren.

Die horizontale Achse braucht eine neue Fragestellung. Statt zu fragen „Unterstützt dies das Team oder bewertet es das Produkt?“ ist die nützlichere Unterscheidung die zwischen Prüfen und Analysieren. Prüfen bedeutet, vordefinierte erwartete Ergebnisse zu verifizieren: Assertions in automatisierten Tests, Compliance-Validierungen, Regressions-Suiten. Analysieren bedeutet, Bereiche zu untersuchen, in denen es keine vordefinierte richtige Antwort gibt: explorative Tests, Penetrationstests, Lasttests zur Ermittlung von Belastungsgrenzen, Usability-Forschung, Analyse von Produktionsprotokollen.

Was die neue Achse offenbart

Diese Neuausrichtung löst mehrere hartnäckige Debatten. Sicherheitstests teilen sich natürlich in Penetrationstests auf der Analyseseite und Compliance-Prüfungen auf der Prüfseite, was den Mythos entkräftet, dass Sicherheit ein einziges „nicht-funktionales“ Anliegen sei. Performance-Tests teilen sich ähnlich: Explorative Lasttests, die fragen „Wo wird es brechen?“ gehören zur Analyse, während automatisierte SLA-Verifizierung eine Prüfung ist.

Die Unterscheidung bringt auch Qualitätsaktivitäten zum Vorschein, die traditionelle Testpläne selten abdecken. A/B-Experimente, Produktionsanalysen, hypothesengetriebene Produkttests und Trendanalysen operativer Daten befinden sich alle auf der Analyseseite. Sie liefern Erkenntnisse statt Bestanden/Nicht-bestanden-Urteile und erfordern qualifizierte Interpretation statt skriptgesteuerter Ausführung. Ein Grossteil der heutigen Innovation in der Softwarequalität findet in diesem Bereich statt.

Die Community des kontextgetriebenen Testens hatte jahrelang ein ähnliches Argument vorgebracht: Das Verifizieren erwarteter Ergebnisse ist nicht wirklich Testen im vollen Sinne. Prüfen ist notwendig, aber mechanisch. Analyse ist dort, wo Tester echte Kompetenz und echtes Urteilsvermögen einsetzen. Ein Modell, das dies sichtbar macht, hilft Organisationen, durchdachter in beide Dimensionen zu investieren.

Frameworks sollten sich mit der Branche weiterentwickeln

Die ursprünglichen Testing Quadranten haben wichtige Arbeit geleistet. Sie haben den Testberuf innerhalb agiler Teams legitimiert, in einer Zeit, als dieser Beruf ernsthaft bedroht war. Die Tatsache, dass wir das Modell jetzt aktualisieren müssen, ist keine Kritik an seinen Schöpfern. Es ist der Beweis, dass sich die Branche weiterentwickelt hat, teilweise weil Frameworks wie die Quadranten ihr dabei geholfen haben.

Teams brauchen weiterhin ein gemeinsames mentales Modell für die Teststrategie. Die Achse Prüfen/Analysieren bietet eine bessere Passung für Organisationen, die Continuous Delivery praktizieren, DevOps-Pipelines betreiben und Lean Product Management anwenden. Die vertikale Achse beizubehalten bewahrt die ursprüngliche Erkenntnis, dass Testen sowohl geschäftliche als auch technische Dimensionen hat. Die horizontale Achse zu ersetzen aktualisiert das Modell für eine Welt, in der die Grenze zwischen Entwicklung und Betrieb praktisch verschwunden ist.