Exploratives Testen: Charter, Sessions und Vorlagen

Exploratives Testen ist ein Ansatz im Softwaretest, bei dem du gleichzeitig das Produkt kennenlernst, Tests entwirfst und sie ausführst, ohne ein vorab geschriebenes Skript. Du arbeitest in Sessions mit fester Timebox (meist 45 bis 90 Minuten), geleitet von einer Charter, hältst unterwegs Notizen und Screenshots fest und wertest danach alles in einem Debriefing aus, damit aus deinen Funden Bugs und neue Testideen werden.

Die Definition ist der einfache Teil. Was eine Session ihre Stunde wert macht, sind die Belege: eine klare Charter, lesbare Notizen und Screenshots, mit denen Entwickler sofort etwas anfangen können. Weiter unten findest du eine Formel für Charters, ein Session-Sheet zum Kopieren, einen Ablauf zum Aufnehmen und Schwärzen und eine durchgespielte 60-Minuten-Session.

Was ist exploratives Testen?

Exploratives Testen im Softwaretest geht auf Cem Kaner zurück, der den Begriff 1984 prägte. James Bach beschrieb es später als Testen, bei dem du laufend Dinge lernst, die verändern, was du als Nächstes testest. Das ISTQB-Glossar definiert es formal: Tester entwerfen und führen Tests spontan aus, auf Basis dessen, was sie wissen, was sie sehen und was frühere Tests gezeigt haben.

Ein kurzes Beispiel: Eine Stunde vor dem Code Freeze probiert eine Testerin ein neues Einladungsfeature mit einem abgelaufenen Link, einer doppelten E-Mail-Adresse und einem schnellen Doppelklick auf „Send“ aus. Der Doppelklick erzeugt zwei Einladungen. Diesen Test gab es erst, als die Testerin sah, dass der Button nach dem ersten Klick aktiv blieb.

Die Grundprinzipien und warum Teams darauf setzen:

• Urteilsvermögen der Tester statt Skripte. Jeder Test entsteht aus dem, was der letzte gezeigt hat.
• Freiheit innerhalb eines Rahmens. Eine Charter legt die Mission fest, ein Timer die Grenze.
• Schnelles Feedback. Bugs landen noch am selben Tag bei den Entwicklern, mit Schritten und Screenshots.
• Findet, was Skripte übersehen. Interaktionsbugs, seltsame Abfolgen, Edge Cases und Lücken bei Berechtigungen, für die niemand einen Testfall geschrieben hat.
• Belege machen es greifbar. Notizen und Aufnahmen machen eine Session leicht nachprüfbar.

Explorative vs. skriptbasierte vs. Ad-hoc- vs. Regressionstests

Diese vier werden ständig verwechselt. So unterscheiden sie sich.

Die entscheidende Grenze verläuft zwischen explorativem Testen und Ad-hoc-Testen. Ad-hoc-Tests hinterlassen keine Aufzeichnungen, also kann niemand sagen, was abgedeckt wurde. Exploratives Testen hat eine Charter, eine Timebox, Notizen und ein Debriefing. Deshalb kannst du es planen, prüfen und wiederholen.

Es ergänzt außerdem die Automatisierung. Visual Regression Testing erkennt Pixeländerungen gegenüber einer Baseline. Eine explorative Session findet das Verhalten, an dessen Prüfung niemand gedacht hat.

Zwei verwandte Praktiken sind eng damit verbunden. Beim Abnahmetest (UAT) bestätigen Fachanwender, dass das Produkt ihre Anforderungen erfüllt. Explorative Sessions laufen oft vorher, damit die Fachanwender nicht über offensichtliche Bugs stolpern. Ein Bug Bash ist die Variante als Team-Event: Viele Leute erkunden gleichzeitig, direkt vor einem Release.

Wann du exploratives Testen einsetzt (und wann nicht)

Setz es ein, wenn Lernen genauso wichtig ist wie Prüfen:

• Neue oder sich ändernde Features, bei denen die Spezifikation noch in Bewegung ist und es noch keine Testfälle gibt.
• Risiko-Durchgänge vor dem Release für die Abläufe, die am meisten wehtun würden, wenn sie kaputtgehen.
• Direkt nach einem Bugfix, um den Bereich rund um den Fix abzuklopfen, nicht nur den Fix selbst.
• Beim Onboarding neuer Tester, die mit einer Charter schneller lernen als mit einem Testplan.

Exploratives Testen in agilen Teams folgt oft einem einfachen Rhythmus: eine oder zwei Sessions pro Story, bevor sie auf Done wandert.

Verlass dich nicht allein darauf, wenn Compliance oder ein Audit wiederholbare, skriptbasierte Nachweise der Abdeckung verlangt. Nutz dort skriptbasierte Testfälle und ergänze Sessions obendrauf.

Es hat auch Grenzen. Die Ergebnisse hängen vom Können der Tester ab, und Abdeckung lässt sich im Nachhinein schwer belegen. Gute Notizen und Belege machen beide Probleme kleiner. Deshalb bekommt die Dokumentation unten einen eigenen Abschnitt.

Arten des explorativen Testens

Die meisten Teams mischen diese fünf Stile:

• Freestyle: keine Charter, ein kurzer Blick auf einen frischen Build. Halte es kurz, denn es liegt nah am Ad-hoc-Testen.
• Szenariobasiert: eine echte User Journey von Anfang bis Ende durchspielen, etwa „ein neuer Admin lädt ein Team ein“.
• Strategiebasiert: mit Heuristiken und Techniken steuern, etwa Grenzwerten, SFDIPOT oder einer Risikoliste.
• Sessionbasiert (SBTM): Session-Based Test Management ergänzt eine Charter, eine Timebox, ein Session-Sheet und ein Debriefing. Dieser Guide nutzt diesen Stil.
• Pair oder Mob: Zwei oder mehr Personen teilen sich einen Bildschirm. Eine Person steuert, eine andere schreibt mit und fragt „was wäre, wenn?“

Ein Bug Bash ist das einmalige Event mit vielen Beteiligten, das auf denselben Ideen aufbaut.

So führst du eine explorative Test-Session durch

Fünf Schritte bringen dich von der leeren Seite zum Debriefing.

Schritt 1: Schreib eine Charter

Nutz das Format von Elisabeth Hendrickson aus ihrem Buch Explore It!: Erkunde [Ziel] mit [Ressourcen], um [Informationen] zu entdecken. Im englischen Original heißt das „Explore [target] with [resources] to discover [information]“. Das Ziel legt den Umfang fest. Die Ressourcen sagen, womit du das Ziel unter Druck setzt, und die Informationen beschreiben, wie ein gutes Ergebnis aussieht.

Drei gute Beispiele für eine Test-Charter:

• Erkunde den Ablauf für Team-Einladungen mit abgelaufenen Links, doppelten E-Mail-Adressen und Rollenwechseln, um Fehler bei Berechtigungen und Benachrichtigungen zu entdecken.
• Erkunde den CSV-Import mit Dateien von 10.000 Zeilen, gemischten Zeichenkodierungen und fehlenden Kopfzeilen, um Datenverlust und unklare Fehlermeldungen zu entdecken.
• Erkunde die Filter der Such-API mit leeren, riesigen und widersprüchlichen Werten, um falsche Ergebnisse und Serverfehler zu entdecken.

Zu vage: „Erkunde die App.“ Das hat kein Ziel und keine Methode, also driftet der Tester zurück auf den Happy Path, den Skripte ohnehin abdecken.

Schritt 2: Bereite die Session vor

Nimm dir fünf Minuten für die Vorbereitung, bevor die Uhr läuft:

• Build und Umgebung: Notier die Version und wo sie läuft (Staging, eine Review-App, ein lokaler Build).
• Testdaten: Nutz Fake-Accounts und vorbefüllte Seed-Daten, nie echte Kundendaten. Mit Fake-Daten kannst du Screenshots gefahrlos teilen.
• Aufnahmetool bereit: Kenne deine Tastenkürzel für Screenshots und Aufnahmen.
• Timer läuft: Eine Timebox funktioniert nur, wenn dir etwas sagt, dass sie vorbei ist.

Der kostenlose Timer für Bildschirmaufnahmen kann die Zeit für dich im Blick behalten. Der Countdown-Modus liefert dir die Timebox: Gib eigene 60 oder 90 Minuten ein, denn die Voreinstellungen enden bei 30. Der Stoppuhr-Modus bietet Rundenzeiten, die du als Zeitstempel für Notizen nutzen kannst. Die beiden Modi laufen aber nicht gleichzeitig, also entscheide dich für einen.

Schritt 3: Erkunde mit Heuristiken

Heuristiken halten dich in Bewegung, wenn dir die Ideen ausgehen:

• SFDIPOT: James Bachs Produkt-Checkliste aus Structure, Function, Data, Interfaces, Platform, Operations und Time (Struktur, Funktion, Daten, Schnittstellen, Plattform, Betrieb und Zeit).
• Grenzen: null, eins, das Maximum, das Maximum plus eins, leere Strings und sehr lange Strings.
• CRUD: dasselbe Objekt anlegen, lesen, ändern und löschen, dann alles in falscher Reihenfolge probieren.
• Unterbrechungen: mitten im Ablauf neu laden, das Netzwerk trennen, einen zweiten Tab öffnen, den Login ablaufen lassen.
• Den Daten folgen: einen Datensatz durch jeden Bildschirm, jede E-Mail und jeden Export verfolgen, den er berührt.
• Touren: das Produkt mit einem Thema durchgehen, etwa den Bereich mit den meisten früheren Bugs.

Schritt 4: Mach dir unterwegs Notizen

Führ ein einfaches Textprotokoll mit einem Zeitstempel und einem Tag pro Zeile. Die Tags bleiben auf Englisch, damit sie zu den Vorlagen unten passen:

• SETUP: Build, Daten und Tools, die du vorbereitet hast, bevor die Uhr läuft.
• BUG: Verhalten, das falsch ist.
• ISSUE: etwas, das das Testen blockiert, oder ein Bedenken, das nicht eindeutig ein Bug ist.
• QUESTION: eine Frage, die nur ein PM oder ein Entwickler beantworten kann.
• IDEA: ein Test oder eine ganze Charter für später.
• NOTE: was du abgedeckt und was du gesehen hast.

Die Aufnahmeregel: ein Screenshot pro Beobachtung, aufgenommen in dem Moment, in dem du sie siehst. Schreib den Dateinamen in die Protokollzeile, damit du ihn im Debriefing wiederfindest.

Schritt 5: Debriefing

Mach das Debriefing noch am selben Tag. Jonathan Bachs Paper Session-Based Test Management liefert dafür eine fünfteilige Agenda namens PROOF:

• Past (Vergangenheit): Was ist während der Session passiert?
• Results (Ergebnisse): Was hast du erreicht?
• Obstacles (Hindernisse): Was hat gutes Testen behindert?
• Outlook (Ausblick): Was ist noch zu tun?
• Feelings (Gefühl): Welches Gefühl hat der Tester bei diesem Bereich?

Halte danach die TBS-Aufteilung fest (Test, Bug, Setup): den Anteil der Zeit für Testdesign und Ausführung, für Bug-Analyse und Reporting und für das Session-Setup. Wenn die halbe Session für Bugs draufging, braucht der Bereich mehr Sessions.

Das ausgefüllte Session-Sheet ist dein Bericht zum explorativen Testen. Jeder Bug wird zu einem vollständigen Bug-Report, jede Frage geht an ihren Owner, und jede IDEA wird zu einer neuen Charter.

Von den Machern dieser Seite

Genug von langweiligen Screenshots? Probier ScreenSnap Pro.

Schöne Hintergründe, professionelle Anmerkungen, GIF-Aufnahme und sofortiges Teilen in der Cloud, alles in einer App. Einmal 34 $ zahlen, für immer besitzen.

Preis und Funktionen ansehen

So dokumentierst du exploratives Testen

Gute Belege lassen Entwickler einen Bug ohne Call reproduzieren und zeigen deiner Teamleitung, was du abgedeckt hast. Dieser Ablauf funktioniert mit jedem Aufnahmetool.

Was du aufnimmst

Wähl die Art des Belegs passend zu dem, was du gesehen hast:

Anleitungen: GIF-Aufnahme auf dem Mac und unter Windows, Bildschirmaufnahme auf dem MacBook und unter Windows sowie Text aus einem Screenshot kopieren auf dem Mac oder mit OCR-Software unter Windows.

Für lange Seiten haben die Chrome DevTools einen Befehl für Screenshots in voller Größe. Mehr dazu in den Anleitungen zu Ganzseiten-Screenshots auf dem Mac und unter Windows.

Jedes schnelle Aufnahmetool funktioniert. ScreenSnap Pro deckt zum Beispiel den Großteil der Tabelle in einer App ab: ein Tastenkürzel für Bereichsaufnahmen, GIF- und Bildschirmaufnahme mit Mikrofon, OCR, Anpinnen und 17 Annotationswerkzeuge, darunter ein Zähler und ein deckend gefülltes Rechteck.

Eine Einschränkung: Die Funktion Website Capture rendert eine URL auf einem Server und eignet sich deshalb nur für öffentliche Seiten. Für Seiten hinter einem Login, auf localhost oder nur im VPN nutzt du die Bereichsaufnahme oder die DevTools.

Pinne die Spezifikation beim Testen an

Mach vor der Session einen Screenshot des Mockups oder der Akzeptanzkriterien und pinne ihn an, damit er über der zu testenden App schwebt. Du vergleichst direkt an Ort und Stelle, statt zwischen Fenstern zu wechseln, und bemerkst so auch kleine Abweichungen. So hältst du ein Fenster auf dem Mac immer im Vordergrund und unter Windows immer im Vordergrund.

Annotiere so, dass Entwickler reproduzieren können

Nimm einen Fund pro Bild und ergänze nur, was ein Entwickler braucht:

• Nummerierte Zähler an jedem Reproduktionsschritt, passend zu den nummerierten Schritten im Ticket.
• Ein Pfeil auf genau das Bedienelement oder den Text, der falsch ist.
• Eine Hervorhebung oder ein Rahmen um den fehlerhaften Zustand.
• Eine kurze Textnotiz mit erwartet vs. tatsächlich in weniger als zehn Wörtern.

Schritt-für-Schritt-Anleitungen: Screenshots auf dem Mac annotieren und Screenshots unter Windows bearbeiten.

Schwärze vor dem Teilen

Datenschutz-Bugs sind häufige Funde, und oft enthält der Screenshot genau die geleakten Daten. Bevor du etwas anhängst:

• Secrets bekommen einen deckenden, undurchsichtigen Kasten: API-Tokens, Session-IDs, Einladungslinks und Passwörter. Unschärfe und Verpixelung lassen sich umkehren, wie dieser Guide zum Schwärzen von Text erklärt.
• Mach nur unkritische Details unscharf oder verpixle sie, etwa Fake-Testnamen, Avatare und Test-E-Mails. Der Guide zum Unscharfmachen oder Verpixeln auf dem Mac zeigt beides.
• Fake-Daten dürfen als Beleg sichtbar bleiben. Wenn echte Kundendaten auftauchen, deck sie mit einem Kasten ab und beschreib sie in Worten.
• Auch HAR-Dateien enthalten Secrets. Darin können Cookies, Auth-Header und Tokens in Request-URLs und Request-Bodies stecken. Nutz nach Möglichkeit einen bereinigten Export (die Chrome DevTools lassen dabei Cookie- und Auth-Header weg) und prüf danach URLs und Bodies auf Tokens.
• Rotier jedes echte Secret, das in einer Aufnahme auftaucht. Das Abdecken im Bild macht das Leak nicht rückgängig.

Mach aus Funden Bug-Reports und Testfälle

Jede BUG-Zeile wird zu einem Ticket mit dem annotierten Bild und den Reproduktionsschritten. Bei falschem Text oder falscher Ausgabe fügst du erwarteten und tatsächlichen Text in ein Tool zum Textvergleich ein und hängst den Diff an. Sobald ein Bug behoben ist, machst du daraus einen Regressionstestfall.

Teile den Session-Bericht

Häng die Bild- und GIF-Dateien direkt an das Jira-Issue, den Testlauf oder das GitHub-Issue. Atlassian erklärt, wie du einem Jira-Arbeitselement einen Anhang hinzufügst, GitHub Docs beschreibt das Anhängen von Dateien, und es gibt eine komplette Anleitung zu Screenshots in Jira.

Ein schneller Share-Link ist für das Debriefing in Slack in Ordnung, aber er ist nicht die Dokumentation. Share-Links sind zum schnellen Teilen da, und Uploads können mit der Zeit entfernt werden. Die angehängten Dateien sind deshalb der eigentliche Beleg.

Wenn ein Fund die Benutzerdokumentation verändert, sieh dir den Guide zu Screenshots in technischer Dokumentation an.

Vorlagen für explorative Tests: Charter und Session-Sheet

Kopier sie in eine Markdown-Datei, ein Wiki oder dein Testtool. Sie folgen dem SBTM-Session-Sheet: Charter, Tester, Startzeit, Aufgabenverteilung, Daten, Notizen, Issues und Bugs.

Vorlage für eine explorative Test-Charter

## Charter
Erkunde: [Zielbereich oder Feature]
Mit: [Ressourcen, Daten, Techniken oder Heuristiken]
Um zu entdecken: [das Risiko oder die Information, um die es dir geht]

Timebox: 60 Min.
Build / Umgebung:
Im Scope:
Nicht im Scope:
Erste Testideen:
- 
- 

Vorlage für das Session-Sheet

# Session-Sheet

## Charter
Erkunde ... mit ..., um ... zu entdecken.

## Session
- Tester:
- Build:
- Umgebung:
- Start: JJJJ-MM-TT HH:MM
- Dauer: 60 Min. (kurz 45 / normal 90 / lang 120)

## Aufgabenverteilung (TBS)
- Testdesign und Ausführung: __%
- Bug-Analyse und Reporting: __%
- Session-Setup: __%
- Charter / Opportunity: __% / __%

## Genutzte Daten und Dateien
- 

## Notizprotokoll
HH:MM  TAG       Notiz                                 Beleg
10:00  SETUP
10:05  NOTE

## Bugs
- BUG-1:  (Beleg: 01-name.png)

## Issues
- 

## Fragen
- Q-1:  (Owner: )

## Belegdateien
- 01-name.png

Ausgefülltes Beispiel

# Session-Sheet: Einladungsablauf

## Charter
Erkunde den Ablauf für Team-Einladungen mit abgelaufenen Links,
doppelten E-Mails und Rollenwechseln, um Fehler bei Berechtigungen
und Benachrichtigungen zu entdecken.

## Session
- Tester: Jane Doe (jane@example.com)
- Build: 4.18.0-rc2
- Umgebung: Staging, vorbefüllter Workspace qa-invite-01
- Start: 2026-10-05 10:00
- Dauer: 60 Min.

## Aufgabenverteilung (TBS)
- Testdesign und Ausführung: 60%
- Bug-Analyse und Reporting: 30%
- Session-Setup: 10%
- Charter / Opportunity: 85% / 15%

## Genutzte Daten und Dateien
- admin@example.com, viewer@example.com (fake), 8 Tage alter Link

## Notizprotokoll
HH:MM  TAG       Notiz                                                       Beleg
10:00  SETUP     Workspace qa-invite-01 befüllt, admin@example.com, viewer@example.com
10:06  NOTE      Einladungsdialog nimmt bis zu 20 E-Mails, per Komma oder neuer Zeile
10:12  BUG       Doppelklick auf Send erzeugt 2 Einladungen für eine E-Mail  01-double-send.gif
10:19  NOTE      8 Tage alter Link zeigt generische 404, kein erneutes Senden möglich
10:24  ISSUE     Rollenauswahl springt nach Validierungsfehler auf Viewer zurück
10:31  BUG       "Already invited"-Toast zeigt fremdes Workspace-Mitglied    02-toast-leak.png
10:38  QUESTION  Angepinnte Spec AC-2 will eine Seite zum erneuten Senden. In diesem Release?
10:44  IDEA      Neue Charter: Einladungen auf Domains mit SSO-Pflicht
10:51  BUG       Herabgestufter Viewer öffnet weiterhin /settings/admin      03-admin-url.png
10:56  QUESTION  Wird die Link-Gültigkeit von 7 Tagen pro Workspace eingestellt?
11:00  NOTE      Timebox vorbei: 3 Bugs, 1 Issue, 2 Fragen, 1 neue Charter

## Bugs
- BUG-1: Doppelklick auf Send erzeugt 2 Einladungen (01-double-send.gif)
- BUG-2: "Already invited"-Toast zeigt Mitglied eines anderen Workspaces (02-toast-leak.png)
- BUG-3: Herabgestufter Viewer öffnet weiterhin /settings/admin (03-admin-url.png)

## Issues
- Rollenauswahl springt nach einem Validierungsfehler auf Viewer zurück

## Fragen
- Q-1: Ist die Seite für abgelaufene Links aus AC-2 in diesem Release? (Owner: PM)
- Q-2: Wird die Link-Gültigkeit von 7 Tagen pro Workspace eingestellt? (Owner: Dev Lead)

## Belegdateien
- 01-double-send.gif
- 02-toast-leak.png
- 03-admin-url.png

Die Nummern entsprechen dem Sheet: (1) die Charter, (2) die Session-Details, (3) die TBS-Aufteilung, (4) das getaggte Notizprotokoll und (5) Bugs, Fragen und Belegdateien.

Beispiel für exploratives Testen: eine 60-Minuten-Session im Detail

Das ist die Session hinter dem ausgefüllten Sheet, mit der Charter zum Einladungsablauf von oben. Der Zeitplan:

1. 10:00 bis 10:05: Setup mit einem vorbefüllten Workspace und zwei Fake-Accounts.
2. 10:05 bis 10:20: doppelte E-Mails und schnelle Klicks. BUG-1 gefunden.
3. 10:20 bis 10:40: abgelaufene Links und „Already invited“-Pfade über zwei Workspaces hinweg. BUG-2 gefunden und Q-1 gestellt.
4. 10:40 bis 10:55: Rollenwechsel zwischen Admin, Editor und Viewer. BUG-3 gefunden.
5. 10:55 bis 11:00: Notizen aufgeräumt und eine neue Charter geschrieben.

Die drei Bugs:

• BUG-1: Ein Doppelklick auf „Send“ erzeugt zwei Einladungen für eine E-Mail-Adresse (inv-2231 und inv-2232). Beleg: das kurze GIF unten.
• BUG-2: Der „Already invited“-Toast nennt den Absender, auch wenn diese Person zu einem anderen Workspace gehört. Damit leakt eine E-Mail-Adresse über Mandantengrenzen hinweg. Beleg: der annotierte Screenshot oben.
• BUG-3: Nachdem ein Admin einen User zum Viewer herabgestuft hat, kann dieser User /settings/admin weiterhin per URL öffnen, bis er sich neu anmeldet.

Die zwei Fragen: Q-1 stammt aus der angepinnten Spezifikation, die bei abgelaufenen Links eine Seite zum erneuten Senden vorsieht, während der Build eine 404 zeigt. Der PM muss bestätigen, dass diese Story Teil dieses Releases ist. Q-2 fragt, ob die Gültigkeit der Links pro Workspace eingestellt wird.

Der BUG-2-Screenshot stammt von einem Mac und das BUG-1-GIF von Windows, aber die Regeln sind dieselben: Fake-Daten, ein Fund pro Datei, Secrets mit einem Kasten abgedeckt.

Tools für exploratives Testen

Du brauchst keine spezielle Suite:

• Eingebaute Aufnahme: Auf dem Mac nimmt Shift + Command + 4 einen Bereich auf, und Shift + Command + 5 öffnet die Symbolleiste für Screenshots und Bildschirmaufnahmen (Apple Support). Unter Windows öffnet Win + Shift + S das Snipping Tool (Microsoft Support). Beide sind kostenlos.
• Browser-DevTools: Konsole, Netzwerk-Tab, Geräteemulation und Ganzseiten-Screenshots.
• Testmanagement: TestRail und Xray bieten beide Session-Vorlagen oder Apps, die Charters neben skriptbasierten Testläufen speichern.
• Notiztools: Rapid Reporter, ein kleines Notiztool speziell für SBTM, oder eine einfache Markdown-Datei mit der Vorlage oben.
• Eine Ebene zum Aufnehmen und Annotieren: Hier sparst du pro Fund die meiste Zeit.

Wenn du jeden Tag Belege annotierst, bündelt ScreenSnap Pro Screenshots, GIF- und Bildschirmaufnahmen, OCR, Anpinnen und Annotation hinter einem Satz Tastenkürzel. Es kostet einmalig 34 $: 1 Lizenz für 2 Computer (2 Aktivierungen, Mac oder Windows), praktisch, wenn du auf beiden Plattformen testest. Zu den Preisen.

Häufig gestellte Fragen

Was ist exploratives Testen?

Exploratives Testen heißt, das Produkt kennenzulernen, Tests zu entwerfen und sie gleichzeitig auszuführen, ohne Skript. Tester arbeiten in Sessions mit fester Timebox, geleitet von einer Charter, machen Notizen und Screenshots und halten danach ein Debriefing. So finden sie Bugs, die Skripte übersehen, etwa seltsame Abfolgen und Lücken bei Berechtigungen.

Was ist der Unterschied zwischen explorativem Testen und Regressionstests?

Regressionstests prüfen, ob Features, die vorher funktioniert haben, nach einer Änderung noch funktionieren, meist indem dieselbe Suite erneut läuft. Exploratives Testen sucht nach Problemen, für die noch niemand einen Test geschrieben hat. Nutz beides: Bugs, die du beim Erkunden findest, werden nach dem Fix zu neuen Regressionstestfällen.

Was ist der Unterschied zwischen Ad-hoc-Testen und explorativem Testen?

Beide kommen ohne Skript aus, aber Ad-hoc-Testen ist informell: Jemand klickt ohne Plan und ohne Aufzeichnung herum. Exploratives Testen ergänzt eine Charter, eine Timebox, getaggte Notizen, Screenshots und ein Debriefing. Diese Struktur macht die Ergebnisse leicht nachprüfbar und wiederholbar.

Was ist der Unterschied zwischen funktionalem Testen und explorativem Testen?

Beim funktionalen Testen geht es darum, was du testest: ob Features den Anforderungen entsprechen. Beim explorativen Testen geht es darum, wie du testest: Du entwirfst Tests spontan, statt einem Skript zu folgen. Beides überschneidet sich oft, und eine explorative Session kann auch Usability, Sicherheit oder Geschwindigkeit abdecken.

Kannst du ein Beispiel für exploratives Testen geben?

Eine Testerin bekommt 60 Minuten, um einen Ablauf für Team-Einladungen mit abgelaufenen Links, doppelten E-Mail-Adressen und Rollenwechseln zu erkunden. Sie findet heraus, dass ein Doppelklick zwei Einladungen verschickt, ein Toast eine E-Mail-Adresse aus einem anderen Workspace verrät und ein herabgestufter User seinen Admin-Zugriff behält. Jeder Fund bekommt einen Screenshot oder ein GIF und ein Ticket.

Was sind die vier Arten von Tests?

Gemeint sind meist die vier Teststufen: Unit-Test (Komponententest), Integrationstest, Systemtest und Abnahmetest. Explorative Sessions finden vor allem auf Systemebene statt, an einem lauffähigen Build, oft kurz vor dem Abnahmetest. Entwickler erkunden auch auf Integrationsebene, zum Beispiel indem sie eine API mit ungewöhnlichen Eingaben abklopfen.

Wie lang sollte eine explorative Test-Session sein?

Die meisten Teams planen 45 bis 90 Minuten ein. Das ursprüngliche SBTM-Paper sieht etwa 90 Minuten als normal an, 45 als kurz und zwei Stunden als lang. Unter 30 Minuten reicht die Zeit nicht, um in die Tiefe zu gehen, und nach zwei Stunden lässt die Konzentration nach. Teil große Bereiche deshalb auf mehrere Charters auf.

Lässt sich exploratives Testen automatisieren?

Nicht vollständig: Tools und KI-Assistenten können Charters vorschlagen, Testdaten erzeugen oder deine Notizen gruppieren. Der Kern ist aber ein Mensch, der den nächsten Test auf Basis dessen wählt, was er gerade gesehen hat, und dieses Urteil lässt sich nicht in ein Skript fassen. Automatisieren kannst du die Bugs, die du findest, indem du sie zu Regressionstests machst.

Checkliste zum Abschluss

Geh diese Liste vor und nach jeder Session durch:

• Charter nach dem Muster Erkunde, Mit, Um zu entdecken geschrieben
• Build, Umgebung und Fake-Testdaten notiert
• Timer läuft für 45 bis 90 Minuten
• Getaggte Notizen mit Zeitstempel, ein Screenshot pro Beobachtung
• Secrets mit einem Kasten abgedeckt, unkritische Testdaten unscharf oder verpixelt
• Debriefing mit PROOF und TBS-Aufteilung erledigt
• Bugs mit angehängten Dateien gemeldet, Fragen an die Owner geschickt, neue Charters im Backlog