Testen als Entdeckung – Exploratives Testen im Team

@MichaKutz

Wann Was
09:00 Begrüßung/Agenda
Aufteilen in Teams
Produktauswahl
09:10 Was ist Exploratives Testen?
09:20 Übung: Was wollt ihr über euer Produkt wissen?
09:30 Wie plant man Exploratives Testen? Was sind Chartas?
09:40 Übung: Welche Chartas kann man aus den Fragen machen?
10:10 Wie man Chartas ausfüht
10:25 Übung: Chartas ausführen
11:20 Blitzlich-Retrospektive
11:30 Ende

I would consider it a red flag if a team isn't doing exploratory testing at all - even if their automated testing was excellent.

Even the best automated testing is inherently scripted testing - and that alone is not good enough.

November 18th 2019

Martin Fowler

@martinfowler

Exploratives Testen

Gleichzeitiges Erstellen und Ausführen von Tests um etwas über das System zu lernen, wobei die Erkenntnisse aus vorherigen Experimenten für weitere genutzt werden.

Elisabeth Hendrickson
@testobsessed

…ob die Software den bekannten

Anforderungen entspricht

…nach weiteren möglichen Risiken

\text{getestet} = \text{überprüft} + \text{erforscht}
\text{Verhalten (moderner) Software} = f
\left( \begin{array}{c} \phantom{\text{Code},}\\ \phantom{\text{Eingaben},}\\ \phantom{\text{Bestandsdaten},}\\ \phantom{\text{(Test-)Umgebung},}\\ \phantom{\text{Konfiguration},}\\ \phantom{\text{Zeit},}\\ \phantom{\text{Ort},}\\ \phantom{\text{Infrastruktur},}\\ \phantom{\text{…}} \end{array} \right)
\begin{array}{c} \text{Code},\\ \text{Eingaben}\phantom{,}\\ \phantom{\text{Bestandsdaten},}\\ \phantom{\text{(Test-)Umgebung},}\\ \phantom{\text{Konfiguration},}\\ \phantom{\text{Zeit},}\\ \phantom{\text{Ort},}\\ \phantom{\text{Infrastruktur},}\\ \phantom{\text{…}} \end{array}
\begin{array}{c} \phantom{\text{Code},}\\ \phantom{\text{Eingaben}},\\ \text{Bestandsdaten}\phantom{,}\\ \phantom{\text{(Test-)Umgebung},}\\ \phantom{\text{Konfiguration},}\\ \phantom{\text{Zeit},}\\ \phantom{\text{Ort},}\\ \phantom{\text{Infrastruktur},}\\ \phantom{\text{…}} \end{array}
\begin{array}{c} \phantom{\text{Code},}\\ \phantom{\text{Eingaben},}\\ \phantom{\text{Bestandsdaten}},\\ \text{(Test-)Umgebung}\phantom{,}\\ \phantom{\text{Konfiguration},}\\ \phantom{\text{Zeit},}\\ \phantom{\text{Ort},}\\ \phantom{\text{Infrastruktur},}\\ \phantom{\text{…}} \end{array}
\begin{array}{c} \phantom{\text{Code},}\\ \phantom{\text{Eingaben},}\\ \phantom{\text{Bestandsdaten},}\\ \phantom{\text{(Test-)Umgebung}},\\ \text{Konfiguration}\phantom{,}\\ \phantom{\text{Zeit},}\\ \phantom{\text{Ort},}\\ \phantom{\text{Infrastruktur},}\\ \phantom{\text{…}} \end{array}
\begin{array}{c} \phantom{\text{Code},}\\ \phantom{\text{Eingaben},}\\ \phantom{\text{Bestandsdaten},}\\ \phantom{\text{(Test-)Umgebung},}\\ \phantom{\text{Konfiguration}},\\ \text{Zeit}\phantom{,}\\ \phantom{\text{Ort},}\\ \phantom{\text{Infrastruktur},}\\ \phantom{\text{…}} \end{array}
\begin{array}{c} \phantom{\text{Code},}\\ \phantom{\text{Eingaben},}\\ \phantom{\text{Bestandsdaten},}\\ \phantom{\text{(Test-)Umgebung},}\\ \phantom{\text{Konfiguration},}\\ \phantom{\text{Zeit}},\\ \text{Ort}\phantom{,}\\ \phantom{\text{Infrastruktur},}\\ \phantom{\text{…}} \end{array}
\begin{array}{c} \phantom{\text{Code},}\\ \phantom{\text{Eingaben},}\\ \phantom{\text{Bestandsdaten},}\\ \phantom{\text{(Test-)Umgebung},}\\ \phantom{\text{Konfiguration},}\\ \phantom{\text{Zeit},}\\ \phantom{\text{Ort}},\\ \text{Infrastruktur}\phantom{,}\\ \phantom{\text{…}} \end{array}
\begin{array}{c} \phantom{\text{Code},}\\ \phantom{\text{Eingaben},}\\ \phantom{\text{Bestandsdaten},}\\ \phantom{\text{(Test-)Umgebung},}\\ \phantom{\text{Konfiguration},}\\ \phantom{\text{Zeit},}\\ \phantom{\text{Ort}},\\ \phantom{\text{Infrastruktur},}\\ \text{…} \end{array}

Schadenshöhe

Eintritts-wahrscheinlichkeit

Wenn ihr an euer Produkt denkt, was würdet ihr gern wissen?

Planung

Erforsche <Ziel>


mit <Resourcen>


um <Information> zu gewinnen

Was erforschen wir?

ein Feature

eine Anforderung

ein Modul

Welche Resourcen brauchen wir?
ein Werkzeug
einen Datensatz
eine Technik
eine Konfiguration

Welche Information suchen wir?

Sicherheit

Performance

Zuverlässigkeit

Fähigkeiten

Benutzbarkeit

Barrierefreiheit

Konsistenz (des Designs)

Verletzungen von Standards

Test Chartas

from "Explore It!"
by Elisabeth Hendrickson

Meine Mission ist es

 

innerhalb von <Zeitrahmen>

<Risiko>

 

in <Ziel> zu erforschen.

Was soll erforscht werden?

ein Feature

eine Anforderung

ein Modul

Was könnte schief gehen?

Funktion ist gestört

Benutzbarkeit ist schlecht

mangelnde Barrierefreiheit

Design ist Inkonsistent

Alternatives Charta Muster

Wie lange sollte es dauern?

Explore the behavior of the basket button


with various interaction types and speeds


to discover unintended side effects

Explore every input field in the shop


with every security tool you can find


to discover security issues

Explore the address form


with the name "Søren Anderson"


to discover if scandinavial letters are handled correctly

Too narrow

actually a test case

Too broad

you will never be finished

Explore the registration form


with common XSS injection strings


to discover XSS attack vulnerabilities

My mission is to test SQL vulnerabilities

 

in the context of the search form.

Find ways that a valid order modification might fail.

Experiment with invalid values when updating customer addresses.

Gute Chartas,
schlechte Chartas

So fühlen sich Schlechte Chartas an…

Worauf soll ich mich fokussieren?

Ich brauchen

mehr Zeit!!

Laaaaaaaangweilig!

Wo finde ich die notwendigen Daten dafür?!

Das soll noch niemand getestet haben?!

Ist das wirklich

wichtig?!

Ideen

Wir wollen Same-Day-Delivery anbieten!

OK. Wann ist die späteste Zeit für eine Same-Day-Bestellung?

13 Uhr.

Was soll passieren, wenn ein Kunde vor 13 Uhr eine Bestellung anfängt, aber erst nach 13 Uhr abschließt?

Können wir solche Kunden auf die Lieferzeitauswahl zurückwerfen?

Ja, das sollte kein Problem sein.

Erforsche den Bestellprozess nach der Lieferterminwahl


mit einem Same-Say-Termin

 

um Probleme mit dem Zurückwerfen zu entdecken.

Requirement Discussions

Oh… darüber muss ich nachdenken…

Kunden können einen Liefertermin bis zu 30 Minuten lang reservieren.

Sollen wir Reservierungen ab 12:30 unterbinden?

Erforsche Reservierungen


mit Same-Day-Lieferterminen nach 12:30

 

um herauszufinden, ob Kunden Same-Day-Bestellungen nach 13 Uhr aufgeben können.

Requirement Discussions

Continued

Sicherheit

Schnelligkeit

Zuverlässigkeit

Benutzbarkeit

Barrierefreiheit

Skalierbarkeit

Implizierte Erwartungen

// I don't know why this works…
// …but it does
// DO NOT TOUCH!
if (deliveryAddress != null) {
    …

Andere Inspirationen für Chartas…

Nehmt die Frage aus dem ersten Teil und macht Chartas daraus

Ausführung

Lief der Installationsprozess ohne Fehlermeldung?

Kann ich die Software starten?

Tiefere Fragen stellen

Wurde die Erfolgsmeldung angezeigt?

Kann ich das Produkt im Warenkorb finden?

Wird der Abmelde-Knopf angezeigt?

Kann ich mein Profil bearbeiten?

Blickt hinter das, was ihr zu finden erwartet

unerwartete Logs

JavaScript-Logs

unerwartete Systemlast

unerwartete Änderungen in der Datenbank/im Dateisystem

$> watch ls
$> psql

subtile GUI-Änderungen

unerwarteter Datentrasfer

Formulare

Browser-Typ

Cookies

URL & Parameter

Eingabefelder

Browser-Plugins

Variablen

  • Datenbasis
  • Anzahl Suchergebnisse
  • Anzahl Benutzer
  • Gesamtlaufzeit des Systems

Zählbares

→ 0, 1, viel

→ zu viel

→ too wenig

Position

→ Anfang, Mitte, Ende

Dateien & Speicher

→ unzugänglich machen

→ Standardordner ändern

Geographische Koordinaten

→ weit weg, nah

→ andere Zeitzonen

Formate

→ Daten, Dezimalzahlen, Binär, IP-Adressen

→ Dateiformate

Größe

→ groß, klein

Zeit, Frequenz & Dauer

→ Mitternacht

→ schnell, langsam

Eingabe & Navigation

→ Maus, Keyboard

→ Tippen, Einfügen

→ Touch

Variablen Typen

  • Format: Buchstaben? Sonderzeichen?
  • Eingabemethode: Einfügen, Klicken, Tippen
  • Position: Einfügen am Anfang, in der Mitte, am Ende
  • Zählbar: negativ, 0, 1, (zu) viele
  • Geschwindigkeit: schnelle Klicken
  • Eingabemethode: Klick, Enter-Taste, Leertaste
  • Zeit: füge das Produkt hinzu und warte den 13.09. ab

Enseble

Führt jetzt eure Chartas aus

Auswertung

Wer wird die Software benutzen und wozu?

Warum würde jemand das Produkt benutzen und nicht das der anderen?

Immer & Niemals

Kannst du mir einen Elevator-Pitch für das Produkt geben?

Wenn nicht anderes mehr funktioniert, was muss immer gehen?

Was ist deine größte Befürchtung bzgl. der Software?

Was sind die wichtigsten Qualitätskriterien?

Genauigkeit? Zuverlässigkeit? Erreichbarkeit? Benutzbarkeit? Barrierefreiheit? Sicherheit?

\left. \begin{array}{l} \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \\ \end{array} \right\}

Kern Funktionalität

\left\{ \begin{array}{l} \\ \\ \\ \\ \\ \\ \end{array} \right.

"Nicht-funktionale" Anforderungen

\left\{ \begin{array}{l} \\ \\ \\ \end{array} \right.

Risiken

Alternative Verifikation

Interne Konsistenz

Standards

Vergleichbares (Konkurrenz)

Plausibilität

Umkehrtest

\sqrt{a^2}=a

Checklisten

z.B. https://www.ministryoftesting.com/dojo/lessons/checklist-for-testing-web-page-functionality

Versucht Immer- und Niemals-Regeln für das Produkt zu finden

Immer abrechnen!

Niemals mehrfach!!

Es dürfen niemals falsche Inhaltsstoffe für Produkte angezeigt werden!

Es muss immer einen Liefertermin in der nächsten Woche geben!

Es werden niemals falsche Daten auf der Bestellbestätigungsseite angezeigt!

Ein Abbrechen des Bestellvorgangs muss immer möglich sein!

Niemals unterschiedliche Preise für das selbe Produkt anzeigen!

Immer valides HTML gemäß W3C-Standards!

Always reader page withing 1 second!

Jedes Bild hat immer eine aussagekräftige Beschreibung im alt-Attribut!

Lernen

Design

Ausführung

Lernen

Meine mission ist es den Bestellprozess zu erforschen


um Überraschungen zu entdecken.

Meine mission ist es den Bestellprozess zu erforschen


um Nebeneffekte bei Verwendung der Browser-Navigation zu entdecken.

Meine mission ist es den Bestellprozess zu erforschen


um Nebeneffekte durch Aktivität in parallelen Tabs zu entdecken.

tatsächliche Testzeit

Zuversichtsfaktor

auf das erforschte Risiko bezogen

gefundene Fehler

neue Chartas

offene Fragen

Dinge zum Automatisieren

Dinge zu Dokumentieren

Testschritte

My mission is to explore the checkout process


for side effects caused by browser navigation.

My mission is to explore the checkout process


for side effects caused by parallel activity in a different tab.

Was habt ihr heute über das Produkt gelernt?

Kontinuierliches Erforschen

Sprint

Planning

Review/

Retro

Coding

1st story done 🎉

2nd story done 🎉

last story done 🎉

Daylies

Backlog Refinement

"Explore It!"
by Elisabeth Hendrickson
https://pragprog.com/book/ehxta/explore-it

"Tips for Writing Better Charters for Exploratory Testing Sessions"
by Michael D. Kelly

https://www.slideshare.net/EuroSTARConference/mike-kelly-euro-star-webinar

https://www.youtube.com/watch?v=dOQuzQNvaCU

"A Heuristic Approach to Test Charters"
by Adam Howard

https://solavirtusinvicta.wordpress.com/2014/12/18/a-heuristic-approach-to-test-charters/

Sources & Acknowledgments

Lisi Hocke

@lisihocke

For her great feedback & encouragement on this talk

Alex Schladebeck

@alex_schl

For a lot of high value shared knowledge & feedback

https://youtu.be/9FKY1Is0lgs

Testen als Entdeckung – Exploratives Testen im Team (Workshop)

By Michael Kutz

Testen als Entdeckung – Exploratives Testen im Team (Workshop)

Ein Workshop zum Thema exploratives Testen für Entwicklungsteams. Basiert auf dem Buch "Explore It!" von Elisabeth Hendrickson.

  • 980