Exploratory Testing, auf Deutsch exploratives Testen, ist ein forschender Testansatz: Er liefert Informationen über die Qualität einer Software dort, wo es weder Anforderungen noch erwartete Ergebnisse gibt. Mit gezielten Experimenten deckt er Unbekanntes auf, etwa Sicherheitslücken, Performance-Grenzen oder Randfälle. Risikobasierter Zuschnitt und Timeboxing lenken den Aufwand auf das, was dem Team wichtig ist, statt alles testen zu wollen.
Das Wichtigste in Kürze
- Exploratives Testen erschließt unbekanntes Terrain: Es sammelt mit Experimenten Informationen, wo keine Anforderung und kein erwartetes Ergebnis existiert, statt ein bekanntes Ergebnis zu bestätigen.
- Eine feste Timebox pro Sitzung und die anschließende Rücksprache mit dem Team verhindern beides: endloses Verbeißen in ein Detail und Arbeit an Fehlern, die niemand beheben wird.
- Vollständiges Testen ist mathematisch unmöglich: Ein einziges Eingabefeld mit 100 Zeichen hat mehr Zeichenkombinationen, als das Universum Sekunden alt ist.
- Erkenntnisse aus explorativen Sitzungen gehören in geskriptete oder automatisierte Tests, sobald das Verhalten verstanden ist, denn für wiederholbare Regressionstests taugt exploratives Testen schlecht.
- Golden Master Testing hält fest, was ein Live-System heute tut, und sichert dieses Verhalten mit Tests ab. Das ist ein legitimer Weg, Regressionsabdeckung nachzurüsten, wenn die ursprünglichen Anforderungen verloren sind.
Exploratory Testing heißt experimentieren, nicht herumklicken
Beim Exploratory Testing führst du Experimente durch, um etwas über das Unbekannte zu erfahren oder eine Vermutung zu bestätigen. Das unterscheidet exploratives Testen vom klassischen Testen, bei dem du vorher festlegst, was passieren soll, und dann prüfst, ob es passiert ist.
Die Grenze zieht das erwartete Ergebnis. Weißt du schon, was eine Funktion tun soll, schreibst du einen Test mit klarem Ja oder Nein. Explorative Tests passen in die Situationen, in denen du keine Erwartung hast und manchmal nicht einmal eine Anforderung. Du gehst hinein, um herauszufinden, was das System tatsächlich tut.
Ein Beispiel ist Performance. Ohne Benchmark und ohne Vorstellung davon, wie sich das System unter Last verhält, klärst du das mit Experimenten. Ein Test, der besteht oder fehlschlägt, ist hier gar nicht das Ziel. Du sammelst die Informationen, mit denen du später entscheiden kannst, ob das Verhalten akzeptabel ist.
Damit räumst du auch mit einem verbreiteten Missverständnis auf: Exploratives Testen ist kein wahlloses Herumstochern. Callum Akehurst-Ryan sieht es als Spektrum. Am einen Ende steht die lockere Fehlerjagd, bei der Leute Knöpfe drücken und warten, bis Fehler herausfallen. Am anderen Ende steht etwas Geplantes und Technisches, bis hin zu Durchläufen, die KI und Automatisierung unterstützen. Beide Enden sind legitim, aber keines beschreibt das Ganze.
Wann exploratives Testen sinnvoll ist: wenn Anforderungen fehlen
Du testest explorativ, wenn es nichts gibt, wogegen du testen könntest. Viele Unternehmen haben jede Menge Software gebaut, ohne je aufzuschreiben, wie gut aussieht. Die Anforderungen, die du normalerweise prüfen würdest, existieren schlicht nicht.
Callum ist der einzige Quality Engineer in seinem Unternehmen, umgeben von Softwareentwicklern mit unterschiedlicher Erfahrung. In diesem Umfeld setzt er Exploration immer wieder für drei Dinge ein.
Erstens für Shift Left. Du untersuchst Entwürfe, User Stories oder Architekturdokumente, bevor etwas gebaut ist, und suchst nach Risiken, über die das Team reden sollte. Kriterien für bestanden oder nicht bestanden gibt es da noch nicht, nur die Frage, was schiefgehen könnte.
Zweitens für Randfälle. Entwickler bleiben gern auf dem Happy Path und schreiben so wenige Unit-Tests, wie sie gerade noch vertreten können. Wer das System erkundet, findet die Fälle, an die niemand gedacht hat.
Drittens, um nicht-funktionale Anforderungen nachzurüsten. Sicherheit, Performance, Wartbarkeit, Benutzbarkeit, Barrierefreiheit, Deploybarkeit: Viele Produkte sind live gegangen, ohne dass jemand dafür Schwellenwerte festgelegt hat. Du erkundest dann nicht, um eine vorgegebene Latte zu reißen, sondern um ein erstes ehrliches Bild zu bekommen. Die Seiten laden so schnell, außer hier. Das System verkraftet so viele Nutzer. Diese Schwachstellen gibt es.
Diese Lücke hat System. Unternehmen arbeiten heute mit weniger Qualitätsexperten, und damit geht Wissen darüber verloren, wie gute Software aussieht. Architekten, Entwickler und Produktleute konzentrieren sich darauf, Features auszuliefern, und vergessen, dass Features nicht der einzige Wert eines Produkts sind. Gerade Start-ups und Scale-ups lassen die Dokumentation bewusst weg und überlassen es den Kunden, Probleme über ihr Feedback zu melden. Das ist eine legitime Entscheidung. Nur findet eine Qualitätsexpertin, die später dazukommt, kaum etwas, wogegen sie testen kann, und Exploration wird zum Einstieg.
Explorative Tests strukturieren: erst nach Risiko eingrenzen, dann die Uhr stellen
Struktur bekommen explorative Tests, wenn du sie auf Risiken zuschneidest und diesen Zuschnitt dann mit einer Timebox begrenzt. Ohne diese zwei Schritte ufert Exploration aus. Du könntest alles testen und würdest nie fertig.
Der Ansatz stammt aus Elizabeth Hendricksons Buch Explore It!. Die Logik ist einfach: Entscheide, was dem Team wichtig ist, beschränke deine Tests auf diese Risiken und gib dir ein festes Zeitfenster. Der risikobasierte Zuschnitt hält dich beim Wesentlichen. Die Timebox verhindert, dass du stundenlang in einem einzigen interessanten Problem verschwindest.
Callum ergänzt eine dritte Regel: Lass dein Ego draußen. Such nach Informationen, die dem Team helfen, und nicht nach dem Beweis, dass du recht hast oder ein guter Tester bist. Er beschreibt die Falle sehr bildhaft:
“Es mag ja spannend sein, dass das System nicht funktioniert, wenn Venus und Merkur in einer Linie stehen, du Löwe bist und gerade Limettengötterspeise isst. Aber das ist so ein abwegiger Randfall, dass ihn nie jemand beheben wird.”
(Callum Akehurst-Ryan)
Drei Fragen geben einer Sitzung ihre Form: Was ist uns wichtig? Was zählt für uns als Team? Was würden wir tatsächlich beheben? Die Antworten stecken dein Spielfeld ab. Innerhalb dieses Spielfelds findest du brauchbare Informationen statt Rauschen.
Der Vergleich mit einem Bug Bash ohne klaren Rahmen zeigt, warum Tiefe zählt. Wer wahllos herumklickt, findet das, was ihn persönlich stört, oder die Probleme, die ohnehin an der Oberfläche liegen. Solche Tests gehen in die Breite und bleiben flach. Ein enger Zuschnitt und eine feste Stunde führen dich in die Tiefe, wo die wichtigen Probleme meist stecken.
Wie eine Sitzung endet: die Timebox als Entscheidungspunkt
Das Ende der Timebox ist mehr als ein Stoppsignal, es ist der Anlass für ein Gespräch. Wenn die Stunde um ist, gehst du zurück zum Team und berichtest, was du gefunden hast und wo du nicht weitergekommen bist.
Bist du auf etwas gestoßen, das dir wichtig vorkommt, fragst du das Team, ob es ihm auch wichtig ist. Wenn ja, investierst du eine weitere Stunde. Hätte es niemanden interessiert, hast du dir diese Stunde gespart und machst mit dem Nächsten weiter. Der feste Schnitt erzwingt die Priorisierung, die Exploration ehrlich hält.
Der Rhythmus schützt dich auch vor dem umgekehrten Fehler: dich an etwas festzubeißen, das niemand braucht, und allein zwei Stunden daran zu verlieren. Das Spielfeld hält dich beim Wichtigen, und die Uhr holt dich immer wieder ins Team zurück, um die Grenzen neu abzustimmen.
Alles testen geht nicht, also ist Priorisierung die eigentliche Kunst
Vollständiges Testen ist unmöglich, und genau diese Einsicht macht Exploration wirksam. Die Mathematik ist gnadenlos. Ein einziges Feld mit hundert Zeichen hat über alle verfügbaren Zeichensätze und regulären Ausdrücke hinweg mehr Kombinationen, als seit Entstehung des Universums Sekunden vergangen sind. Ein einziges Feld. Bei einer Sekunde pro Test hätte das Alter des Universums nicht gereicht.
Die Frage ist also nie: “Wie decke ich alles ab?” Sie lautet: “Was ist wichtig, und was würden wir beheben?” Priorisierung ist kein Kompromiss, zu dem dich die knappe Zeit zwingt. Sie ist die Kernkompetenz.
Als einziger Tester im Team hast du ohnehin keinen Raum für drei Wochen Erkundung ins Blaue. Callum zieht das Testen deshalb nach vorn: Er will Fehler verhindern, bevor sie entstehen, und die Entwickler dazu bringen, über Risiken nachzudenken. Ein paar praktische Schritte tragen dabei die meiste Last:
- Three-Amigos-Sessions im Story Refinement: Du bringst Negativfälle ein und fragst, was mit der Performance oder mit einer Grenzbedingung passiert. So bauen die Entwickler die Lösung für ein Problem, bevor es überhaupt Code gibt.
- Risiko-Mindmaps zu einem bestehenden Ticket, nach Schichten aufgeteilt. Was kann auf der API-Ebene schiefgehen? Was auf der UI-Ebene? Performance und Sicherheit bekommen jeweils einen eigenen Ast.
- Pairing für die eigentliche Exploration, mit einer klaren Absprache vorab: Wir investieren insgesamt drei Stunden in diese drei Bereiche und nicht mehr.
Für alles gilt dieselbe Regel: Versuch nicht, gleich alles perfekt zu machen. Gut genug heißt oft eine Stunde und danach eine Entscheidung auf Basis dessen, was dabei herausgekommen ist.
Explorative Testsitzungen dokumentieren: passend zum Kontext, nicht fürs Audit
Richte deine Dokumentation nach deinem Umfeld aus, nicht nach einem Audit-Trail wie bei einer Bank. Ein großer Teil der Dokumentationskultur im Testen stammt aus dem Finanzsektor. Deshalb glauben viele, jeder Test brauche Screenshots und Nachweise. Für viele Teams stimmt das nicht.
In einem agilen, nicht regulierten Umfeld bleiben von einer Exploration oft die gemeldeten Fehler, die geführten Gespräche und das Wissen, das das Team gewonnen hat. Ein paar Zeilen in einem Slack-Kanal, eine Wiki-Seite, ein neues Ticket oder einfach die Codeänderung, die daraus folgt: Jedes davon kann der Nachweis sein.
Callum selbst hält es schlank. Er hat Block und Stift dabei, notiert unterwegs Stichworte und verdichtet sie nach der Stunde zu einem kurzen Bericht. Darin steht, was er sich angesehen hat, was in Ordnung war, wozu er Fragen hat und was ein Problem sein könnte. Mit diesem Bericht geht er ins Gespräch mit dem Team, und alles, woraus sich etwas machen lässt, wird ein Ticket.
Andere Formate funktionieren auch, je nachdem, wie ihr im Pairing arbeitet und was ihr braucht. Manche Tester nehmen ein Video auf und schauen es sich danach an. Arbeiten zwei Leute zusammen, bedient einer den Bildschirm, der andere schreibt mit, und hinterher machen beide aus den Notizen etwas Brauchbares.
Exploratives Testen füttert die Testautomatisierung, statt sie zu ersetzen
Für wiederholbare Tests ist exploratives Testen schlecht geeignet, und das liegt in seiner Natur. Stell dir eine Linie vom Bekannten zum Unbekannten vor. Du explorierst am unbekannten Ende. Was du dort lernst, rückt in Richtung des bekannten Endes, und alles Bekannte ist ein Kandidat für geskriptete oder automatisierte Tests.
Damit du nicht jede Woche dasselbe Gelände neu abläufst, überführst du dein Wissen in automatisierte Prüfungen, auf Code- oder Feature-Ebene, wo immer es darauf ankommt. Das ist deine Regressionssuite. Einen großen manuellen Regressionslauf explorativ abzuarbeiten, lädt zu Abweichungen ein, weil du ihn nie zweimal gleich durchführst.
Hier missbrauchen Teams die Methode auch gern. Manche verzichten ganz auf Planung und Automatisierung und nennen das Ergebnis exploratives Testen: keine Skripte, keine Dokumentation, einfach zwei Wochen am Monatsende, und dann mal sehen. Das ist ein Vorgehen, aber keine tragfähige Teststrategie. Exploration gehört ins Unbekannte. Sie bereitet das strukturierte Testen vor, das danach kommt, und ersetzt es nicht.
Wo KI ins Spiel kommt: das Unbekannte kartieren und dann festschreiben
KI-Werkzeuge erweitern die Exploration: Sie kartieren, was eine Anwendung tut, und machen aus dieser Karte Tests, die sich beliebig wiederholen lassen. Das Feld ist neu, und niemand sollte behaupten, es schon zu beherrschen. Die Richtung ist aber klar erkennbar.
Playwright lässt sich mit Sprachmodellen verbinden, und das Ganze funktioniert wie eine funktionale Variante eines Security-Spiders wie OWASP ZAP. Du richtest das Werkzeug auf eine Website, lässt es erkunden und crawlen, erkennst die gängigen Abläufe und dokumentierst sie. Auf Basis dieser Dokumentation rüstest du Automatisierung nach und lässt sie so oft laufen, wie du willst. Dabei kommt Gutes und Schlechtes heraus, aber als Ausgangspunkt taugt es.
Dahinter steht eine eigene Disziplin, die älter ist als die KI-Werkzeuge. Golden Master Testing geht davon aus, dass das laufende Produkt die Spezifikation ist. Die Anforderungen gibt es nicht mehr, die Tickets sind weg, und der Product Owner hat keine Zeit, die ursprüngliche Absicht zu rekonstruieren. Also schreibst du Tests, die bestätigen, was das System aktuell tut. Entwickler machen dasselbe auf Code-Ebene und nennen es Characterization Testing: Sie lesen die bestehende Logik und schreiben Tests, die ihr aktuelles Verhalten festhalten, egal was ursprünglich gemeint war.
Der ehrliche Haken: Du testest, was das Produkt tut, und nicht, was es tun sollte. Das ist schwächer als ein Test gegen die eigentliche Absicht. Wertvoll ist es trotzdem. Das heutige Verhalten festzuhalten und vor unbeabsichtigten Änderungen zu schützen, ist ein echter Fortschritt, und KI-gestützte Exploration liefert dieses erste Bild schnell.
Häufig gestellte Fragen
Was unterscheidet den explorativen Test von einem skriptbasierten Testfall?
Das erwartete Ergebnis. Wenn du bereits weißt, was eine Funktion leisten soll, reicht eine Ja-oder-Nein-Prüfung aus. Explorativer Test kommt in Situationen zum Einsatz, in denen du keine Erwartungen hast und manchmal auch keine schriftlichen Anforderungen vorliegen, also führst du Experimente durch, um herauszufinden, was das System tatsächlich macht. Leistung ohne Benchmark ist der klassische Fall: Man sammelt zuerst Informationen und beurteilt die Akzeptanz erst später.
Warum haben so viele Teams am Ende nichts, woran sie ihre Tests ausrichten können?
Die Lücke ist eher struktureller Natur als zufällig. Unternehmen arbeiten mit immer weniger Experten für Qualität, sodass das Wissen darüber, wie gute Software aussieht, immer mehr schwindet, während sich Architekten, Entwickler und Produktmanager darauf konzentrieren, Funktionen auf den Markt zu bringen. Startups und Scale-ups verzichten oft bewusst auf Dokumentation und lassen Probleme durch Kundenfeedback zutage treten. Das ist eine legitime Entscheidung, aber dadurch hat ein Qualitätsspezialist keinen festgelegten Maßstab, an dem er prüfen kann.
Wie verhindert man, dass eine explorative Sitzung in alle Richtungen ausufert?
Begrenze den Umfang auf das Risiko und leg dann eine Zeitbegrenzung fest. Diese Kombination, die aus Elizabeth Hendricksons Buch „Explore It!“ stammt, hält die Aufmerksamkeit auf das gerichtet, was das Team für wichtig hält, und verhindert, dass man sich in einem einzelnen, verlockenden Problem verliert. Drei Fragen definieren den Rahmen: Was interessiert uns, was ist uns als Team wichtig und was würden wir tatsächlich beheben?
Was sollte passieren, wenn die Zeitbegrenzung für eine Sitzung abläuft?
Du kehrst zum Team zurück und berichtest, was du herausgefunden hast und wo du nicht weitergekommen bist. Das Ende der Stunde ist ein Entscheidungspunkt, nicht nur ein Stoppzeichen. Wenn ein Befund bedeutend erscheint, frag, ob es jemanden interessiert. Wenn ja, verbring noch eine Stunde damit. Wenn niemand darauf reagiert hätte, hast du diese Stunde gespart.
Wie kann ein einzelner Tester nützlich sein, wenn es unmöglich ist, alles zu testen?
Indem man das Testen nach vorne verlegt und Priorisierung als Kernkompetenz akzeptiert. Ein Eingabefeld mit 100 Zeichen enthält mehr Kombinationen, als es Sekunden im Alter des Universums gibt, daher ist Überdeckung niemals das Ziel. Praktische Schritte: Negative Fälle in „Three Amigos“-Sessions im Refinement ansprechen, Risikomindmaps nach Schichten wie API, UI, Performance und IT-Sicherheit erstellen und in Paaren arbeiten, mit einem vereinbarten Limit.
Wie viel Dokumentation braucht eine explorative Sitzung eigentlich?
Passe sie an deinen Kontext an, nicht an einen Audit-Trail wie im Bankwesen. Die Gewohnheit, Screenshots und Belege zu sammeln, stammt aus der Finanzbranche. In einem agilen, unregulierten Umfeld können die aufgedeckten Fehlerzustände, die geführten Gespräche und das gewonnene Wissen das bleibende Ergebnis sein: ein paar Zeilen in einem Chat-Kanal, eine Wiki-Seite, ein Ticket. Eine praktikable Routine sind kurze handschriftliche Notizen, die im Nachhinein zu einem kurzen Bericht zusammengefasst werden, in dem festgehalten wird, was geprüft wurde, was in Ordnung war und was Fragen aufwirft.
Kann explorativer Test als Regressionssuite dienen?
Nein. Es ist von Natur aus ein schlechter Mechanismus für wiederholbare Prüfungen. Stell dir eine Linie vom Unbekannten zum Bekannten vor: Die Erkundung findet am unbekannten Ende statt, und alles, was dadurch bekannt wird, wird zu einem Kandidaten für geskriptete oder automatisierte Tests auf Code- oder Feature-Ebene. Einen umfangreichen manuellen Regressionstest als Erkundung durchzuführen, birgt die Gefahr von Abweichungen, da du ihn nie zweimal auf dieselbe Weise durchführen wirst.
Was kannst du tun, wenn die ursprünglichen Anforderungen für ein Live-System nicht mehr vorliegen?
Beim Golden-Master-Testen wird das laufende Produkt als Spezifikation betrachtet: Du schreibst Tests, die bestätigen, dass das System weiterhin das tut, was es gerade tut. Auf Code-Ebene entspricht dies dem Charakterisierungstest, bei dem Entwickler die vorhandene Logik analysieren und ihr Verhalten erfassen, unabhängig von der ursprünglichen Absicht. Die Einschränkung ist klar: Du testest, was das Produkt tut, nicht was es tun sollte. Das aktuelle Verhalten vor unbeabsichtigten Änderungen zu schützen, ist dennoch ein echter Gewinn.
