Exploratives Ensemble Testing bezeichnet eine Methode, bei der eine Gruppe gemeinsam vor einem Computer Software testet: ohne vordefinierte Testfälle, dafür mit klar rotierende Rollen (Driver, Navigator, Ensemble) in festen Zeitintervallen von acht bis zehn Minuten. Ausgangspunkt ist eine Charter, eine grobe Idee zum Untersuchungsbereich. Jedes Experiment informiert das nächste.
Das Wichtigste in Kürze
- Ensemble Testing funktioniert nur, wenn alle Beteiligten ihre Rollen konsequent einhalten: Der Driver trifft keine Entscheidungen, der Navigator fasst den Computer nicht an, und der Timer erzwingt die Rotation alle 8 bis 10 Minuten.
- Spätes Stakeholder-Feedback kurz vor dem Release-Termin war der konkrete Auslöser für die Einführung von explorativem Ensemble Testing, nicht ein methodischer Idealismus.
- Das erklärte Ziel einer Session ist nicht, Fehler zu finden, sondern anhand einer Charter etwas über das System zu lernen; Fehler entstehen dabei als Nebenprodukt, nicht als Maßstab.
- Notizen aus der Session werden bewusst wertfrei gehalten und erst ein bis zwei Tage später mit Produkt- und Projektmanagement ausgewertet, um die Diskussion “Bug oder kein Bug” aus dem Testfluss herauszuhalten.
- Entwicklerinnen und Entwickler bauen durch wiederholte Sessions implizit Testwissen auf, erkennbar daran, dass sie Edge Cases vorhersagen, die sie selbst bereits ausprobiert haben.
Was ist exploratives Ensemble Testing?
Exploratives Ensemble Testing bedeutet, dass eine Gruppe von Menschen gemeinsam vor einem Computer sitzt und Software in klar verteilten Rollen testet, ohne vordefinierte Testfälle. Statt fertiger Skripte gibt es eine Charter, eine grobe Idee dessen, was untersucht werden soll. Aus dem ersten Experiment entstehen die nächsten.
Der Begriff Ensemble Testing löst die ältere Bezeichnung Mob Testing ab. Der Wechsel kam, als klar wurde, dass “Mob” und die Nähe zu “Mobbing” keine gute Wortwahl sind. Inhaltlich beschreibt Ensemble die Sache präziser: eine Gruppe, die zusammen an einer Aufgabe arbeitet.
Die Methode verbindet zwei Praktiken. Das Rollenmodell stammt aus der kollaborativen Arbeit am Code, das offene Vorgehen aus dem explorativen Testen. Beides greift ineinander, weil die Gruppe gemeinsam entscheidet, was als Nächstes ausprobiert wird.
Wie funktioniert die Rollenverteilung im Ensemble?
Im Ensemble gibt es drei feste Rollen: Driver, Navigator und das beobachtende Ensemble. Diese Trennung ist das Herzstück der Methode.
Der Driver sitzt am Computer und bedient ihn. Er trifft aber keine Entscheidung. Der Navigator entscheidet, was getan wird, fasst die Tastatur jedoch nicht an. Wenn beide schweigen, passiert nichts. Erst wenn sie miteinander reden, entsteht ein Testschritt. Diese erzwungene Kommunikation ist gewollt.
Der Rest der Gruppe beobachtet und wirft Ideen ein. Über die Umsetzung entscheidet trotzdem allein der Navigator. Wer eine Idee unbedingt durchsetzen will, muss warten, bis er selbst Navigator ist. Dann wird sie gemacht.
Die Rollen rotieren in einem festen Zeitraster, in der Praxis alle acht bis zehn Minuten. So kommt jeder einmal in jede Position. Eine komplette Session dauert üblicherweise rund anderthalb Stunden, davon mindestens eine Stunde reine Testzeit, der Rest entfällt auf Intro und Nachbereitung.
Warum lohnt sich der Einstieg über ein klar benanntes Problem
Ensemble Testing braucht einen konkreten Anlass, sonst startet es nicht. Der Auslöser bei Tobias Geyer war ein wiederkehrendes Muster: Probleme tauchten in späten Testphasen auf, Feedback von internen Stakeholdern kam regelmäßig zu spät, um es noch ins aktuelle Release zu bringen.
Das Release-Tempo verschärfte den Druck. Bei zwei bis vier Releases im Jahr ist kein kurzfristiges Nachschieben möglich. Spätes Feedback bedeutet dann oft Monate Verzögerung. Genau das frustrierte viele im Team.
Die Methode wurde nicht als Pflichtprozess eingeführt, sondern als Experiment vorgeschlagen. Diese Rahmung half. Statt eine neue Vorgabe durchzusetzen, stand die Frage im Raum, ob es das Problem löst. Das Feedback war positiv, und seitdem läuft es regelmäßig.
Wenn du Ensemble Testing einführen willst, hilft dieser Weg: Benenne ein reales Schmerzthema, nenne es Experiment, lade breit ein und lass die Beteiligten selbst entscheiden, ob es sich lohnt.
Ein Vier-Wochen-Rhythmus hält die Methode am Leben
Die Frequenz entscheidet darüber, ob Ensemble Testing zur Routine wird oder zur lästigen Pflicht. Ein Vier-Wochen-Rhythmus, gekoppelt an den Sprint, hat sich bewährt.
Der Abstand sorgt für zwei Effekte. Erstens ist mindestens ein Sprint vergangen, es gibt also ein neues Feature oder zumindest eine neue Perspektive, etwa ein bekanntes Feature mit einer anderen Persona. Zweitens behält die Session einen gewissen Neuheitscharakter, weil sie nicht ständig stattfindet.
Die anderthalb Stunden sind zugleich eine bewusste Pause vom Alltagsgeschäft. Das wird als Wert empfunden, nicht als Belastung. Ein Zeichen dafür: Abgesagte Sessions ziehen Beschwerden nach sich, nicht Erleichterung.
Eine sinnvolle Gruppengröße liegt bei etwa fünf Personen pro Ensemble als Startpunkt. Ab zehn Leuten wird aufgeteilt, damit das Rotieren und die Mitarbeit funktionieren. Diese Zahlen sind kein Gesetz, sondern eine Erfahrung, die du an deinen Kontext anpassen solltest.
Welche Fehler findet man im Ensemble Testing?
Das Spektrum reicht von simplen Klickproblemen über Exceptions bis zu Usability-Schwächen. In der Praxis war Usability ein überraschend großer Anteil der Funde.
Sichtbar wird vor allem, was kleinteilige, featuregetriebene Entwicklung übersieht. Wenn eine Charter einen größeren User-Workflow durch das ganze Produkt abbildet und die Beteiligten die Software wirklich starten, statt sich auf Unit-Tests zu verlassen, treten die Bruchstellen zwischen den Features hervor.
Ein Beispiel illustriert das. Ein Team hatte ein Eingabefeld für formatierten Text getestet, inklusive verschobener Zeilen und gelöschter Passagen. Alles funktionierte. Dann schlug ein Produktmanager als Navigator vor, den Text per Drag-and-drop zu verschieben. Alle hielten das für unmöglich. Es ging, und es warf prompt eine Exception.
Solche Funde entstehen, weil im Ensemble Menschen mit unterschiedlichen Blickwinkeln zusammensitzen. Was der eine für undenkbar hält, probiert der andere einfach aus.
Der eigentliche Gewinn ist das Testwissen im Entwicklungsteam
Ensemble Testing findet nicht nur Fehler, es baut Testkompetenz bei Entwicklerinnen und Entwicklern auf. Das ist der nachhaltige Effekt, der über die einzelne Session hinausreicht.
In den Sessions lernen Beteiligte Testideen und Testmethodik kennen. Sie entwickeln ein Gefühl dafür, was abseits des Happy Path zu prüfen ist. Dieses Wissen nehmen sie in den nächsten Sprint mit, ob explizit oder implizit.
Ein besonderer Moment zeigt diesen Lernprozess: Das Ensemble glaubt, einen Edge Case gefunden zu haben, der die Software gleich zerlegt. Die Person, die das Feature gebaut hat, sitzt daneben und sagt, das habe sie selbst schon ausprobiert. Genau dann ist Testdenken in die Entwicklung eingezogen.
Für viele bricht die Methode außerdem eine Hürde: Testen kann Spaß machen. Wer exploratives Testen vorher eher als lästig empfand, erlebt es im Ensemble als gemeinsame, lebendige Tätigkeit.
Warum Bewertung und Testen strikt getrennt gehören
Während der Session wird nicht diskutiert, ob etwas ein Bug ist. Diese Trennung hält den Fluss aufrecht und verhindert zähe Streitgespräche.
Im Test gilt eine Haltung aus dem Improv: “Yes, and”. Es gibt keine schlechten Vorschläge, Ideen werden aufgegriffen, um in Bewegung zu bleiben. Notizen entstehen möglichst wertfrei. Eine Exception oder ein Absturz ist klar, alles andere wird zunächst nur festgehalten, nicht bewertet.
Die Bewertung folgt ein, zwei Tage später in kleiner Runde mit Produkt- und Projektmanagement. Erst dort wird entschieden, was ein echter Bug ist, was akzeptiert werden kann und was vielleicht nur falsch verstandenes Produkt ist, das eine bessere Dokumentation braucht.
Wichtig ist außerdem, das Ziel klar zu setzen. Es geht nicht darum, die Software kaputt zu machen oder möglichst viele Fehler zu finden. Fehler tauchen ohnehin auf, weil jede Software welche hat. Das Ziel ist, anhand der Charter etwas über das System zu lernen.
Welche Fallstricke treten beim Ensemble Testing auf?
Zwei Probleme treffen fast jedes Team: das Mitschreiben und die Disziplin bei den Rollen.
Das Mitschreiben wird unterschätzt. Im Eifer des Testens vergisst die Gruppe leicht zu dokumentieren, was sie getan und gefunden hat. Am Ende der Session fällt es dann schwer, die Funde zu rekonstruieren. Wer im Fluss ist, denkt nicht ans Protokoll, und genau deshalb braucht es eine bewusste Notiz-Rolle oder Erinnerung.
Die Rollendisziplin rutscht besonders weg, wenn neue Leute dazukommen oder ein Ensemble frisch startet. Ein Muster ist die kreative Umgehung der Regel. Jemand sagt zum Navigator: “Sag dem Driver, er soll Button A klicken, dann XY eingeben und Feature Z auswählen.” Formal korrekt, inhaltlich am Sinn vorbei. Hier hilft nur freundliche Wiederholung der Spielregeln.
Auch der Timer ist ein Stolperstein. Mitten in einer Aktion überhört man ihn leicht, und plötzlich sind zehn Minuten überzogen. Die Rotation diszipliniert nur, wenn sie eingehalten wird.
Externe Stakeholder brauchen einen eigenen Rahmen
Interne Kunden ins Ensemble zu holen, bringt wertvolles Feedback vor dem echten Kunden, kann die Dynamik aber kippen. Sie neigen dazu, dominant zu werden.
Die Lösung ist eine Aufteilung in zwei Session-Typen. Die eine läuft mit dem Entwicklungsteam, die andere bindet interne Stakeholder ein, ergänzt um einzelne Vertreter der Entwicklung. So entsteht ein Wissensaustausch, ohne dass eine Gruppe das Geschehen an sich zieht.
Die offene Baustelle bleibt die Beteiligung. Das Entwicklungsteam ist deutlich größer als der Kreis, der regelmäßig teilnimmt. Ein Teil kam nie dazu, andere stiegen über die Zeit aus. Mehr Menschen zurückzuholen ist ein erklärtes Ziel.
Im Endeffekt ist es eine Meeting-Einladung, man braucht vielleicht einen Meetingraum. Anderthalb Stunden fliegen unter jedem Management-Radar durch. Einfach machen und davon überrascht werden, wie gut die Leute es selbst finden.
Tobias Geyer
