Machen wir mal einen Test

Keine Sorge, hier wird keine Prüfung abgenommen. Hier geht es um das Testmanagement in agilen Projekten. Auf den ersten Blick scheinen Testmanagement und Agilität wenig miteinander zu tun zu haben. Scrum zum Beispiel kennt weder die Rolle des Testmanagers noch die des Testers. Dennoch wäre es falsch, daraus zu schließen, dass das Testen in agilen Projekten keinen besonderen Stellen­wert besäße. Einzel-, Komponenten- und Systemtests sind bei der Entwicklung von softwareintensiven Systemen unverzichtbar – auch in agilen Projekten. Allerdings laufen sie nicht – wie in Projekten, die sich am V-Modell orientieren – als abgegrenzte Teststufen phasenweise, also nacheinander ab. Im Rahmen von Releases und Sprints folgen die Schritte, mit denen implementierte Funktionen integriert und getestet werden, häufiger und in viel kürzeren Abständen aufeinander als bei klassischem Vorgehen. Aber wenn man sich nicht an festen Teststufen mit vorgegebenen Verantwortlichkeiten und Rollen orientieren kann, wie entscheidet man dann in einem agilen Projekt, welche Tests benötigt werden?

Eine Antwort darauf geben Marick [1] und etwas detaillierter Crispin/Gregory [2] mit ihrem Konzept der Testquadranten. Es bietet einem Team eine einfache Hilfestellung, um Tests zu kategorisieren und zu prüfen, ob es alle relevanten Testarten bedacht hat.

Die Testquadranten entstehen durch zwei Achsen: Entlang der senkrechten Achse werden fachlich orientierte von technologiebezogenen Tests unterschieden. Die waagerechte Achse reicht von teamunterstützenden Tests, mit denen die Qualität der Umsetzung vom Team überprüft wird, bis zu produkthinterfragenden Tests, mit denen festgestellt wird, ob das entwickelte Produkt den Erwartungen der Stakeholder entspricht.

Mithilfe dieser Achsen werden vier Testarten unterschieden:

• Technische, teamunterstützende Tests (Quadrant Q1): Dazu zählen vor allem Unit-Tests, Komponenten- und Kom­ponen­tenintegrationstests (Ablauftests). Unit-Tests werden oft in programmiersprachen-abhängigen Testumgebungen automatisiert.
• Fachliche, teamunterstützende Tests (Q2): Diese Kategorie umfasst alle Tests, die die Frage beantworten: Wurde alle Funktionen so umgesetzt, wie es gefordert war? Hier geht es also um die Funktionstests, mit denen die Erfüllung der funktionalen Anforderungen überprüft wird. Außerdem gehören in diese Kategorie die Tests von Prototypen und Simulationen.
• Fachliche, produkthinterfragende Tests (Q3): Im Mittelpunkt steht hier die „Business-Tauglichkeit“ der Lösung aus Anwendersicht. Es geht unter anderem um den Nachweis, dass die Usability-Anforderungen erfüllt sind. Neben den Usability- und Benutzerakzeptanztests, gehören auch das Testen von Be­nutzungsszenarien, Alpha- und Beta-Tests und das explorative Testen zu dieser Kategorie.
• Technische, produkthinterfragende Tests (Q4): In diese Kategorie fallen alle Tests, die sich auf die nicht-funktionalen Anforderungen bzw. die Qualitäts­anforderungen beziehen: Dazu gehören Last-, Performance-, Zugriffs- und Datensicherheits- sowie Stresstests, die häufig mit spezialisierten Testwerkzeugen durchgeführt werden. Weitere Tests dieser Kategorie beziehen sich auf die Wartbarkeit, Skalierbarkeit und Migrationsfähigkeit der Lösung.

Die Quadranten Q2, Q3 und Q4 haben eines gemeinsam: Mit den dazu gehörenden Tests, die zu einem großen Teil manuell durchgeführt werden, soll die Frage beantwortet werden: Erfüllt die Software die Anforderungen der Stakeholder? Getestet wird also „gegen“ die Anforderungen.*

Wenn sich ein agiles Team darauf verständigt hat, welche Entwicklungsergebnisse bezogen auf welche Anforderungen getestet werden sollen, dann muss es „nur noch“ alle zugehörigen Testfälle „einsammeln“ und „durchtesten“. Allerdings sollte das so geschehen, dass die Tests

• geplant und gesteuert werden können,
• wiederholbar sind,
• nachvollziehbar werden und bleiben.

Diese Aspekte des Testmanagements – Planbarkeit, Wiederholbarkeit und Nachvollziehbarkeit – sind ein Fall für ein Tool.

objectiF RPM unterstützt anforderungsgetriebenes, agiles Vorgehen im Projekt. Was liegt näher, als die Funktionalität um anforderungsgetriebenes Testmanagement zu erweitern? Die Workflows des Testmanagements wird man mit dem Tool anwenderspezifisch ausprägen. Das grundlegende Prinzip bleibt aber gleich. Und das zeige ich Ihnen in einem kurzen Video:

Bugs anlegen, sie zur Behebung einplanen, nachtesten und Regressionstests durchführen – die Geschichte des Testmanagements in objectiF RPM ist damit noch nicht fertig erzählt. Für heute möchte ich es jedoch bei diesen ersten Eindrücken belassen.

[*]Bei den Tests der Kategorie Q1 geht es um die Frage: Macht die Software das, was sich der Entwickler vorgenommen hat? Sie wird durch Unit-Tests beantwortet. Die Erweiterung der verwendeten Unit-Testsuite und der erfolgreiche Durchlauf der Unit-Tests sind implementierungsnahe Aufgaben, die nicht im Kontext des anforderungsbasierten Testmanagements angesiedelt sind. Entsprechend haben wir sie hier im Beitrag ausgeklammert.

Übrigens, wenn Sie mehr über objectiF RPM wissen wollen, hier geht es zu detaillierten Informationen.

Hinweise

[1] Marick, B. (21. 08 2003). Exploration Through Example. Von My Agile testing project: http://www.exampler.com/old-blog/2003/08/21/#agile-testing-project-1 abgerufen.

[2] Crispin, L., & Gregory, J. (2008). Agile Testing: A Practical Guide for Tester and Agile Teams. Amsterdam: Addison-Wesley Longman.