Erfahrungsbasiertes Testen

Kurz gesagt: Erfahrung weiß, wo die Fehler meistens sind: null, negativ, sehr groß, Doppelklick, Mitternacht, Überbleibsel alter Logik. Die intuitive Testfallermittlung macht daraus Angriffe. Exploratives Testen lernt das System beim Testen kennen, nach einer Charta, in einer zeitlich begrenzten Sitzung, mit Notizen. Eine Checkliste bewahrt, was das Team gelernt hat. Alle drei finden, was die Regel nicht sagt, deshalb ergänzen sie die anderen Verfahren.

Problem

Zehn Minuten, drei Fehler

Die Lieferung wurde mit Klassen und Grenzen getestet. Die Rabatte mit einer Entscheidungstabelle. Die Bestellung mit ihren Übergängen. Alles besteht.

Eine Kollegin aus dem Support, die in drei Online-Shops gearbeitet hat, setzt sich zehn Minuten daran. Sie drückt zweimal schnell auf „Bezahlen“: zwei Bestellungen, zwei Zahlungen. Sie gibt den Code mit einem Leerzeichen davor ein: „Der Code ist abgelaufen“, obwohl er es nicht ist. Sie legt 150 € in den Warenkorb und zahlt 4,90 € für die Lieferung.

Keiner der drei Fehler kommt aus einer Regel. Sie kommen aus der Erfahrung, was meistens kaputtgeht.

Die Idee

Erfahrungsbasierte Verfahren

Die letzte Gruppe von Verfahren geht weder von der Regel noch vom Code aus. Sie geht von der Erfahrung des Testers aus: welche Fehler er gesehen hat, wo, in welchen Systemen.

• Intuitive Testfallermittlung (error guessing): Tests, die auf die Stellen zielen, an denen es erfahrungsgemäß meistens Fehler gibt.
• Exploratives Testen: Du lernst das System beim Testen kennen, und jedes Ergebnis lenkt den nächsten Test.
• Checklistenbasiertes Testen: die Erfahrung des Teams, als Fragen aufgeschrieben.

Sie finden, was die Regel nicht sagt. Ihre Schwäche ist, dass sie von der Person abhängen und kein Maß für „wie viel ist abgedeckt“ liefern. Deshalb ergänzen sie die Verfahren aus den vorigen Lektionen, statt sie zu ersetzen.

Die Idee

Intuitive Testfallermittlung

Erfahrene Tester tragen eine Liste im Kopf: wo meistens ein Fehler ist. Eine Liste für einen Shop:

• null und leer: ein leerer Warenkorb, ein leeres Codefeld, 0 Stück;
• negativ und absurd: -1 Stück, ein Warenkorbwert von 999 999 €;
• sehr groß: eine Bestellung von 250 €, wenn alle Tests bis 80 € gehen;
• anders geschriebener Text: ein Code in Kleinbuchstaben, mit einem Leerzeichen davor, mit einem Zeilenumbruch eingefügt;
• eine wiederholte Aktion: ein Doppelklick auf „Bezahlen“, „Zurück“ nach der Zahlung, derselbe Code in zwei Tabs;
• Zeit: Mitternacht am letzten Tag des Codes, Zeitzonen, der 29. Februar;
• Überbleibsel: alte Logik, die niemand entfernt hat („ab 100 € wieder 4,90“);
• was nach einem Fehler bleibt: Leert eine Ablehnung den Warenkorb, bleibt eine halbe Bestellung zurück?

Wenn die Liste systematisch gegen das System laufen gelassen wird, wird jede Zeile zu einem Angriff (fault attack). Manche öffnen Fragen, die die Regel nicht beantwortet: Soll ein kleingeschriebener Code gültig sein? Das entscheidet nicht der Tester, sondern der Inhaber.

Genauer, für Neugierige

Der ISTQB CTFL v4.0.1 beschreibt die erfahrungsbasierten Verfahren in Abschnitt 4.4: intuitive Testfallermittlung (mit Fehlerangriffen als systematischer Art, sie anzuwenden), exploratives Testen und checklistenbasiertes Testen. Die Liste der Vermutungen stammt aus der Erfahrung des Testers, aus der Fehlerhistorie des Systems und aus bekannten Fehlerarten ähnlicher Systeme.

Probier es aus

Angriff: null und sehr viel

Nimm aus der Liste der Angriffe „null“ und „sehr groß“. Schreibe sie als Lieferungstests.

Die Regel: Die Lieferung ist ab einer Bestellung von 50 € (einschließlich) kostenlos, sonst kostet sie 4,90 €. Ein leerer Warenkorb kann nicht bestellt werden.

	Eingabe	Erwartet		Das richtige System
#	Warenkorbwert	Abgelehnt	Lieferung

Eine leere Ergebniszelle wird nicht geprüft. Beträge schreibt man wie 49,99.

▶ Ausführen+ Zeile hinzufügenAnfang wiederherstellen

Die Idee

Exploratives Testen

Beim explorativen Testen schreibst du die Testfälle nicht vorher. Du lernst das System kennen, entwirfst und führst die Tests gleichzeitig aus. Wenn dir etwas Merkwürdiges auffällt, geht der nächste Test dorthin.

Das heißt nicht „zufällig klicken“. Drei Dinge machen daraus Arbeit statt eines Spaziergangs:

• Eine Charta: ein Ziel für die Sitzung. Eine praktische Vorlage: „Erkunde [was] mit [womit], um [was] herauszufinden.“ Zum Beispiel: „Erkunde den Gutscheincode mit abgelaufenen, benutzten und kleingeschriebenen Codes, um herauszufinden, wie der Shop dem Kunden sagt, warum der Code nicht gilt.“
• Eine zeitlich begrenzte Sitzung: meist 60 bis 90 Minuten, ohne Unterbrechung, nur zur Charta. Was außerhalb auffällt, notierst du für eine spätere Sitzung.
• Notizen: was du getestet hast, wie, was du gefunden hast, welche Fragen du hast. Am Ende steht eine Nachbesprechung (debrief) mit der Testleitung: was gefunden wurde, was bleibt, wie die nächste Charta lautet.

Genauer, für Neugierige

Die Vorlage „Erkunde … mit … um … herauszufinden“ stammt aus Elisabeth Hendricksons Buch „Explore It!“ (2013). Das Testen in Sitzungen mit Chartas und Nachbesprechungen (session-based test management) beschrieben Jonathan und James Bach um 2000. Der CTFL v4.0.1 sagt, exploratives Testen sei am nützlichsten, wenn die Spezifikation schlecht oder unzureichend ist, die Zeit knapp ist oder als Ergänzung zu formaleren Verfahren. Und dass es am besten mit erfahrenen Testern funktioniert, die die Domäne kennen.

Probier es aus

Die Charta und die Notizen

1. Welche Charta ist die beste?

Prüfe, dass der Gutscheincode bei einem Warenkorb von 30 € 10 % gibtTeste den GutscheincodeErkunde den Gutscheincode mit abgelaufenen, benutzten, kleingeschriebenen und mit Leerzeichen gepolsterten Codes, um herauszufinden, wie der Shop dem Kunden sagt, warum der Code nicht gilt

2. Während der Sitzung fällt dir auf, dass der Warenkorb nach einer Adressänderung manchmal noch den alten Betrag zeigt. Es steht nicht in der Charta. Was tust du?

Du schreibst es nicht auf, weil es nicht in der Charta stehtDu schreibst es in die Notizen als Befund und als Idee für eine neue Charta und machst mit der Charta weiterDu lässt die Charta fallen und jagst dem Neuen nach

3. Was kommt in die Notizen der Sitzung?

Nur die gefundenen FehlerNichts: Exploratives Testen hat keine AufzeichnungenWas wie getestet wurde, die Befunde, die Fragen und die Ideen für nächste Sitzungen

Prüfen

Die Idee

Checklistenbasiertes Testen

Eine Liste von Angriffen im Kopf einer Kollegin hilft einem Team. Aufgeschrieben hilft sie allen. Checklistenbasiertes Testen lässt eine Liste von Fragen oder Bedingungen gegen das System laufen.

Eine Checkliste für jedes neue Formular im Shop:

• ein leeres Feld, der längste erlaubte Text, ein Zeichen mehr;
• Leerzeichen am Anfang und am Ende, Klein- und Großbuchstaben;
• Kyrillisch, Lateinisch, Sonderzeichen;
• ein Doppelklick auf den Button, „Zurück“ nach dem Absenden;
• mit der Tastatur, ohne Maus; mit einem Screenreader;
• die Fehlermeldung sagt, was zu korrigieren ist.

Sie ist eine Verwandte der Review-Checkliste, nur für das laufende System statt für das Dokument. Und sie hat dasselbe Risiko: Eine veraltete Checkliste wird mechanisch abgearbeitet, und neue Fehler rutschen daran vorbei. Deshalb wird sie mit jedem Fehler aktualisiert, der durchgerutscht ist.

Probier es aus

Die Sitzung

Ordne eine explorative Sitzung von der Charta bis zum nächsten Schritt.

1. Der nächste Schritt: Fehlerberichte, Fragen an den Inhaber, neue Chartas↑↓
2. Die Sitzung: 60 bis 90 Minuten ohne Unterbrechung, nur zur Charta↑↓
3. Die Notizen: was getestet wurde, Befunde, Fragen, Ideen↑↓
4. Die Nachbesprechung: mit der Testleitung, was gefunden wurde und was bleibt↑↓
5. Die Charta: was, womit und wonach du suchst↑↓

Prüfen

Übung

Angriffe auf das Limit

1. Negativ, und was bleibt. Die zwei Angriffe aus der Liste: eine negative Menge und „was nach einer Ablehnung im Warenkorb bleibt“.

Schreibe die Angriffe auf das Warenkorb-Limit: eine negative Menge und ein Hinzufügen über das Limit hinaus. Prüfe auch, was im Warenkorb bleibt.

Die Regel: Im Warenkorb können höchstens 10 Stück eines Produkts liegen. Was darüber hinausgeht, wird mit einer Meldung abgelehnt, und der Warenkorb bleibt, wie er ist. Hinzugefügt wird mindestens 1 Stück.

	Eingabe		Erwartet		Das richtige System
#	Im Warenkorb	Hinzufügen	Abgelehnt	Danach im Warenkorb

Eine leere Ergebniszelle wird nicht geprüft. Beträge schreibt man wie 49,99.

▶ Ausführen+ Zeile hinzufügenAnfang wiederherstellen

Test

Teste dich

1. Was ist intuitive Testfallermittlung (error guessing)?

Tests, die zufällig geschrieben werdenDas richtige Ergebnis erratenTests, die auf die Stellen zielen, an denen es erfahrungsgemäß meistens Fehler gibt

2. Wie unterscheidet sich exploratives Testen vom vorherigen Schreiben von Testfällen?

Du lernst das System kennen, entwirfst und führst Tests gleichzeitig aus, und jedes Ergebnis lenkt den nächsten TestNur Entwickler machen esEs gibt gar keinen Plan

3. Warum ersetzen erfahrungsbasierte Verfahren Klassen und Grenzen nicht?

Sie hängen von der Erfahrung der Person ab und liefern kein Maß für die ÜberdeckungWeil sie langsamer sindSie ersetzen sie doch

4. Wann ist exploratives Testen am nützlichsten?

Wenn die Spezifikation schlecht ist, die Zeit knapp ist oder du finden willst, was die Regeln nicht sagenNie, wenn es automatisierte Tests gibtWenn die Regel ganz in einer Entscheidungstabelle steht

5. Was ist das Risiko bei einer Checkliste?

Sie veraltet und wird mechanisch abgearbeitet, ohne nachzudenkenEs gibt kein RisikoSie ist zu kurz

Prüfen

Lektion von vorn beginnen

Verwandte Lektionen

• Baut auf: Grenzwerte · Entscheidungstabellen · Zustandsübergänge · Codeüberdeckung
• Geht weiter in: Warum und was automatisieren
• Aufgaben zum Thema: Testentwurfsverfahren