Exploratives Testen ist ein Testansatz, der verwendet wird, um Informationen über die Qualität von Software zu finden, für die es keine Anforderungen oder erwarteten Ergebnisse gibt. Dabei werden Experimente durchgeführt, um Unbekanntes aufzudecken, wie z.B. IT-Sicherheitslücken, Leistungsgrenzen oder Grenzfälle. Durch einen risikobasierten Rahmen und einen Zeitplan werden die Anstrengungen auf die Bereiche konzentriert, die für das Team wichtig sind, anstatt erschöpfend zu testen.
Das Wichtigste in Kürze
- Exploratives Testen deckt unbekanntes Terrain ab: Es führt Experimente durch, um Informationen zu sammeln, für die es keine Anforderungen oder erwarteten Ergebnisse gibt, und nicht, um ein bekanntes Ergebnis zu bestätigen.
- Durch die Beschränkung der Erkundung auf eine bestimmte Zeit und die anschließende Rücksprache mit dem Team, bevor es weitergeht, werden sowohl endlose Kaninchenlöcher als auch die Arbeit an Fehlerzuständen verhindert, die niemand beheben wird.
- Erschöpfende Tests sind mathematisch unmöglich: Die Zeichenkombinationen für ein einziges 100-Zeichen-Eingabefeld übersteigen die Anzahl der Sekunden, in denen das Universum existiert.
- Befunde aus explorativen Testsitzungen sollten in geskriptete oder automatisierte Tests einfließen, sobald das Verhalten verstanden wurde, denn explorative Tests sind ein schlechter Mechanismus für wiederholbare Regressionstests.
- Golden Master Tests, bei denen erfasst wird, was ein laufendes System tut, und Tests geschrieben werden, die bestätigen, dass es so bleibt, sind eine gültige Strategie, um die Überdeckung von Regressionen nachzurüsten, wenn die ursprünglichen Anforderungen nicht mehr bestehen.
Exploratives Testen bedeutet, Experimente durchzuführen, nicht herumzuklicken
Unter explorativem Testen versteht man das Durchführen von Experimenten, um Informationen zu finden, die helfen, Unbekanntes zu bestätigen oder zu lernen. Es dient einem anderen Zweck als das traditionelle Testen, bei dem du festlegst, was passieren soll, und dann überprüfst, ob es passiert ist.
Die Trennlinie ist das erwartete Ergebnis. Wenn du bereits weißt, was eine Funktion tun soll, kannst du einen Ja-oder-Nein-Test schreiben. Explorative Tests eignen sich für die Momente, in denen du keine Erwartungen und manchmal nicht einmal eine Anforderung hast. Du machst dich auf den Weg, um herauszufinden, was das System tatsächlich tut.
Nimm die Leistung als Beispiel. Wenn du keinen Benchmark hast und nicht weißt, wie sich das System unter Last verhält, führst du Experimente durch, um das herauszufinden. Es geht nicht darum, eine Prüfung zu bestehen oder fehlzuschlagen. Es geht darum, Informationen zu sammeln, anhand derer du später entscheiden kannst, ob das Verhalten akzeptabel ist.
Diese Formulierung korrigiert auch ein häufiges Missverständnis. Exploratives Testen ist nicht dasselbe wie zufälliges Stochern. Callum Akehurst-Ryan beschreibt es als ein Spektrum: am einen Ende die lose Fehlerjagd, bei der Menschen Knöpfe drücken und darauf warten, dass Fehlerzustände herausfallen, am anderen Ende etwas Geplantes und Technisches, einschließlich von KI und Automatisierung unterstützter Durchläufe. Beide Enden sind gültig. Keines von beiden definiert das Ganze.
Warum Teams zur Erkundung greifen, wenn die Dokumentation fehlt
Du erkundest, wenn es nichts gibt, gegen das du testen kannst. Viele Unternehmen haben große Mengen an Software entwickelt, ohne aufzuschreiben, wie gute Software aussieht, sodass die Anforderungen, die du normalerweise prüfen würdest, einfach nicht existieren.
Callum arbeitet als einziger Qualitätsingenieur in seinem Unternehmen neben Softwareentwicklungsingenieuren mit unterschiedlichem Niveau. In diesem Umfeld tauchen immer wieder drei Anwendungen der Erkundung auf.
Die erste ist das Shift-Left. Du untersuchst Entwürfe, User-Stories oder Architekturdokumente, bevor irgendetwas gebaut wird, um nach diskussionswürdigen Risiken zu suchen. Es gibt noch keine Bestehens-/Fehlschlagkriterien, sondern nur eine Jagd nach dem, was schiefgehen könnte.
Der zweite Punkt sind Randfälle. Ingenieure neigen dazu, den besten Weg und die kleinste Anzahl von Tests zu wählen, mit denen sie auskommen können. Die Erkundung des Systems bringt die Fälle ans Licht, an die sie nicht gedacht haben.
Der dritte Punkt ist das Nachrüsten von nicht-funktionalen Anforderungen. IT-Sicherheit, Leistung, Wartbarkeit, Gebrauchstauglichkeit, Zugänglichkeit, Einsatzfähigkeit: Viele Produkte wurden ausgeliefert, ohne dass irgendjemand Schwellenwerte für diese Punkte festgelegt hat. Du erkundest nicht, um eine festgelegte Messlatte zu erfüllen, sondern um dir ein erstes ehrliches Bild zu machen. Der Seitenaufbau ist so schnell, außer hier. Das System verwaltet so viele Benutzer. Diese Schwachstellen gibt es.
Diese Lücke ist strukturell bedingt, nicht zufällig. In den Unternehmen gibt es immer weniger Qualitätsexperten, so dass das Wissen darüber, wie gute Software aussieht, ausgedünnt ist. Architekten, Ingenieure und Produktmanager konzentrieren sich auf die Bereitstellung von Funktionen und vergessen dabei, dass Funktionen nicht die einzige Quelle von Wert sind. Vor allem Start-ups und Scale-ups verzichten absichtlich auf die Dokumentation und überlassen es den Kunden, Probleme durch ihr Feedback aufzudecken. Das ist eine legitime Entscheidung. Wenn ein Qualitätsexperte eintrifft, gibt es nur wenig, gegen das er testen kann, und das Erforschen wird zum Einstieg.
Erst das Risiko abwägen, dann die Uhr stellen
Strukturiere den explorativen Test, indem du ihn nach dem Risiko einteilst und dann einen Zeitrahmen für den Testumfang festlegst. Ohne diese beiden Schritte zieht sich die Erkundung in die Länge. Du könntest alles testen, würdest aber nie fertig werden.
Dieser Ansatz basiert auf dem Buch Explore It! von Elizabeth Hendrickson. Die Logik ist einfach: Entscheide, was für das Team wichtig ist, beschränke deine Tests auf diese Risiken und gib dir ein festes Zeitfenster. Der risikobasierte Umfang sorgt dafür, dass du dich auf das konzentrieren kannst, was wichtig ist. Der Zeitrahmen verhindert, dass du dich stundenlang mit einem Problem beschäftigst.
Callum fügt eine dritte Disziplin hinzu: Halte dein Ego da raus. Suche nach Informationen, die dem Team helfen, und nicht nach dem Beweis, dass du Recht hast oder ein guter Tester bist. Er bringt die Falle anschaulich auf den Punkt:
Es mag zwar sehr aufregend sein, dass das System nicht funktioniert, wenn Venus und Merkur in einer Linie stehen und du Löwe bist und Limonengelatine isst, aber das ist ein so seltsamer Sonderfall, dass ihn niemand jemals beheben wird.
Die drei Fragen, die eine Sitzung bestimmen, sind: Was ist uns wichtig? Was ist für uns als Team wichtig? Was würden wir tatsächlich reparieren? Die Antworten bestimmen deinen Spielplatz. Auf dieser Spielwiese findest du nützliche Informationen und keinen Lärm.
Der Kontrast zu einem nicht überschaubaren Bug Bash zeigt, wie wichtig Tiefe ist. Wenn Menschen wahllos herumklicken, finden sie das, was sie persönlich nicht mögen, oder die oberflächlichen Probleme, die an der Oberfläche liegen. Sie gehen in die Breite und bleiben oberflächlich. Ein enger Rahmen und eine feste Stunde bringen dich in die Tiefe, wo sich die wichtigen Themen eher verstecken.
Wie eine Sitzung endet: die Timebox als Entscheidungspunkt
Das Ende der Timebox ist nicht nur ein Stoppsignal, sondern auch ein Gesprächsauslöser. Wenn die Stunde um ist, gehst du zurück zum Team und berichtest, was du befunden hast und wo du stecken geblieben bist.
Wenn du auf etwas gestoßen bist, das dir wichtig erscheint, fragst du das Team, ob es dir wichtig ist. Wenn ja, verbringst du eine weitere Stunde damit. Wenn die Antwort lautet, dass es niemanden interessiert hätte, hast du diese Stunde gespart und kannst weitermachen. Die Abgrenzung erzwingt eine Prioritätensetzung, die die Erkundung ehrlich macht.
Dieser Rhythmus schützt dich auch vor der gegenteiligen Fehlerwirkung: Du bleibst an etwas hängen, das niemanden interessiert, und verbringst allein dafür zwei Stunden. Der Spielplatz hält dich bei dem, was wichtig ist, und die Uhr bringt dich immer wieder zum Team zurück, um die Grenzen zu überprüfen.
Du kannst nicht alles testen, also geht es darum, Prioritäten zu setzen
Erschöpfende Tests sind unmöglich, und das zu akzeptieren, macht die Effektivität von Exploration aus. Die Mathematik ist unerbittlich. Ein einziges Feld mit hundert Zeichen enthält mit allen verfügbaren Zeichensätzen und Regexen mehr Kombinationen, als es in der Geschichte des Universums je gegeben hat. Ein Feld. Wenn jeder Test eine Sekunde dauern würde, hätte das Universum nicht lange genug gedauert.
Die Frage lautet also nie: “Wie kann ich alles abdecken?” Sie lautet: “Was ist wichtig und was würden wir reparieren?” Das Setzen von Prioritäten ist kein Kompromiss, der durch begrenzte Zeit erzwungen wird. Sie ist die Kernkompetenz.
Für einen Tester, der allein unterwegs ist, ist ohnehin kein Platz für drei Wochen Erkundungstouren mit offenem Ausgang. Callum verlegt das Testen stattdessen auf einen früheren Zeitpunkt, um Fehler zu verhindern, bevor sie auftreten, und um die Ingenieure dazu zu bringen, über Risiken nachzudenken. Ein paar praktische Maßnahmen haben das meiste Gewicht:
- Drei Amigos-Sitzungen beim Story Refinement, bei denen du negative Fälle ansprichst und fragst, was mit der Leistung oder einer Randbedingung passiert. So können die Ingenieure Probleme beheben, bevor der Code existiert.
- Risiko-Mindmaps für ein bestehendes Ticket, bei denen das Risiko nach Schichten aufgeschlüsselt wird. Auf der API-Ebene: Was könnte schief gehen? Auf der UI-Ebene, was schief gehen könnte. Leistung und IT-Sicherheit bekommen jeweils einen eigenen Zweig.
- Paarung für die eigentliche Erkundung, die im Voraus vereinbart wurde: Wir werden insgesamt drei Stunden für diese drei Bereiche aufwenden, nicht mehr.
Die gemeinsame Regel für alle: Versuche nicht, alles auf einmal perfekt zu machen. Gut genug sieht oft so aus, dass wir uns eine Stunde Zeit nehmen und dann eine Entscheidung treffen, die auf den Ergebnissen basiert.
Dokumentiere für deinen Kontext, nicht für ein Audit, das du nicht hast
Passe deine Dokumentation an die Umgebung an, nicht an einen Audit-Trail auf Bankniveau. Ein Großteil der Dokumentationskultur im Testen ist aus dem Finanzwesen hervorgegangen, weshalb man davon ausgeht, dass jeder Test Screenshots und Belege braucht. Für viele Teams ist diese Annahme jedoch falsch.
In einem agilen, ungeregelten Umfeld können die aufgedeckten Fehlerzustände, die geführten Gespräche und die Erkenntnisse, die das Team gewonnen hat, das bleibende Ergebnis der Erkundung sein. Ein paar Zeilen in einem Slack-Kanal, eine Wiki-Seite, ein neues Ticket oder einfach die darauf folgende Code-Änderung: All das kann der Beleg sein.
Callums eigene Gewohnheit ist leicht. Er nimmt einen Block und einen Stift mit, macht sich unterwegs kurze Notizen und fasst sie nach einer Stunde in einem kurzen Bericht zusammen. In dem Bericht steht, was er sich angesehen hat, was gut war, wozu er Fragen hat und was ein Problem sein könnte. Dieser Bericht dient als Grundlage für das Gespräch mit dem Team, und alles, was sich umsetzen lässt, wird zu einem Ticket.
Es gibt auch andere Formate, je nachdem, wie ihr zusammenarbeitet und was ihr braucht. Manche Tester nehmen Videos auf und schauen sie sich an. Wenn sich zwei Leute zusammentun, steuert einer den Bildschirm, während der andere schreibt, und sie gestalten die Notizen anschließend zu etwas Sinnvollem.
Die Erkundung füttert deine automatisierten Tests, sie ersetzt sie nicht
Explorative Tests sind eine schlechte Methode, um wiederholbare Tests durchzuführen, und das ist gewollt. Stell dir eine Linie vor, die vom Bekannten zum Unbekannten führt. Du erkundest am unbekannten Ende. Was du dort lernst, bewegt sich in Richtung des bekannten Endes, und alles, was bekannt ist, ist ein Kandidat für geskriptete oder automatisierte Tests.
Um zu vermeiden, dass du jede Woche dasselbe Thema wiederholst, musst du das, was du gelernt hast, in automatisierte Prüfungen umwandeln, und zwar auf Code- oder Feature-Ebene, wo immer es wichtig ist. Das ist deine Regressionssuite. Wenn du einen großen manuellen Regressionsdurchlauf durchführst, lädt das zum Abdriften ein, weil du es nicht zweimal auf die gleiche Weise machen wirst.
Das ist auch der Punkt, an dem Teams die Technik missbrauchen. Manche verzichten ganz auf Planung und Automatisierung und nennen das Ergebnis exploratives Testen: keine Skripte, keine Dokumentation, nur zwei Wochen am Ende eines Monats, um zu sehen, was passiert. Das ist zwar ein Ansatz, aber keine solide Teststrategie. Die Erkundung gehört zum Unbekannten. Sie bereitet das anschließende strukturierte Testen vor, anstatt es zu ersetzen.
Wo KI passt: das Unbekannte ausspionieren und es dann festhalten
KI-Werkzeuge erweitern die Erkundung, indem sie die Funktionen einer Anwendung abbilden und in wiederholbare Tests umsetzen. Das Feld ist neu, und niemand sollte behaupten, es zu beherrschen, aber die Richtung ist klar.
Playwright lässt sich mit Sprachmodellen integrieren, und das Muster funktioniert wie eine funktionale Version eines IT-Sicherheitsspiders wie OWASP ZAP. Du wendest das Tool auf eine Website an, lässt es diese erkunden und crawlen, identifizierst die üblichen Arbeitsabläufe und dokumentierst sie. Anhand dieser Dokumentation kannst du die Automatisierung nachrüsten und sie dann so oft wiederholen, wie du willst. Du wirst gute und schlechte Ergebnisse erzielen, aber es ist ein brauchbarer Ausgangspunkt.
Dahinter verbirgt sich eine bestimmte Disziplin, die noch vor den KI-Werkzeugen entwickelt wurde. das Golden Master Testing geht davon aus, dass das laufende Produkt die Spezifikation ist. Du hast die Anforderungen nicht mehr, die Tickets sind weg, der Product Owner hat keine Zeit, die Absicht zu rekonstruieren, also schreibst du Tests, die bestätigen, was das System gerade tut. Softwareingenieure machen das Äquivalent auf der Code-Ebene, das sogenannte Charakterisierungstesten: Sie lesen die vorhandene Logik und schreiben Tests, die das aktuelle Verhalten erfassen, unabhängig davon, was ursprünglich beabsichtigt war.
Die ehrliche Einschränkung: Du testest, was das Produkt tut, und nicht, was es tun sollte. Das ist schwächer als das Testen gegen die Absicht. Trotzdem hat es einen echten Wert. Das aktuelle Verhalten zu erfassen und vor unbeabsichtigten Änderungen zu schützen, ist eine echte Verbesserung, und die KI-gestützte Erkundung ist ein schneller Weg, um dieses erste Bild zu erstellen.
