Ein Testfall ist eine einzelne Prüfung, aufgeschrieben, damit jemand, der sie nicht verfasst hat, sie ausführen kann und dieselbe Antwort bekommt. Er benennt einen Ausgangszustand, die Schritte und das, was passieren soll. Wenn zwei Leute ihn ausführen können und sich uneinig sind, ob er bestanden wurde, ist er nicht fertig.

Das ist die ganze Idee, und es ist dieselbe Idee wie bei einem Fehlerbericht, nur von der anderen Seite. Ein Fehlerbericht sagt: “So bringt man etwas zum Scheitern.” Ein Testfall sagt: “So prüft man, ob es richtig läuft.”

Was er enthält

Sechs Teile, und nur drei davon sind die interessanten.

  • Eine Kennung, damit er in einem Build-Bericht oder einem Gespräch benannt werden kann
  • Ein Titel, der sagt, was geprüft wird, nicht was geklickt wird
  • Vorbedingungen: der Zustand, in dem die Welt sein muss, damit Schritt eins Sinn ergibt
  • Schritte, nummeriert, jeder davon eine Handlung
  • Erwartetes Ergebnis, spezifisch genug, um falsch sein zu können
  • Tatsächliches Ergebnis, eingetragen beim Ausführen

Die drei, die darüber entscheiden, ob er funktioniert, sind die Vorbedingungen, das erwartete Ergebnis und der Titel. Schritte sind einfach. Zu wissen, welchen Zustand der Test voraussetzt und was “richtig” so genau bedeutet, dass man darüber streiten kann, ist die Arbeit.

Den Titel schreiben

Ein Titel wird in einer Liste von zweihundert gelesen, also sollte er sagen, was verifiziert wird.

Schwach
Login-Seite testen
Besser
Die Anmeldung wird mit einer Meldung abgelehnt, wenn das Passwort falsch ist

Der zweite sagt Ihnen, was er abdeckt, was ein Fehlschlag bedeuten würde und ob er den darunter doppelt. Der erste sagt Ihnen nichts, und in sechs Monaten weiß niemand mehr, ob er die Fehlermeldung abdeckt oder nicht.

Die Schritte schreiben

Nummerieren Sie sie und schreiben Sie genau eine Handlung in jeden. Der Test ist nicht der Ort, um sparsam zu sein.

Titel:          Die Anmeldung wird mit einer Meldung abgelehnt, wenn das Passwort falsch ist
Vorbedingungen: Für ada@example.com existiert ein bestätigtes Konto
Schritte:
  1. /login aufrufen
  2. ada@example.com in das E-Mail-Feld eingeben
  3. wrongpassword in das Passwortfeld eingeben
  4. Auf Anmelden klicken
Erwartet:       Die Seite bleibt auf /login, zeigt "E-Mail oder Passwort ist falsch",
                und das Passwortfeld ist geleert

Beachten Sie, was das erwartete Ergebnis nicht sagt: “Ein Fehler erscheint.” Drei verschiedene Implementierungen erfüllen diesen Satz, und zwei davon sind falsch. Es benennt auch, was nicht hätte passieren sollen, nämlich keine Navigation, denn ein Test, der nur auf die Meldung prüft, besteht auch auf einer Seite, die die Meldung zeigt und den Benutzer trotzdem anmeldet.

Was einen Testfall verdirbt

Er hängt vom letzten Test ab. Ein Fall, der nur besteht, wenn der vorherige zuerst lief, kann nicht allein ausgeführt und nicht umsortiert werden und fällt in sich zusammen, sobald früh etwas kaputtgeht. Jeder Fall stellt seine eigenen Vorbedingungen her.

Er prüft sechs Dinge. Wenn er fehlschlägt, erfahren Sie, dass eines von sechs Dingen falsch ist. Teilen Sie ihn auf.

Er beschreibt die Oberfläche statt des Verhaltens. “Auf den blauen Button oben rechts klicken” bricht, wenn der Button umzieht; “Das Formular absenden” nicht.

Sein erwartetes Ergebnis ist ein Schulterzucken. “Funktioniert korrekt”, “wie entworfen”, “keine Fehler” - all das heißt, dass die ausführende Person entscheidet, und genau das soll ein Testfall vermeiden.

Er testet, was nicht fehlschlagen kann. Ein Fall, der prüft, ob eine statische Überschrift die richtigen Worte enthält, kostet bei jedem Durchlauf für immer Zeit. Stecken Sie den Aufwand dorthin, wo Verhalten steckt.

Manuelle und automatisierte Fälle

Dieselbe Disziplin, andere Ökonomie. Ein automatisierter Fall läuft bei jedem Build und muss präzise sein, sonst wird er flaky; ein manueller Fall wird von einem Menschen ausgeführt, der urteilen kann, was zugleich seine Stärke und der Grund dafür ist, dass zwei Leute aus einem vagen Fall zwei Antworten holen.

Schreiben Sie manuelle Fälle für das, was Urteil braucht - sieht dieses Layout falsch aus, ergibt diese Meldung Sinn - und automatisieren Sie, was eine bekannte Eingabe und eine bekannte Antwort hat. Und halten Sie die manuellen kürzer, als Sie denken: Ein Fall mit fünfzehn Schritten wird von jedem, der ihn zum neunten Mal ausführt, in der Mitte übersprungen.

Wenn einer fehlschlägt

Ein fehlgeschlagener Testfall ist der Anfang eines Fehlerberichts, und er startet vor den meisten: Die Schritte stehen schon, das erwartete Ergebnis ist schon formuliert, und beides ist in einer Sprache, mit der jemand etwas anfangen kann.

Was er nicht mitbringt, ist der Kontext der Maschine, auf der er fehlschlug - der Browser, die Konsole, die Requests hinter der Seite. Das ist die Lücke zwischen “Testfall 47 fehlgeschlagen” und einem Bericht, mit dem ein Entwickler arbeiten kann.

Session Replay

Kostenlose Chrome-Erweiterung. Ein Klick auf der Seite, die sich falsch verhält, erfasst den Screenshot, die Konsole und das Netzwerkprotokoll und gibt Ihnen einen Link, den Sie ins Ticket einfügen können.

Erweiterung holen

Hängen Sie die Kennung des Falls an den Bericht, und die beiden bleiben verbunden: Wer ihn behebt, kann dieselbe Prüfung ausführen, und wer die Prüfung im nächsten Release ausführt, sieht, dass sie einmal fehlschlug. Der Leitfaden für Fehlerberichte deckt den Rest ab, den dieser Bericht braucht.

Die kurze Fassung

Eine Prüfung pro Fall. Vorbedingungen, die er sich selbst herstellt. Schritte, denen jemand anderes folgen kann. Ein erwartetes Ergebnis, das so genau ist, dass zwei Leute sich nicht darüber streiten können, ob es eingetreten ist. Alles andere ist Formatierung.