Jeder, der bereits als Testmanager in einem Projekt unterwegs war, kennt die Situation. Es muss ein Testkonzept erstellt werden, welches lieber gestern als heute vorliegen sollte. Mit Hilfe von verschiedenen und zeitaufwendigen Ermittlungstechniken versuchen wir die notwendigen Informationen zusammenzutragen. Dies um anschliessend das Testkonzept in Form eines Dokumentes zu erstellen. Neben dem nicht unerheblichen Aufwand ist auch der Sinn und Nutzen dieser Vorgehensweise in Frage zu stellen. Da es gerade im Agilen keine explizite Design- bzw. Testphase gibt, bedarf es einer angepassten Methode, mit der schnell Ergebnisse erzielt werden können. Zusätzlich haben wir den Anspruch, dass nicht nur der Testmanager, sondern alle beteiligten Rollen und Mitarbeitenden den Inhalt des Testkonzeptes kennen, verstehen und aktiv umsetzen können. Die Notwendigkeit hierfür ergibt sich insbesondere auch aus dem Test-first und Built-in-Quality Ansatz.
Das Agile Testing Canvas
Wir haben darüber nachgedacht, wie und in welcher Darstellungsform ein zeitgemässes Testkonzept in einem agilen Umfeld erstellt werden kann. Die erste Idee war eine Art Definition of Test – angelehnt an die Definition of Ready und Definition of Done. Hier galt es die notwendigen Inhalte zu definieren und eine klare und strukturierte Darstellungsform zu finden. Nach diversen Überlegungen und einigen Workshops haben wir uns für die Darstellung in Form eines Canvas entschieden. Nicht nur die klare Struktur eines Canvas, sondern auch die Erarbeitung der Ergebnisse durch das Team ist an dieser Stelle ein grosser Vorteil. Das Testkonzept ist nicht länger eine «One-Person-Show», sondern eine Teamleistung. Durch die Teamleistung wird nicht nur die Notwendigkeit, sondern auch das Verständnis der definierten und erarbeiteten Massnahmen geschärft wird.
Den Canvas haben wir zum Beispiel auf verschiedenen Ebenen im SAFe Umfeld eingesetzt. Auf der Programm-Ebene haben wir die Rahmenbedingungen festgelegt, um anschliessend die Detaillierung auf Team-Ebene vorzunehmen. Selbstverständlich kann das erstellte Canvas auch als Commitment zur Built-in-Quality betrachtet werden.
Das Agile Testing Canvas wurde zwar für agile Vorhaben konzipiert. Er kann aber – mit Adaption – ebenfalls für Hybride und sogar Wasserfall Projekte verwendet werden. So können zum Beispiel statt DoR / DoD die Meilensteine und Quality-Gates definiert werden.
Aufbau und Struktur
Wir haben das Agile Testing Canvas in 8 Bereiche gegliedert, wobei die Nummerierung auch die Reihenfolge der Erarbeitung ergibt:
- System under Test (SUT)
- Testpyramide
- Testmatrix
- Testvorgehen (Pipeline)
- Definition of Ready (DoR)
- Definition of Done (DoD)
- Risikobasiertes Testen
- Was sonst?
Im folgendem schauen wir uns die einzelnen Bereiche detaillierter an.
1. System Under Test (SUT)
Wir beginnen mit dem ersten Bereich, dem System Under Test (SUT). Innerhalb der Systemgrenze wird das eigentliche Testobjekt (bestehend aus dessen Teilsystemen) platziert. Ausserhalb der Systemgrenze, die hier als Quadrat dargestellt ist, werden die erforderlichen Umsysteme, die zum Testen notwendig sind, skizziert. Zusätzlich könnten wir für die einzelnen Umsysteme festlegen, für welche Umgebungen diese verfügbar sind, und ob es für das jeweilige Umsystem einen Mock gibt.
Hierbei ist zu beachten, dass das SUT nur das zu testende System inkl. notwendiger Umsysteme darstellt und nicht das komplett Architekturdiagramm.
2. Die Testpyramide
In der Testpyramide (nach Mike Cohn) zeichnen wir die verschiedenen relevanten Ebenen ein. Diese weisen wir anschliessend dem entsprechenden Testfokus zu. Zusätzlich können wir die vorhandenen Testumgebungen den verschiedenen Ebenen zuordnen (z.B. DEV/ TEST/ INT / PROD). Gemäss dem bereits erwähnten Test-First Prinzip sollte der Testaufwand auf der untersten Ebene der Testpyramide am stärksten ausgeprägt sein. Je weiter wir uns in der Testpyramide nach oben bewegen, umso geringer sollte die Anzahl der Testszenarien sein. Auch der Automatisierungsgrad nimmt entsprechend ab, im Gegensatz zur Businessrelevanz, die mit jeder Ebene zunimmt.
3. Die Testmatrix
In die Testmatrix tragen wir die Testaktivitäten aus den verschiedenen Sichten ein. Wir unterscheiden hier vier Bereiche:
Der erste Quadrant bildet die technische Teamsicht ab. In dieser Sicht befinden wir uns auf Ebene Code, sodass die hier definierten Tests aus Sicht Entwicklung dargestellt werden. Zu diesen gehören Testverfahren aus dem Whitebox-Testing. Ein hoher Automatisierungsgrad ist anzustreben.
Im zweiten Quadranten wird die fachliche Teamsicht auf die funktionalen Aspekte der Artefakte abgebildet. Dies können – abhängig vom Projektaufbau – sowohl Features als auch Stories sein. Erste Usability Tests können ebenfalls bereits angestrebt werden.
Im dritten Quadranten betrachten wir, mit dem Fokus auf Anwender und Nutzer, die fachliche Sicht auf das Produkt. Neben der Validierung von Softwarekomponenten, die aus einem Feature oder Epic hervorgegangen sind, werden an dieser Stelle auch die UAT und die Usability Tests über das gesamte Produkt eingeplant.
Die technische bzw. betriebliche Sicht auf das Produkt wird im vierten Quadranten dargestellt. Hier findet alles Platz, was zu den nicht funktionalen Anforderungen (NFA) zählt, wie z.B. Last-/ und Performancetests oder auch Security Tests. Sinnvoll an dieser Stelle ist ein Verweis auf die ISO 25010.
4. Das Testvorgehen (Pipeline)
Nachdem wir die Inhalte der Testpyramide (Feld 2) und der Testmatrix (Feld 3) erarbeitet und ausgefüllt haben, bringen wir diese in der Pipeline zusammen. Hierbei ist es wichtig, dass wir die Aktivitäten pro Entwicklungsschritt im Prozess platzieren und nicht in den klassischen Teststufen denken. Weiterhin definieren wir an dieser Stelle die zuständigen Rollen. Zusätzliche Informationen, wie z.B. die notwendigen Testinfrastruktur können ebenfalls an dieser Stelle definiert werden. Das Vorgehen erfolgt gemäss dem Built-in-Quality Ansatz.
5. Definition of Ready (DoR)
In der DoR definieren wir die notwendigen Massnahmen, um ein Backlog Item für die Umsetzung bereitstellen zu können. Wir unterscheiden an dieser Stelle die verschiedenen Abstraktionsebenen der Backlog Items (Epic/Feature und Story). Dies da sich die Anforderungen an die DoR zwischen diesen unterscheiden. Aus unserer Sicht ist es sinnvoll, die DoR als Checkliste und nicht als starre Vorgabe zu betrachten. Sonst besteht die Gefahr, dass sich das Team selbst blockiert. Weiterhin sollte die DoR in regelmässigen Abständen hinterfragt und wenn notwendig angepasst werden.
6. Definition of Done (DoD)
Die DoR stellt eine Checkliste des Teams an die Qualität eines Backlogitems für die Umsetzung dar. In der DoD wird definiert, wann die Arbeit an einem Backlogitem mit den geforderten Qualitätsaspekten erfolgreich abgeschlossen ist. Mit Erfüllung der DoD wird aus dem Backlog Item ein Produkt Inkrement. Auch bei der DoD unterscheiden wir die verschiedenen Abstraktionsebenen (Epic/Feature und Story).
7. Risikobasiertes Testen
Da ein vollständiges Testen unmöglich ist, müssen wir Prioritäten setzen. Diese gelingt am besten durch den Einsatz einer Risikomatrix. Mit Hilfe der Qualitätsrisiko-Matrix können wir jedes Item einer Risikoeinstufung unterziehen. Die Einstufung ergibt sich aus der Multiplikation der beiden Werte (Fehler-) Wahrscheinlichkeit und Schadensausmass. Je nach Risikoeinstufung können wir anschliessend den Testumfang definieren.
8. Was sonst?
Selbstverständlich können wir nicht jedes Detail bzw. jedes Konzept im Zusammenhang mit der Qualität in diesem Canvas abbilden. Dieses Feld dient uns dazu, weitergehende Detaillierungen zu verlinken. So können wir an dieser Stelle beispielsweise auf ein vorhandenen Testhandbuch verweisen. Auch Konzepte zu Testdaten, Testautomatisierung, Defect-Management können wir hier anbringen.
Fazit
Die Erarbeitung eines agilen Testkonzeptes muss nicht länger eine One-Person-Show sein, vielmehr ist hier das gesamte Team gefragt. Neben der einfachen Anwendung des Canvas ist auch die Adaption in unterschiedlichste Projektstrukturen und Vorgehensweisen problemlos möglich.
Sie möchten gleich loslegen? Dann finden sie hier den Download-Link.
