Ensemble Testing bezeichnet eine kollaborative Arbeitsmethode, bei der vier bis sechs Personen gemeinsam testen oder programmieren: eine Person führt aus, die übrigen denken laut und leiten an. Denken und Ausführen sind damit bewusst getrennt. Das macht implizites Wissen explizit, fördert Wissensaustausch zwischen Testern und Entwicklern und liefert kreativere Ergebnisse als Einzelarbeit.
Das Wichtigste in Kürze
- Ensemble Testing trennt Denken und Ausführen konsequent: Eine Person tippt nur auf Anweisung, das gesamte restliche Team denkt laut mit und macht so implizites Wissen explizit.
- Die ideale Ensemble-Gruppe hat vier bis sechs Personen, weil darunter einzelne Stimmen untergehen und darüber die Session zäh wird.
- Ensemble-Formate überzeugen Skeptiker leichter als Pair Programming, weil das Gruppen-Setting weniger persönlichen Druck erzeugt als das direkte Eins-zu-eins-Arbeiten.
- Tester müssen durch Ensemble-Sessions keine Programmierer werden, sondern bauen genug Verständnis auf, um qualifiziertere Fragen zur Testbarkeit zu stellen.
Was Ensemble Testing und Ensemble Programming bedeuten
Ensemble Testing und Ensemble Programming sind kollaborative Arbeitsformate, bei denen eine ganze Gruppe gemeinsam an einer Aufgabe arbeitet, statt sie unter sich aufzuteilen. Eine Person sitzt an Tastatur und Maus, der Rest der Gruppe sitzt drumherum und denkt laut mit. Das Ziel ist nicht, schneller fertig zu werden. Es geht um Wissensaustausch, Teambuilding und gemeinsames Lernen.
Thomas Much beschreibt das Format als Weiterentwicklung von Pair Programming, an dem er jahrelang als Coach gearbeitet hat. Statt zwei Leuten arbeiten vier bis sechs zusammen. Der Begriff hat mehrere Namen: Mob Programming, Team Programming, Software Teaming. Für den Test-Kontext spricht man von Ensemble Testing.
Der Reiz liegt darin, dass mehrere Rollen denselben Raum teilen. Entwickler, Tester, manchmal auch Architekten oder Leute aus dem Fachbereich sitzen zusammen und produzieren etwas Konkretes: Code oder Tests.
Die wichtigste Regel: Denken und Ausführen trennen
Das zentrale Prinzip beim Ensemble-Arbeiten ist die Trennung von Denken und Ausführen. Die Person an der Tastatur führt nur aus. Sie entscheidet nicht, was passiert. Das Denken übernimmt die Gruppe.
Diese ausführende Person heißt Typist. Sie tippt, klickt und gibt Werte ein, aber sie wird nicht von sich aus aktiv. Wenn nichts aus der Gruppe kommt, fragt sie nach: Wo soll ich hinklicken? Welchen Betrag soll ich eingeben? Thomas nennt das ein “Smart Input Device”. Der Typist darf jederzeit zurückfragen, wenn er etwas nicht verstanden hat, und darf darauf bestehen, dass die Gruppe sich einig wird.
Durch dieses laute Denken wird implizites Wissen explizit. Warum gibt jemand eine Zahl mit Punkt und nicht mit Komma ein? Welche Ober- und Untergrenze muss man beim Testen beachten? In normaler Einzelarbeit bleiben solche Entscheidungen unsichtbar. Im Ensemble werden sie ausgesprochen und diskutiert.
Warum das Format niemanden überfordert
An der Tastatur muss niemand etwas können, weil die Intelligenz im Raum sitzt. Wer nicht programmieren kann, gibt anfangs vielleicht nur einzelne Zeichen ein. Das nivelliert sich schnell, weil man zwischendurch zwanzig Minuten zusieht, was die anderen tippen, und mitbekommt, wie es ungefähr läuft.
Genau hier liegt der Hebel für gemischte Teams. Tester eignen sich nebenbei Entwicklungsverständnis an, Entwickler bauen Testwissen auf. Keiner muss die andere Rolle vollständig übernehmen.
Wenn ich sage, ich habe euch nicht verstanden, erklärt es mir bitte genauer, sind garantiert ein, zwei im Raum, die auch sagen: Das wollte ich immer schon mal wissen. — Thomas Much
Das funktioniert, weil ein Ensemble ein sicherer Raum ist. Vermeintlich dumme Fragen, die sich in einer Eins-zu-eins-Situation niemand traut, fallen in der größeren Runde leichter. Thomas hat erlebt, wie CEO, Teamleiter und Projektleiter mitgemacht haben, einfach um zu sehen, ob es wirklich so zugänglich ist.
Die richtige Gruppengröße liegt bei vier bis sechs
Vier bis sechs Personen sind die ideale Größe für ein Ensemble. Bei weniger Teilnehmern fehlen Ideen, und die Dynamik kippt.
Zu zweit dominiert meist einer, der andere geht unter oder traut sich nicht zu fragen. Auch zu dritt wird oft einer untergebuttert, sobald zwei dieselbe Meinung haben. Ab vier Personen gleichen sich die Stimmen aus, und die Gruppe moderiert sich selbst. Die lauteste Stimme muss auch mal still sein, weil sie gerade an der Tastatur sitzt.
Mehr als sechs Teilnehmer machen die Sache zäh. Thomas hat einmal mit zwölf Leuten gearbeitet und alle zwei Minuten gewechselt. Es hat Spaß gemacht, aber die Gruppe war eigentlich zu groß.
Nimm dir genug Zeit, sonst bringt es nichts
Eine Ensemble-Session braucht Zeit, und Hetze ist Gift. Unter Stress traut sich niemand zu fragen, und der sichere Raum verschwindet.
Thomas empfiehlt Teams, die einsteigen, einen Block von zwei bis drei Stunden pro Woche zu reservieren. Wenn die Aufgabe früher fertig ist, umso besser. Dann nutzt man die übrige Zeit, um den Code wartbarer zu machen oder einen weiteren Test zu automatisieren. Die Zeit füllt sich von selbst.
Geübte Teams kommen auch mit einer Stunde aus, wenn das Setup vorbereitet ist und der Rechner läuft. Beim Einstieg gilt aber: lieber zu großzügig planen als zu knapp.
Die Person an der Tastatur wechselt in kurzen Intervallen, alle fünf bis zehn Minuten. Ein Timer gibt die Timebox knallhart vor, damit gewechselt wird, ohne zu diskutieren. Technikbegeisterte hängen gern an der Tastatur und geben ungern ab. Der Timer löst das.
Ensemble-Arbeit ist nachhaltiger als Pair Programming
Skeptiker für Ensemble-Arbeit zu gewinnen ist leichter als für Pair Programming. Das hat mit dem anderen Setting zu tun.
Thomas zitiert einen Vergleich, den er von einem Agile Coach kennt: Pair Programming sei wie ein Date, bei dem es menschlich perfekt passen muss, sonst wird es anstrengend. Ensemble-Arbeit dagegen sei wie eine Party mit Freunden, entspannter und unverbindlicher. Das macht das Format im Alltag haltbarer. Es wird im Schnitt häufiger genutzt.
In der Praxis liegen Teams irgendwo zwischen zwei Extremen. Manche probieren es einmal und vergessen es. Andere arbeiten intensiv damit. Die meisten landen bei einer gesunden Mischung: Im Daily besprechen sie, was sie diese Woche gemeinsam angehen wollen.
Architektur ist ein Teamsport
Aus agiler, kontinuierlicher Sicht ist Architektur kein Spezialistenthema, sondern Teamarbeit. Lokale Design- und Architekturentscheidungen trifft das Team. Zentrale Architekten moderieren das Ganze und sorgen dafür, dass das Unternehmen nicht auseinanderläuft.
Wenn Architektur dezentral ist, gehört sie ins Ensemble wie Code und Tests. Die Unterscheidung ist simpel: Was im Code versteckt ist, ist Design. Was man von außen beobachten kann, ist Architektur.
Wo Architekturteams stärker getrennt arbeiten, lohnt es sich, sie regelmäßig in die Sessions zu holen. Architekten, die zentral Entscheidungen treffen, erleben dann, was ihre Vorgaben in der Umsetzung bedeuten. Dieses Erlebnis liefert ihnen neue Ideen, wie sie angemessener vorgeben können.
Dasselbe gilt für Fachabteilungen, die zu wenige Features beklagen. Holt man sie hinein, verstehen sie, was die Entwicklung schwierig macht: unklar spezifizierte Features oder Ansprechpartner, die selten erreichbar sind.
Ein Ensemble-Meeting produziert Code, kein Protokoll
Der häufigste Management-Einwand lautet: Vier Leute, zwei Stunden, die müssen doch arbeiten. Thomas dreht das Argument um. In Meetingräumen sitzen Manager auch nie allein. Sie tauschen sich aus, weil sie etwas erreichen wollen.
Der Unterschied zur Ensemble-Session ist das Ergebnis. Management-Meetings produzieren bestenfalls eine Agenda oder ein Protokoll. Eine Ensemble-Session produziert getesteten Code mit ordentlicher Architektur. Genau das, was ein Entwicklungsteam braucht.
Das Format entstand vor über zehn Jahren bei Woody Zuill und seinem Team, anfangs als U-Boot-Projekt am Management vorbei. Die Begründung gegenüber den Vorgesetzten war einfach: Wir machen ein Meeting. Nur produziert dieses Meeting Code und Tests.
Wie du die erste Session aufsetzt
Starte vor Ort, nicht remote. Vor Ort entstehen Mimik, Gestik und gemeinsames Lachen, und niemand fällt sich ins Wort. Remote erfordert Screen Sharing, Tooling für die Übergabe und deutlich mehr Disziplin. Das hebt man sich für später auf.
Die wichtigsten Erfolgsfaktoren für den Einstieg:
- Raum: nicht zu klein, nicht zu groß, damit es nicht anonym wird.
- Teilnehmer: vier bis fünf Kolleginnen und Kollegen, die mitmachen wollen.
- Vorbereitung: Eine Person setzt das Setup vorab auf, damit der Rechner läuft. Wenn die Gruppe erst eine halbe Stunde wartet, ist die Lust weg.
- Aufbau: Rechner an einem Stehpult, der Rest sitzt entspannt drumherum. Wer ausführt, steht auf und geht zum Rechner. Diese kleine Bewegung trennt das Tun vom Zusehen.
- Rollen: Der Typist hält sich zurück und wird nicht von sich aus aktiv. Die Gruppe denkt laut.
- Timer: Rotation per Smartphone-Timer, damit der Wechsel ohne Diskussion passiert.
Für den Einstieg eignen sich Coding Katas, also kleine Übungsbeispiele. Danach geht es schnell an echte Aufgaben, damit sich das Format nicht nur im Schulungsraum bewährt. Wer tiefer einsteigen will, findet Videomaterial von Woody Zuill zu Mob Programming und Software Teaming sowie von Lisi Hocke zu Ensemble Testing.
