Jenga Testing Game

Das Jenga Testing Game demonstriert anschaulich die Eigenschaften von agilem Testen. Die Simulation macht erlebbar, wie wichtig es ist möglichst früh Produkttests in die Entwicklung einzubeziehen. Die Teilnehmenden lernen in verschiedenen Rollen eines Teams innerhalb von drei Runden durch verschiedene Vorgehensweisen (angefangen bei der Vorgehensweise nach Wasserfall, gefolgt von iterativen Vorgehen mit Sprint hin zum Pair Programming) das schnelles und häufiges Testen effektiver ist und das die Bedeutung der Integration von Qualität bei der testgetriebenen Entwicklung einen hohen Stellenwert hat.

Vorbereitung

Es werden 36 Jenga Blöcke pro Team mit 5-7 Personen benötigt, die von 1-36 nummeriert sind und zusätzlich in Gruppen von 1-12, 13-24, 25-36 farblich gekennzeichnet sind.

Zusätzlich ist es sinnvoll verschiedene Schilder für die unterschiedlichen Rollen wie Entwickler, Business Analyst, Designer und Tester bereitzustellen. Bis auf den Tester können die Rollen auch mehrfach besetzt werden.

Tipp: Damit es abwechslungsreich bleibt, empfehle ich die Rolle des Testers für jede Runde neu zu besetzen. So kann auch der ungewohnte Perspektivenwechsel für einen Entwickler inspirierend sein, wenn dieser die Tester Rolle bewusst einnehmen kann.

Aufgabe der Entwickler ist es, mit den Blöcken eine Struktur aufzubauen. Der Turm muss mindestens drei Stockwerke hoch sein. Dabei müssen alle Blöcke verwendet werden. Nach einer gewissen Zeit entfernt ein Tester bestimmte Problem-Blöcke (Bugs). Hierzu werden zufällige Nummern vom Moderator gezogen, beispielsweise durch ein Zufallszahlengenerator oder durch entsprechende Karten. Wenn ein Fehler erkannt wird, wird er entfernt und nicht wieder eingefügt. Nach dem Entfernen muss weiterhin die Anforderung erfüllt sein, dass der Turn drei Stockwerke hoch ist.

Ablauf

Insgesamt werden 3 Runden gespielt. Die Anforderungen sind immer gleich, der einzige Unterschied in jeder Runde ist, wie schnell/wie oft die Struktur getestet wird. Für jede Runde wird ein neuer Satz von insgesamt 6 Zufallszahlen als zu behebende Bugs vom Moderator aufgeschrieben. Jede Runde beginnt damit, dass der Entwickler die Struktur gemäß den Anforderungen erstellt, wobei der Tester basierend auf den Regeln der Runde Feedback gibt.

Runde 1

Der Entwickler baut innerhalb von 3 Minuten einen Turm, der mindestens drei Stockwerke hoch ist und muss dabei alle Blöcke verwenden. Der Tester darf die gebaute Struktur erst verifizieren nachdem die gesamte Struktur gebaut wurde. Der Tester entfernt am Ende die sechs Blöcke, die Probleme verursachen. Ist nach dem entfernen der Blöcke der Turm weiterhin mind. drei Stockwerken hoch?

Learnings: Wenn wie beim Wasserfall Modell erst am Ende getestet wird, besteht die Gefahr das sich ein Projekt durch ein tiefsitzenden Fehler verzögert oder gar fehlschlägt. Dies wäre bei einem Jenga Turms auf den unteren Ebenen der Fall.

Runde 2

Das Entwicklungsteam baut innerhalb von 3 Minuten einen Turm, der mindestens drei Stockwerke hoch ist und muss dabei alle Blöcke verwenden. Der Unterschied ist diesmal, dass das Entwicklungsteam die Blöcke in drei separaten Stapel aufteilt: 1-12, 13-24 und 25-36. Für jeden Stapel hat der Entwicklungsteam somit 1 Minute Zeit. In dieser Runde darf der Tester immer zwei problematischen Blöcke entfernen, nachdem jeweils 12 Blöcke eingefügt wurden. Der Tester erhält also drei Gelegenheiten, Feedback zu geben. Ist nach dem entfernen der Blöcke der Turm weiterhin mind. drei Stockwerken hoch?

Learnings: Wenn Tester und Entwickler zusammenarbeiten, liefern sie qualitativ hochwertige Software mit weniger Nacharbeit. Da die Rückmeldung schneller erfolgt, kann der Entwickler den Code frühzeitig korrigieren und minimiert so die Risiken.

Runde 3

Die Anforderungen sind unverändert und die Blöcke stehen weiterhin in drei Stapeln zur Verfügung. Dieses Mal darf der Tester beim Aufbau der Struktur innerhalb der 3 Minuten mit dem Entwickler zusammenarbeiten und gleich auf Bugs hinweisen. Der Moderator teilt dem Tester vor Beginn der Runde die Nummern für jeden Fehler mit. Ist nach dem entfernen der Blöcke der Turm weiterhin mind. drei Stockwerken hoch?

Learnings: Dies ist der effektivste Weg, da der Tester dem Entwickler in Form von Pair Programming dabei hilft das Einbauen von Fehlern zu vermeiden. Ein weiterer Schritt könnte sein, Ansätze wie Test-driven development (TDD) zu verwenden und Tests zu automatisieren.

Varianten

• Vereinfachung durch Entwicklung der Struktur in Komponenten/Modulen: In diesem Fall sollte es einfacher sein, die Struktur anzupassen, da ganze Komponenten verschoben werden können, anstatt blockweise angepasst werden zu müssen.
• Herausforderung: Entfernte Bugs wieder zur Verfügung stellen. Dies würde einen wiederkehrenden Fehler darstellen, der in der Entwicklung passieren kann. Eine weitere Alternative ist immer die Zufallszahlen aus allen schon verbauten Blöcken zu ziehen.

Debriefing

• Wie war es in die verschiedenen Rollen zu schlüpfen? Welche Erkenntnisse oder Erfahrungen kann hier mitgenommen werden?
• Welche Auswirkung hat die Anzahl der Rückmeldung des Testers auf die Qualität?
• Die Fehlerdichte (Fehler / geänderte Codezeilen) war in jeder Runde gleich. Was sich in jeder Runde geändert hat, war die Geschwindigkeit wie schnell ein Fehler gefunden wurde und somit die Qualität. Welche Auswirkungen hätte es gehabt, wenn doppelt soviel Fehler vorkommen?
• Welche Auswirkungen hatte die Tatsache, dass nicht auf jeder Seite die Nummer ersichtlich war, auf das Design des Turms?
• Welche Erkenntnisse aus dem Spiel kann auf die Software Architektur übertragen werden?
• Was kannst du als Ziel des agilen Testen für dich mitnehmen?