Ein Testplan ist ein kurzes Dokument, das festhält, was getestet wird, was nicht, von wem, in welchen Umgebungen, und was zutreffen muss, bevor jemand anfängt oder aufhört. Er entsteht vor dem Testen, und sein eigentlicher Wert liegt im zweiten Punkt dieser Aufzählung.

Aufzählen, was man zu prüfen gedenkt, kann jeder. Aufzuschreiben, was man bewusst liegen lässt, ist der Teil, der das Gespräch drei Wochen später verhindert, in dem jemand annahm, eine Sache sei abgedeckt, weil niemand gesagt hatte, dass sie es nicht ist.

Was hineingehört

Sechs Abschnitte tragen fast den gesamten Wert, und jeder von ihnen darf ein paar Zeilen lang sein.

  • Umfang. Was diese Testrunde abdeckt: welche Funktionen, welche Releases, welche Plattformen.
  • Nicht im Umfang. Was sie bewusst nicht abdeckt, und warum. Der nützlichste Abschnitt und der, der am häufigsten fehlt.
  • Vorgehen. Manuell, automatisiert oder die Aufteilung dazwischen, und auf welcher Ebene.
  • Umgebungen und Daten. Wo getestet wird und wogegen, denn das entscheidet, was gefunden werden kann. Ein Plan, der “Staging” sagt, ohne den Build und die Daten zu nennen, sagt nicht viel.
  • Eintritts- und Austrittskriterien. Was gelten muss, bevor das Testen beginnt, und was gelten muss, bevor es als beendet gilt.
  • Risiken. Was diesen Plan zum Scheitern bringen könnte, benannt solange es nichts kostet.

Manche Pläne führen zusätzlich Rollen, einen Zeitplan und einen Fehlerprozess. Das wird wichtiger, je mehr Menschen beteiligt sind, und bedeutet sehr wenig, wenn Sie zu zweit sind.

An den Austrittskriterien entzünden sich die Streitfälle

“Fertig” ist nicht selbsterklärend, und ein Plan, der es nicht definiert, erzeugt ein Release, über das am Tag der Auslieferung gestritten statt vorher entschieden wird.

Schwach
Alle größeren Fehler behoben und das Testen abgeschlossen
Besser
Jeder Fall der Checkout-Suite besteht, keine offenen Defekte mit Schweregrad 1 oder 2, und die drei bekannten Defekte mit Schweregrad 3 sind mit Umgehungslösungen in den Release Notes festgehalten

Das zweite kann jemand prüfen, der nicht im Raum war. Das erste ist eine Stimmung.

Für Eintrittskriterien gilt dasselbe: sich darauf zu einigen, dass das Testen beginnt, wenn der Build seinen Smoke Test besteht, erspart einer Testerin den Nachmittag, an dem sie auf vierzig Arten beweist, dass ein kaputter Build kaputt ist.

Wie lang er sein sollte

Kürzer als gedacht, und proportional dazu, wie viele Menschen zustimmen müssen.

Zwei Leute, die eine Funktion testen, die beide verstehen, brauchen einen Absatz, und mehr zu schreiben ist Theater. Ein reguliertes Release mit externer Prüfung braucht das formale Dokument, weil jemand außerhalb des Teams nachlesen können muss, was entschieden wurde. Die meiste Arbeit liegt dazwischen, und eine Seite ist meistens richtig.

Der Test dafür: würde sich das Verhalten irgendjemandes ändern, wenn es diesen Abschnitt nicht gäbe? Wenn nicht, löschen Sie ihn. Ein Plan, den niemand liest, ist schlechter als keiner, weil er den Glauben erzeugt, das Testen sei geplant worden.

Wo er zwischen den anderen Dokumenten steht

Ein Plan liegt eine Ebene über den Prüfungen selbst.

  • Der Plan sagt, dass der Checkout-Ablauf manuell in Chrome und Safari getestet wird und dass Mobilgeräte in dieser Runde nicht im Umfang sind.
  • Die Testfälle sagen genau, was zu tun ist und was dabei passieren soll.
  • Die Regressionssuite sagt, was erneut geprüft wird, weil es früher funktioniert hat.
  • Die Akzeptanzkriterien sagen, was die Funktion überhaupt leisten sollte, und sie standen vor alldem fest.

Den Plan mit den Fällen zu verwechseln ist der übliche Fehler: ein Dokument mit zweihundert Schritten ist kein Plan, es ist eine Suite mit einem Deckblatt.

Der Fehlerprozess gehört hinein

Eine Zeile, die die meisten Pläne auslassen, und sie kostet mehr, als sie aussieht. Halten Sie fest, wie ein Defekt gemeldet wird, wohin er geht und wer entscheidet, ob er das Release aufhält.

Ohne das treffen Funde in drei Chat-Threads und einer Tabelle ein, wer sie einsammelt, verbringt den letzten Tag der Runde mit dem Nachfassen von Details, und etwas Echtes geht im Rauschen verloren. Benennen Sie das Ziel und die Form dessen, was hineingeht, und verlinken Sie die Anleitung, statt sie zu wiederholen - unser Leitfaden für Fehlerberichte existiert genau dafür.

Wenn die Testenden Menschen sind, deren Beruf nicht Software ist, zählt die Form mehr, nicht weniger. Fragen Sie sie, was passiert ist und was sie erwartet hatten, und lassen Sie das Werkzeug den technischen Teil tragen.

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

Kurz gefasst

Eine Seite: was abgedeckt ist, was nicht, wie, wo, was zutreffen muss, um zu beginnen und um aufzuhören, und was schiefgehen könnte. Vor dem Testen geschrieben, mit den Betroffenen abgestimmt und kurz genug, dass sie es lesen. Der Abschnitt, den alle überspringen - nicht im Umfang - ist der, der den Streit verhindert.