##  Pfadnavigation

1. [ Startseite ](/)
2. [ Software Testing & Qualität - Testautomatisierung, KI & Agilität ](/podcast/software-testing-qualitaet-testautomatisierung-ki-agilitaet)
3. Exploratives Ensemble-Testing: Qualität durch Teamarbeit steigern

# Exploratives Ensemble-Testing: Qualität durch Teamarbeit steigern

            **Podcast:**

   [Software Testing & Qualität - Testautomatisierung, KI & Agilität](/podcast/software-testing-qualitaet-testautomatisierung-ki-agilitaet)

              **Erscheinungsdatum:**

   20. Januar 2026

            **Länge:**

   00:20:54

    [         Link zur Episode (extern)   ](https://www.richard-seidl.com/de/podcast/exploratives-ensemble-testing)

 ![Exploratives Ensemble Testing - Tobias Geyer](https://www.botcaster.de/sites/default/files/styles/podcast_n_episode_metadata_image_1x/public/2026-08/6b84b30f-9dda-4ea6-ba34-a92b66ab5b67.jpg.webp?itok=FSqfoxVk)

###   Exploratives Ensemble Testing - Tobias Geyer

   20. Januar 2026 · [Software Testing & Qualität - Testautomatisierung, KI & Agilität](/podcast/software-testing-qualitaet-testautomatisierung-ki-agilitaet)

Wie kann ein Team die Qualität seiner Software grundlegend verbessern, ohne nur neue Tools einzuführen oder Prozesse zu verkomplizieren? Oft liegt die Lösung in der Art und Weise, wie Menschen zusammenarbeiten. In einer neuen Folge seines Podcasts *Software Testing & Qualität* spricht Host Richard Seidl mit dem erfahrenen Softwaretester Tobias Geyer über eine Methode, die genau hier ansetzt: das explorative Ensemble-Testing. Tobias teilt seine Erkenntnisse aus über zwei Jahren praktischer Anwendung und zeigt, wie dieser kollaborative Ansatz nicht nur Fehler früher aufdeckt, sondern auch das gesamte Team für das Thema Qualität begeistert. Diese Episode ist ein Muss für alle, die nach Wegen suchen, Silos aufzubrechen und ein gemeinsames Verständnis für das Produkt zu schaffen - von Entwickler:innen bis hin zu Produktmanager:innen.

## Das Wichtigste auf einen Blick

- **Was ist exploratives Ensemble-Testing?** Früher als Mob-Testing bekannt, bezeichnet es eine Methode, bei der ein ganzes Team gemeinsam an einem Computer eine Software testet. In klar definierten und rotierenden Rollen - Driver, Navigator und Ensemble - wird das System systematisch, aber ohne starre Testfälle erkundet.
- **Das Ziel ist gemeinsames Lernen, nicht nur Fehler finden.** Tobias betont, dass das Hauptziel nicht das Zerstören der Software ist, sondern das gemeinsame Lernen über ihr Verhalten. Fehler werden zwangsläufig gefunden, aber der Erkenntnisgewinn für das gesamte Team steht im Vordergrund.
- **Ein Katalysator für frühes Feedback.** Die Methode hat sich als äußerst wirksam erwiesen, um Probleme und Usability-Schwächen aufzudecken, lange bevor sie in späten Testphasen oder beim Kunden landen. Dies ist ein Paradebeispiel für den Shift-Left-Ansatz in der Praxis.
- **Es ist eine wirkungsvolle Schulungsmethode.** Entwickler:innen, die an den Sessions teilnehmen, entwickeln ein tieferes Verständnis für Testmethoden und lernen, über den Tellerrand ihres eigenen Features hinauszuschauen. Sie beginnen, selbstständig wie Tester:innen zu denken.
- **Die Struktur ist der Schlüssel zum Erfolg.** Feste Rollen, ein Timer für die Rotation (üblicherweise 8-10 Minuten) und eine klare Mission (die Charter) verhindern Chaos und sorgen dafür, dass alle Perspektiven gehört werden.
- **Der Einstieg ist unkompliziert.** Tobias ermutigt dazu, es einfach als Experiment zu starten. Eine anderthalbstündige Besprechungseinladung fliegt meist unter dem Radar des Managements und der Nutzen wird schnell sichtbar.

## Was ist exploratives Ensemble-Testing? Eine Methode für das ganze Team

Stell dir vor, dein gesamtes Entwicklungsteam sitzt zusammen vor einem Bildschirm, um eine neue Funktion zu testen. Das klingt zunächst nach Chaos, funktioniert aber dank einer klaren Struktur erstaunlich gut. Tobias erklärt die drei zentralen Rollen, die das Fundament des Ensemble-Testings bilden. Der **Driver** bedient Maus und Tastatur, darf aber keine eigenen Entscheidungen treffen. Der **Navigator** gibt die Anweisungen, was der Driver tun soll, und trifft die strategischen Entscheidungen. Das restliche Team, das **Ensemble**, beobachtet, bringt Ideen ein und unterstützt den Navigator. Der Clou: Alle 8 bis 10 Minuten rotieren die Rollen. So kommt jeder zu Wort, und auch die Person mit der vermeintlich verrückten Idee bekommt die Chance, sie als Navigator umzusetzen.

Kombiniert wird dieser Ansatz mit dem **Exploratory Testing**. Statt einem starren Testplan folgt das Team einer sogenannten Charter - einer groben Mission, wie zum Beispiel Wir erkunden den neuen Checkout-Prozess aus der Perspektive eines Neukunden. Auf Basis dieser Charter führt das Team Experimente durch, lernt dabei über das System und lässt diese Erkenntnisse in die nächsten Schritte einfließen. Dieser dynamische Ansatz fördert Kreativität und deckt Probleme auf, die in vordefinierten Testfällen oft übersehen werden.

## Zwei Jahre in der Praxis: Erfolge und Erkenntnisse

Warum hat Tobias diese Methode überhaupt eingeführt? Der Auslöser war ein wiederkehrendes Problem: Wichtiges Feedback von Stakeholdern und Fehlerberichte kamen so spät, dass sie nicht mehr im aktuellen Release-Zyklus behoben werden konnten. Das frustrierte das Team und verzögerte Verbesserungen. Inspiriert von einem Workshop bei Lisi Hocke, startete Tobias das Ensemble-Testing als Experiment. Der Erfolg gab ihm recht.

In den letzten zwei Jahren hat sein Team eine breite Palette von Fehlern gefunden - von einfachen UI-Glitches über unerwartete Exceptions bis hin zu gravierenden Usability-Problemen. Tobias berichtet von einem besonders eindrücklichen Moment: Ein Produktmanager schlug als Navigator vor, Text per Drag-and-Drop in einem Eingabefeld zu verschieben. Das Entwicklerteam wusste nicht einmal, dass dieses Feature existieren sollte. Der Versuch endete in einer Exception und führte zu einem wichtigen Aha-Erlebnis für alle. Solche Momente zeigen, wie die Methode Wissenssilos aufbricht und ein gemeinsames Produktverständnis schafft. Der größte Gewinn ist laut Tobias jedoch die Entwicklung eines Test-Mindsets im Team. Wenn Entwickler:innen in den Sessions Edge Cases vorschlagen und die Person, die den Code geschrieben hat, stolz antwortet Habe ich schon ausprobiert, ist das ein klares Zeichen für einen nachhaltigen Kulturwandel.

## Der Ablauf einer Session: Struktur schafft Kreativität

Um die Methode erfolgreich und effizient zu gestalten, hat sich bei Tobias ein fester Rhythmus etabliert. Die Sessions finden alle vier Wochen statt, passend zum Sprint-Zyklus, und dauern etwa anderthalb Stunden. Das reicht für eine kurze Einführung, rund eine Stunde reines Testen und eine abschließende Zusammenfassung. Die Einladung geht an das gesamte Team, einschließlich Produkt- und Projektmanagement. Typischerweise nehmen genug Personen teil, um ein bis zwei Ensembles mit jeweils etwa fünf Mitgliedern zu bilden.

Ein entscheidender Faktor für den reibungslosen Ablauf ist die strikte Trennung von Testdurchführung und Fehleranalyse. Während der Session werden alle Beobachtungen, Ideen und potenziellen Fehler wertfrei in Notizen festgehalten. Das Team konzentriert sich darauf, im kreativen Fluss zu bleiben, anstatt in Diskussionen über die Schwere eines Bugs stecken zu bleiben. Erst ein oder zwei Tage später setzt sich Tobias mit den Produkt- und Projektmanager:innen zusammen, um die Notizen zu sichten und zu entscheiden, welche Punkte als Bugs angelegt, welche als Verbesserungsvorschläge behandelt oder welche durch bessere Dokumentation gelöst werden müssen. Diese Trennung bewahrt die positive und kollaborative Dynamik der Session.

## Motivation und Teamdynamik: Wie die Methode langfristig begeistert

Könnte eine regelmäßige, anderthalbstündige Testsitzung nicht mit der Zeit langweilig werden? Tobias verneint das entschieden. Der Schlüssel zur anhaltenden Motivation liegt in der Abwechslung. Jede Session hat eine neue Charter, die sich auf ein neues Feature, eine andere Benutzer-Persona oder einen komplexen Workflow konzentriert. Der vierwöchentliche Rhythmus sorgt dafür, dass die Methode frisch bleibt und nicht zur reinen Routine verkommt.

Für viele im Team ist die Session eine willkommene Abwechslung vom Alltagsgeschäft. Sie bietet einen Raum, um fokussiert und kreativ zusammenzuarbeiten, ohne den Druck der täglichen Aufgaben. Tobias berichtet schmunzelnd, dass er sich schon Beschwerden anhören musste, als er eine Session absagen musste - ein klares Indiz dafür, dass die Teilnehmenden den Wert und den Spaß an der Methode erkannt haben. Die Teamdynamik war durchweg positiv, was vor allem an der klaren Struktur mit den rotierenden Rollen liegt, die sicherstellt, dass niemand dominiert und alle zu Wort kommen.

## Praktische Schritte: So startest Du mit explorativem Ensemble-Testing

Wenn du jetzt neugierig geworden bist und die Methode in deinem eigenen Team ausprobieren möchtest, gibt Tobias einige wertvolle Tipps für den Einstieg:

1. **Verkaufe es als Experiment:** Nenne es nicht gleich eine neue, feste Prozesskomponente. Lade dein Team zu einem anderthalbstündigen Experiment ein. Das senkt die Hürden und weckt die Neugier.
2. **Lade eine vielfältige Gruppe ein:** Je mehr unterschiedliche Perspektiven (Entwicklung, Produktmanagement, vielleicht sogar Support), desto wertvoller die Erkenntnisse.
3. **Bereite eine klare Charter vor:** Formuliere eine prägnante Mission für die erste Session. Das gibt dem Team eine klare Richtung und einen Fokus.
4. **Erkläre die Regeln zu Beginn:** Nimm dir fünf Minuten Zeit, um die Rollen (Driver, Navigator, Ensemble), den Timer und das Ziel des gemeinsamen Lernens zu erläutern.
5. **Dokumentation ist alles:** Der häufigste Anfängerfehler ist, das Mitschreiben zu vergessen. Bestimme eine Person, die Notizen macht, oder nutzt ein geteiltes Dokument. Ohne Aufzeichnungen geht der Wert der Session verloren.
6. **Sei ein guter Moderator:** Achte darauf, dass die Rollen und der Timer eingehalten werden. Erinnere das Team freundlich, aber bestimmt an die Regeln, besonders in den ersten Sessions.
7. **Trenne Testen von der Analyse:** Beende die Session mit den gesammelten Notizen und plane einen separaten Termin für die Triage der Ergebnisse. Das hält die Energie hoch und verhindert endlose Debatten.

---

 version="1.0" encoding="UTF-8"?
      .st0 {
        fill: #010101;
      }

      .st1 {
        fill: #b0c0b3;
      }

      .st2 {
        fill: #3b3a3b;
      }

      .st3 {
        fill: #3a3a3a;
      }

      .st4 {
        fill: #5e7185;
      }

      .st5 {
        fill: #f9eddd;
      }

      .st6 {
        fill: #000100;
      }

      .st7 {
        fill: #aebeb3;
      }

      .st8 {
        fill: #fefefe;
      }

      .st9 {
        fill: #7f93a8;
      }

      .st10 {
        fill: #f8f0df;
      }

      .st11 {
        fill: #fbf0df;
      }

      .st12 {
        fill: #afbfb2;
      }

      .st13 {
        fill: #f7eedd;
      }

      .st14 {
        fill: #fdfdfd;
      }
                                                                                   Botcaster

  **Zusammengefasst von Anja Schirwinski**

Ich beschäftige mich beruflich wie privat mit Künstlicher Intelligenz - von konkreten Tools im Arbeitsalltag bis zu den größeren Fragen, die dabei aufkommen. Viele der Themen, die in Podcasts besprochen werden, begegnen mir in Projekten immer wieder. Deshalb fasse ich hier die für mich interessantesten Podcastfolgen zusammen und ordne sie aus der Praxis ein.

[Mehr über das Projekt Botcaster](/ueber-uns)

##  Themen

 - [  Testen und Qualität  ](/podcasts/themen/testen-qualitaet)
- [  Mitarbeitende befähigen  ](/podcasts/themen/mitarbeitende-befaehigen)

**Hinweis:** *Diese Zusammenfassung wurde mit Hilfe von KI aus dem Transkript der Podcast-Episode generiert.*

Alle Inhalte auf Botcaster beruhen auf öffentlich zugänglichen Podcasts rund um Künstliche Intelligenz. Wir fassen die Episoden nach bestem Wissen zusammen, übernehmen jedoch keine Gewähr für Vollständigkeit, Aktualität oder Richtigkeit der Inhalte. Die Rechte an den Original-Podcasts und -Inhalten liegen ausschließlich bei den jeweiligen Urheber:innen.

         ## Shownotes

   In dieser Episode spreche ich mit Tobias Geyer über exploratives Ensemble Testing. Er nutzt die Methode seit zwei Jahren und zeigt, warum sie wirkt. Wir besprechen wie die Rollen Driver und Navigator funktionieren, das rotieren der Rollen und die kompakten 90-Minuten-Sessions. Das Ergebnis: früheres Feedback, viele Usability-Funde und vor allem Lernen im Team. Entwickler entdecken den Blick über den Happy Path hinaus. Streit? Kaum, weil wir Notizen sammeln und die Bewertung später machen. Wichtig sind klare Charters, gute Moderation und diszipliniertes Mitschreiben.