Teststufen und Agilität

Agiles Testen: Mitarbeiter werten Ergebnisse aus
© SFIO CRACHO – fotolia.com

Beim agilen Testen wird das starre, sequentielle Durchlaufen der einzelnen Teststufen aufgebrochen. Zwar sind die einzelnen Stufen noch immer notwendig – schließlich erfüllen sie jeweils unterschiedliche Aufgaben, für die es in der agilen Entwicklung keinen Ersatz gibt. Aber sie können flexibel und inkrementell ausgeführt werden.

In agilen Projekten entscheidet das Team, wann und in welchem Umfang welche Teststufen für einen bestimmten Teil der Software bereits vorgezogen werden können. Um diese Entscheidung einfacher zu machen, hat sich in der Praxis ein Modell von Gregory und Crispin (Agile Testing – A Practical Guide for Testers and Agile Teams, AddisonWesley, 2008) bewährt. Es unterteilt die unterschiedlichen Arten von Tests nicht nach ihrer Stufe, sondern entlang zweier Dimensionen (siehe Abbildung). Demnach unterscheiden sich Tests darin, ob sie eher technische oder fachliche Anforderungen prüfen (1. Dimension) und ob sie eher zur Absicherung der Grundfunktionen oder des Softwareprodukts als Ganzes gedacht sind (2. Dimension).

Quadranten des agilen Testens
Abbildung: Die vier Quadranten des agilen Testens [Quelle: lisacrispin.com]

In der ersten Dimension (Y-Achse) wird zwischen fachlichen und technischen Tests unterschieden. Fachliche Tests testen die Software gegen Anforderungen, die sich auf das Geschäft beziehen, wie zum Beispiel die korrekte Berechnung eines Versicherungstarifs. Sie müssen von Teammitgliedern durchgeführt werden, die eine gewisse Expertise von der Domäne haben, in der die Software angewendet wird (z. B. ein Anwender). Technische Tests hingegen testen, ob Softwarebausteine mit anderen Bausteinen zusammen funktionieren und schnell genug auf Benutzereingaben reagieren. Sie werden von Teammitgliedern durchgeführt, die eine technische Expertise haben (z. B. ein Entwickler oder ein Mitarbeiter des IT-Betriebs).

Die zweite Dimension (X-Achse) unterscheidet, ob die Tests eher dazu dienen, nur den sogenannten „Happy Path“, also nur die Grundfunktionen zu testen. Solche Tests lassen sich gut einsetzen, um die grundsätzliche Funktionstüchtigkeit der Software inklusive aller funktionalen Anforderungen zu testen. Anhand der Quote bestandener Tests kann das Team dadurch stets messen, wie weit es mit der Abarbeitung der Anforderungen ist. Deshalb werden diese Tests auch „teamunterstützend“ bezeichnet. Sofern die Tests eher auf nicht-funktionale Anforderungen ausgerichtet sind, also zum Beispiel die Bedienbarkeit oder Zuverlässigkeit der Software, oder sofern die Tests auch die Funktionstüchtigkeit abseits der üblichen Nutzungspfade prüfen, so handelt es sich um sogenannte „produkthinterfragende“ Tests.

Als Entscheidungshilfe für die Praxis bietet es sich an, die einzelnen agilen Testarten im Überblick zu haben:

Quadrant 2Quadrant 3

Quadrant 1Quadrant 4

Nach oben scrollen