Manuelle Testfälle schreiben — Aufbau, Vorlage und vier Regeln aus einem Projekt mit Coding-Agent

Veröffentlicht 18.09.2026 · Aktualisiert 20.09.2026
von

Mitte September 2026 hatte der Katalog manueller Testfälle im DI²-Projekt 32 aktive Einträge. 27 davon gab es nur, weil vorher etwas kaputt gewesen war. Bei gerade einmal zwei Testfällen stand schon fest, was am Bildschirm zu sehen sein muss, bevor es den Code gab.

Ein Katalog, der fast nur aus Fehlern entstanden ist, sichert ab, was schon einmal schiefgegangen ist. Etwas Neues fragt er kaum ab. Der erste vollständige Lauf dieses Katalogs fand trotzdem 19 Fehler in der Anwendung. Fast alle fielen während des Laufs nebenbei auf, an Stellen, die kein Testfall abfragte.

Dieser Artikel beschreibt, wie man Testfälle schreiben kann, wenn ein Coding-Agent die Anforderung, den Code und den Testfall schreibt und es keine zweite Person gibt, die gegenliest. Ein Testfall besteht dabei aus drei Dingen, die zu verschiedenen Zeiten entstehen. Was am Bildschirm zu sehen sein muss, steht in der Anforderung, bevor es den Code gibt. Die Folge der Klicks kommt aus der fertigen Oberfläche. Der Lauf kommt zuletzt, und erst sein Protokoll ist ein Nachweis dafür, dass geprüft wurde.

Alle Regeln und Zahlen stammen aus einem einzigen Projekt und aus drei Wochen Praxis. Es sind die Regeln dieses Projekts und keine allgemeine Testlehre. Den Katalog, seine Regeln, die automatische Formprüfung und die Protokolle hat ein Coding-Agent geschrieben, Claude Code in den Modellen Claude Opus 5, Claude Fable 5 und Claude Fable 5.1, nach Vorgaben des Maintainers. Der Maintainer hat die Vorgaben gemacht, geklickt und entschieden. Den Code der Anwendung liest er nicht selbst.

Das Wichtigste vorab:

  • In den Katalog manueller Testfälle kommt im DI²-Projekt nur, was sich allein am Bildschirm prüfen lässt: zum Beispiel der Moment, in dem eine Meldung erscheint. Alles, was ein Programm zuverlässig selbst prüfen kann, gehört in die automatisierten Tests.
  • Ein Testfall stellt jeden Schritt neben das, was dabei zu sehen sein muss: In einer Tabelle muss beim Testen niemand zwischen Schritten und Erwartungen hin- und herspringen, und es fällt auf, wenn eines von beiden fehlt. Das Ergebnis eines Laufs steht nie im Testfall, sondern in einem eigenen Protokoll.
  • Vier Regeln für das Schreiben sollen die fehlende zweite Person ersetzen: Die Erwartung kommt aus der Anforderung und nicht aus dem fertigen Code, sie enthält kein Wort, das nur der Programmierer kennt, sie sagt mindestens einmal, was nicht passieren darf, und sie nennt den Zeitpunkt, wo er zählt. Ganz ersetzen sie die zweite Person nicht.
  • Woher ein Testfall kommt, prägt, wonach er fragt: Ein Testfall aus einem Fehler fragt vor allem danach, ob dieser Fehler wiederkommt. Im DI²-Projekt waren zuletzt 27 von 32 Testfällen so entstanden, und diese Zahl wird automatisch nachgerechnet.
  • Ein geschriebener Testfall ist eine Zusage, erst ein protokollierter Lauf ist ein Nachweis: Im DI²-Projekt stand ein Fehler kurz vor dem Schließen, und sein Testfall war nie gelaufen. Aufgefallen ist es durch eine Rückfrage.

Voraussetzung: Keine. Die Beispiele stammen aus einer Web-Anwendung, die Tabellen und Spalten einer Datenbank verwaltet, mehr muss man über sie nicht wissen. Der Katalog besteht aus Markdown-Dateien im Repository und einem kleinen Prüfprogramm, ein Werkzeug zur Testverwaltung ist nicht nötig. Zwei Wörter hält der Text auseinander: Testfall meint einen aufgeschriebenen Ablauf mit Erwartungen, den ein Mensch am Bildschirm ausführt. Test meint eine automatisierte Prüfung, die grün oder rot endet.

Inhalt

Warum ein Katalog manueller Testfälle neben den automatisierten Tests steht

Der Katalog im DI²-Projekt entstand am 27. August 2026 mitten in einem Testdurchgang. Der Maintainer hatte dem Agenten im Chat eine Liste von Klick-Schritten diktiert, um eine Änderung zu prüfen. Nach der Sitzung wäre diese Liste weg gewesen, und beim nächsten Mal hätte jemand sie neu erfinden müssen. Der Auftrag lautete deshalb: Die Testfälle sollen im Repository liegen, wiederholbar sein und nach Bereichen der Anwendung geordnet werden.

Was in diesen Katalog gehört, ist eng gefasst. Ein Testfall prüft hier nur, was sich allein am Bildschirm prüfen lässt. Dazu gehört der Moment, in dem eine Meldung erscheint, das Verhalten einer Seite auf einem kleinen Bildschirm oder der Weg eines Nutzers durch mehrere Ansichten. Alles, was ein Programm zuverlässig selbst prüfen kann, gehört in die automatisierten Tests. Dort läuft es bei jeder Änderung von selbst mit, ein Testfall läuft nur, wenn jemand klickt. Diese Grenze ist eine Entscheidung des Projekts, denn von Hand lässt sich auch prüfen, was in einer Datenbank oder in einer Datei steht.

Kernaussage: Ein Katalog manueller Testfälle ersetzt keine automatisierten Tests. Im DI²-Projekt nimmt er auf, was nur ein Mensch am Bildschirm beurteilen kann, und er sorgt dafür, dass diese Prüfung beim nächsten Mal nicht neu erfunden wird.

Wie ein Testfall aufgebaut ist: Vorlage und Beispiel

Jeder Testfall ist eine eigene Markdown-Datei mit demselben Aufbau. Die folgende Vorlage zeigt ihn vollständig, und wer selbst Testfälle schreiben will, kann sie so übernehmen:

# TEST-NNNN: <Titel>

- **Suiten:** <Bereich>[, <Bereich> …]
- **Lauf-Klasse:** Smoke | Regression
- **Status:** Aktiv | Zurückgezogen (<Begründung>)
- **Bezug:** <die Anforderung mit ihrem Kriterium, oder der Fehler, aus dem der Testfall entstand>
- **Abdeckung:**
  - <Datei der Anwendung, auf die der Testfall zielt>

**Ziel:** <Was soll dieser Testfall zeigen? Ein Satz.>

**Vorbedingung:** <Zustand, aus dem heraus der Testfall startet.>

**Ablauf:**

| # | Schritt | Erwartetes Ergebnis |
|---|---|---|
| 1 | <Klick-Schritt> | <was dabei zu sehen sein muss> |

**Übergreifend erwartet:**
- <Aussage, die zu keinem einzelnen Schritt gehört>

**Aufräumen:** <Wie der Ausgangszustand wiederhergestellt wird.>

Am Anfang steht ein Kopf mit fünf Pflichtangaben. Eine Suite ist eine Gruppe von Testfällen zu einem Bereich der Anwendung. Die Lauf-Klasse sagt, wann der Testfall fällig ist: Ein Smoke-Testfall läuft bei jeder Auslieferung, und wenn er fehlschlägt, wird nicht ausgeliefert. Ein Regressions-Testfall läuft, wenn eine der Dateien geändert wurde, die unter Abdeckung stehen. Beide Wörter stehen hier nur für die Fälligkeit im DI²-Katalog, im üblichen Sprachgebrauch bedeuten sie mehr. Der Bezug nennt den Anlass des Testfalls. Auf dieses Feld kommt der Artikel beim Thema Herkunft zurück.

Danach folgen das Ziel in einem Satz, die Vorbedingung und der Ablauf als Tabelle. Die Vorbedingung beschreibt den Zustand vor dem ersten Klick, und das ist vor allem der Zustand in der Datenbank: mit welcher Tabelle der Testfall arbeitet und dass dort noch keine Spalte ausgewählt ist. Dazu kommen Angaben wie die Rolle, mit der man angemeldet ist, oder die Breite des Bildschirms. Das folgende Beispiel ist ein gekürzter und verallgemeinerter Testfall aus dem Katalog. Er prüft, dass die Anwendung sofort eine Meldung zeigt, wenn eine Prüfregel nicht mehr zu ihrer Spalte passt:

#SchrittErwartetes Ergebnis
1Eine Tabelle öffnen und eine Zahlen-Spalte auswählen.Die Spalte gilt als ausgewählt.
2Auf dieser Spalte eine Prüfregel für einen Wertebereich anlegen und speichern.Die Regel erscheint in der Liste. Es erscheint keine Meldung, denn die Regel ist gültig.
3Die Spalte auf Text umstellen und speichern.Die Spalte zeigt den Text-Typ.
4Ohne weitere Aktion die Meldungen betrachten.Eine offene Meldung nennt die ungültig gewordene Regel und den Grund. Sie erscheint sofort, ohne dass die Ansicht gewechselt werden muss.
5Die Ansicht neu laden.Weiterhin genau eine Meldung, keine Doppelung.

Unter der Tabelle steht im Abschnitt „Übergreifend erwartet“, was zu keinem einzelnen Schritt gehört, etwa Bedingungen, die durchgehend gelten, oder Toleranzen. Am Ende steht das Aufräumen, das den Ausgangszustand wiederherstellt.

Zwei Regeln gehören zu diesem Format. Ein Schritt ohne eigene Beobachtung bekommt einen Strich in die Ergebnis-Spalte, das ist ehrlicher, als eine Erwartung zu erfinden. Und jeder Testfall läuft für sich allein: Die Vorbedingung verweist nie auf den Endzustand eines anderen Testfalls. Sonst sieht ein vergessener Vorbereitungs-Schritt aus wie ein Fehler der Anwendung, und genau das ist beim ersten Durchgang passiert.

Dass Schritt und Erwartung nebeneinanderstehen, kam aus einer Beschwerde. Am 28. August arbeitete der Maintainer den Katalog zum ersten Mal ab. Schritte und erwartete Ergebnisse standen damals in zwei getrennten Abschnitten, und beim Testen musste er zwischen beiden hin- und herspringen und die Nummern im Kopf behalten. Alle sieben Testfälle wurden deshalb auf die Tabelle umgebaut. Seitdem steht in jeder Zeile der Schritt neben dem, was dabei zu sehen sein muss, und wer den Testfall abarbeitet, liest ihn von oben nach unten durch. In dieser Form fällt auch auf, wenn zu einem Schritt die Erwartung fehlt oder zu einer Erwartung der Schritt.

Der Testfall selbst enthält kein Datum, kein Ergebnis und keinen Hinweis auf eine Umgebung. Diese Datei nennt der Artikel die Deklaration. Jeder Lauf bekommt ein eigenes Protokoll, das festhält, wer wann in welcher Umgebung welche Testfälle ausgeführt hat und was dabei herauskam. Der Grund für die Trennung steht im Katalog selbst: Wer ein altes Ergebnis im Testfall liest, bestätigt es beim nächsten Lauf unbewusst. Ein Protokoll wird auch nie nachträglich umgeschrieben. Ein erneuter Lauf nach einer Korrektur ist ein neues Protokoll, und der alte Fehlschlag bleibt als Beleg stehen.

Kernaussage: Ein Testfall ist ein Dokument zum Abarbeiten, nicht zum Lesen. In der Tabelle steht jeder Schritt neben seiner Erwartung. Das erspart beim Testen das Springen zwischen zwei Listen und zeigt, wo eines von beiden fehlt. Das Ergebnis gehört ins Protokoll, damit der Testfall beim nächsten Lauf unvoreingenommen gelesen wird.

Testfälle schreiben: drei Regeln und eine vierte

In der klassischen Arbeitsteilung schreibt nicht der Entwickler die Testfälle. Wer den Code geschrieben hat, richtet den Testfall leicht an seiner Umsetzung aus. Wege, an die er beim Programmieren nicht gedacht hat, fehlen dann auch im Testfall. Im DI²-Projekt gibt es diese zweite Person nicht. Derselbe Agent schreibt die Anforderung, den Code und den Testfall. Als der Maintainer das am 28. August ansprach, ließ sich der Einwand am Bestand nachzählen: Alle sieben Testfälle waren nach der Umsetzung geschrieben worden.

Die naheliegende Lösung wäre, den Testfall vor der Umsetzung anzulegen. In diesem Format geht das nicht vollständig, denn Vorbedingung, Schritte und Aufräumen nennen konkrete Klicks und setzen die fertige Oberfläche voraus. Ein Testfall besteht aber aus zwei Teilen mit verschiedener Quelle, und einer davon lässt sich vor der Umsetzung festlegen:

Teil des TestfallsQuelleSteht fest
Ziel und erwartetes Ergebnisdas Kriterium der Anforderungvor der Umsetzung, im Text der Anforderung
Vorbedingung, Schritte, Aufräumendie fertige Oberflächenach der Umsetzung

Daraus sind drei Regeln für das Schreiben geworden und eine vierte, die schon einen Tag vorher entstanden war. Wie gut sie wirken, ist nach drei Wochen kaum belegt. Wo es einen Beleg gibt, steht er bei der Regel.

Erste Regel: Die Erwartung kommt aus der Anforderung und nicht aus dem fertigen Code. Wer das erwartete Ergebnis aus dem Code ableitet, schreibt auf, was die Anwendung tut, und ein solcher Testfall kann kaum noch fehlschlagen. Wer es aus der Anforderung übernimmt, schreibt auf, was sie tun soll. Die fehlende zweite Person wird damit durch einen zeitlichen Abstand ersetzt: Die Erwartung liegt schriftlich fest, bevor es den Code gibt. Im Projekt wird deshalb schon beim Schreiben einer Anforderung entschieden, welches ihrer Kriterien sich nur am Bildschirm prüfen lässt, und dieses Kriterium wird so formuliert, dass es später als erwartetes Ergebnis taugt.

Knapp drei Wochen lang stand diese Regel nur im Katalog, angewendet hatte sie noch niemand. Das erste Mal geschah es Mitte September 2026. In einer Anforderung vom 13. September waren zwei Kriterien als solche gekennzeichnet, die sich nur am Bildschirm prüfen lassen. Drei Tage später entstand der Code, und die zwei Testfälle dazu übernahmen ihre Erwartungen aus diesen beiden Kriterien. Was am Bildschirm zu sehen sein muss, stand also schon fest, bevor es den Code gab.

Schon beim ersten Lauf dieser zwei Testfälle zeigte sich, was die Regel nicht leistet. Der Maintainer sah die neue Oberfläche zum ersten Mal und war mit der Bedienung nicht einverstanden. Die Anforderung hatte vorgesehen, dass sich ein bestimmter Wert nur in einem eigenen Dialog ändern lässt. Der Maintainer wollte ihn direkt in der Zeile der Tabelle ändern können, so wie es an anderer Stelle der Anwendung schon möglich war. Daraufhin wurde die Anforderung geändert und die Oberfläche umgebaut. Beide Testfälle wurden umgeschrieben und noch einmal von vorn ausgeführt.

Der zeitliche Abstand hat also getan, was er sollte: Die Erwartung war nicht am fertigen Code entlanggeschrieben. Verhindert hat er nicht, dass die Erwartung selbst eine Lücke hatte. Wer die Anforderung schreibt und schon weiß, wie er sie umsetzen wird, schreibt sie danach. Mehr als diesen einen Fall gibt es bisher nicht.

Zweite Regel: Im erwarteten Ergebnis steht kein Wort, das nur der Programmierer kennt. Ausgeführt wird der Testfall von einem Menschen am Bildschirm. Steht in der Erwartung der Name einer Prozedur, einer Sicht, eines internen Codes oder einer Datenbank-Spalte, kann diesen Testfall nur beurteilen, wer den Code kennt. Er ist dann falsch formuliert. Begriffe, die die Oberfläche selbst verwendet, sind ausdrücklich erlaubt. Diese Regel lässt sich in Sekunden am Text prüfen, ohne den Code zu kennen. Sie gilt für Testfälle am Bildschirm. Wer von Hand den Zustand einer Datenbank nach einem Lauf prüft, braucht genau dieses Vokabular, denn dort ist es der Gegenstand.

Dritte Regel: Jeder Testfall enthält mindestens eine Aussage darüber, was nicht passieren darf. Ein Testfall, der an der Umsetzung entlanggeschrieben wurde, beschreibt den Weg, den es gibt. Die erzwungene Verneinung holt einen Teil des Rests zurück. Im Beispiel oben sind es zwei: keine Meldung bei einer gültigen Regel und keine Doppelung nach dem Neuladen. In einem Testfall zur Scroll-Position deckt genau eine solche Aussage, nämlich dass der Sprung nur einmal passiert, eine Nachbesserung ab, die der Hauptweg nicht abdeckt. Eine Verneinung, die nur die Regel erfüllt, ist allerdings wertlos. Sie muss etwas ausschließen, das bei dieser Funktion naheliegt.

Vierte Regel: Wo der Zeitpunkt zählt, gehört er in die Erwartung. Beim Formulieren des Beispiel-Testfalls stand zuerst der Satz „Die Meldung erscheint“ in der Erwartung. Dabei stellte sich die Frage: wann genau? Erst diese Frage machte den Fehler sichtbar. Die Meldung erschien tatsächlich, aber erst, nachdem der Nutzer die Ansicht verlassen und wieder betreten hatte. Ohne aufgeschriebenen Testfall wäre das als „sie kommt ja“ durchgegangen. Der Fehler dahinter hatte zwei voneinander unabhängige Ursachen, und die Erwartung „sofort, ohne Wechsel der Ansicht“ steht seitdem im Testfall.

Kernaussage: Am meisten schadet die Verzerrung in der Erwartung. Deshalb steht sie vor dem Code fest, und sie ist so formuliert, dass ein Mensch ohne Kenntnis des Codes sie beurteilen kann. Frei von Verzerrung ist auch die Folge der Klicks nicht, denn sie beschreibt nur den Weg, den es gibt. Eine zweite Person ersetzen die Regeln nicht vollständig.

Woher die Testfälle kommen

Ein Testfall hat im DI²-Katalog zwei mögliche Anlässe. Er entsteht aus einer Anforderung und prüft dann eine Zusage. Oder er entsteht aus einem Fehler und sichert dann einen bekannten Schaden ab. Ein Testfall der ersten Art fragt nach etwas, das noch niemand geprüft hat. Ein Testfall der zweiten Art fragt vor allem danach, ob sein Fehler wiederkommt. Etwas Neues findet er nur, wenn es auf seinem Weg liegt.

Im Katalog des DI²-Projekts gibt es für die Herkunft kein eigenes Feld. Sie ergibt sich aus dem Feld Bezug: Nennt es einen Fehler, ist der Testfall aus einem Fehler entstanden. Die Übersicht des Katalogs führt in einer eigenen Zeile, wie viele der aktiven Testfälle so entstanden sind, zuletzt 27 von 32. Diese Zeile wird nicht von Hand gepflegt. Die automatische Formprüfung des Katalogs rechnet sie bei jeder Änderung nach, denn eine Zahl, die sich aus anderen Angaben ergibt und trotzdem von Hand gepflegt wird, stimmt nach einigen Wochen nicht mehr.

Der Anteil der Testfälle aus einem Fehler sagt etwas über die Zusammensetzung des Katalogs, nicht über seine Qualität und nicht über die Disziplin dahinter. Die Praxis war bei der letzten Zählung drei Wochen alt, und dass ein junger Katalog überwiegend aus Fehlern entsteht, ist zu erwarten: Ein eingetretener Schaden ist der naheliegendste Anlass, überhaupt einen Testfall zu schreiben. Die Aussage lautet deshalb nicht, dass 27 von 32 zu viele sind. Sie lautet, dass ein hoher Anteil eine Folge hat: Der Katalog fragt vor allem nach Fehlern, die schon einmal aufgetreten sind. Die zwei Testfälle aus dem vorigen Abschnitt haben den Anteil zum ersten Mal sinken lassen. Zwei Testfälle aus einer Anforderung sind aber noch keine Entwicklung.

Der erste vollständige Lauf des Katalogs vom 13. bis zum 15. September passt dazu und zeigt zugleich eine Gegenseite. Alle 30 aktiven Testfälle liefen. In diesen drei Tagen fielen 19 Fehler in der Anwendung auf, ein schwerer, vier mittlere und 14 leichte. Als Fehler zählt dabei jede Fehler-Datei, die im Lauf angelegt wurde, und die Schwere hat der Agent beim Anlegen nach der Skala des Projekts eingestuft. Nur zwei der 19 Fehler fanden die Testfälle auf die vorgesehene Art, weil ein Schritt nicht das erwartete Ergebnis brachte. Beide Testfälle waren aus einem Fehler entstanden, und beide Funde waren neue Fehler auf ihrem Weg und keine Wiederholung. Die übrigen 17 fielen während des Laufs nebenbei auf: weil während eines Testfalls etwas passierte, das kein Schritt abfragte, beim Herstellen der Ausgangslage, beim Aufräumen, beim erneuten Prüfen eines gerade behobenen Fehlers oder weil der Agent vor einem Testfall den Code las. Die Erwartungen dieses Katalogs fanden also wenig Neues. Der Lauf selbst fand viel. Wie dieser Lauf im Einzelnen verlief und warum dabei 16 der 30 Testfälle selbst geändert wurden, beschreibt der Artikel Die erste Ausführung testet den Testfall.

Kernaussage: Die Herkunft eines Testfalls prägt, wonach seine Erwartung fragt. Der Anteil der Testfälle aus einem Fehler gehört deshalb in die Übersicht des Katalogs, und er gehört automatisch nachgerechnet. Ein hoher Anteil ist kein Mangel. Er passt dazu, dass im ersten vollständigen Lauf fast alle Funde neben den Erwartungen lagen. Ob das eine die Ursache des anderen ist, zeigt ein einzelner Lauf nicht.

Welche Felder ein Testfall braucht und welche nicht

Am 28. August brachte der Maintainer eine Empfehlung eines anderen KI-Werkzeugs mit in die Sitzung. Sie schlug vor, jeden Testfall mit drei Angaben zu versehen: einem Testziel aus einer Tabelle mit 15 Testklassen, von Smoke über Security bis Performance, dazu einer Testebene und einer Priorität. Die Lauf-Klasse des Katalogs mit ihren zwei Werten Smoke und Regression wäre in diesem Testziel nur noch zwei von 15 Klassen gewesen. Seine Frage lautete nicht, ob der Agent das umsetzen könne. Sie lautete, ob es sinnvoll sei, im Katalog schon so weit zu unterscheiden.

Der Agent prüfte die Empfehlung gegen den Bestand und nicht gegen das Lehrbuch. Die Testebene wäre in diesem Katalog bei jedem Testfall dieselbe gewesen, weil er nur enthält, was am Bildschirm geprüft wird. Ein Feld mit genau einem möglichen Wert sagt nichts und kostet trotzdem Pflege. Für große Teile des Testziels gab es im Projekt kein Verfahren: Performance wird (noch) nicht gemessen, für Barrierefreiheit gibt es keinen Ablauf, und Sicherheit prüft ein eigener Skill, der das ganze Projekt durchsieht und im Artikel zur Kontroll-Schleife beschrieben ist. Ein Testfall, der eine solche Klasse im Kopf trägt, verspricht etwas, das niemand einlöst. Die Priorität schließlich hätte eine Frage beantwortet, die zwei Angaben schon beantworten. Was laufen muss, sagen die Lauf-Klasse und die Abdeckung. Eine dritte, von Hand gepflegte Antwort auf dieselbe Frage weicht irgendwann von den ersten beiden ab. Keine der drei Angaben kam deshalb in den Katalog.

Die Liste der Testklassen wurde trotzdem nicht verworfen. Sie dient seitdem als Liste von Fragen beim Schreiben eines Testfalls. Sie beantwortet nicht, wie ein Testfall einzuordnen ist, sondern woran der Schreibende noch nicht gedacht hat:

  • Hauptweg: Tut die Funktion das, wofür sie gebaut wurde?
  • Gegenrichtung: Geht der Zustand auch wieder zurück?
  • Gesperrter Weg: Ist verboten, was verboten sein soll?
  • Zeitpunkt: Wann wird das Ergebnis sichtbar, sofort, nach dem Neuladen oder erst beim erneuten Betreten der Ansicht?
  • Bildschirmgröße: Verhält sich die Seite auf einem kleinen Bildschirm anders?
  • Berechtigung: Sehen und dürfen verschiedene Rollen Verschiedenes?
  • Sprache: Stimmt es auf Deutsch und auf Englisch?
  • Grenzwert: Was passiert genau an der Schwelle und nicht nur weit darüber?
  • Fehlerfall: Was sieht der Nutzer, wenn der Aufruf im Hintergrund scheitert?

Jeder Treffer auf dieser Liste wird im DI²-Katalog ein eigener Testfall und kein weiterer Punkt in einem bestehenden. Sonst ist bei einem Fehlschlag unklar, welche Aussage gebrochen ist, und der Testfall lässt sich nicht gezielt wiederholen. Eine Frage bewusst nicht abzudecken, ist in Ordnung. Dann gehört diese Entscheidung als Satz in den Testfall, damit der nächste Leser sie nicht für ein Versehen hält.

Gegen diese Sparsamkeit gibt es einen ernsthaften Einwand. Die Einteilungen aus den Lehrbüchern sind vollständig, weil sie für jedes Projekt taugen sollen. Wer sie zusammenstreicht, richtet sich nach dem heutigen Stand und zahlt, wenn das Projekt wächst. Das Argument für die Sparsamkeit ist eine Frage des Aufwands und keine des Prinzips. Es gilt bei gut 30 Testfällen und einem Maintainer. Bei 400 Testfällen und drei Teams kann die Rechnung anders ausgehen.

Kernaussage: Eine zusätzliche Einteilung kommt im DI²-Katalog erst in den Kopf eines Testfalls, wenn ihr Wert ändert, wann oder wo der Testfall läuft. Das ist eine Frage des Aufwands bei gut 30 Testfällen und keine allgemeine Regel. Eine Einteilung, die als Pflichtfeld nur Arbeit macht, kann als Liste von Fragen beim Schreiben trotzdem nützen.

Der Lauf ist der Nachweis

Am 29. August stand im DI²-Projekt ein Fehler kurz vor dem Schließen. Der zugehörige Testfall war geschrieben, in der Übersicht geführt und aus dem Fehler verlinkt. In keinem der acht Protokolle, die es bis dahin gab, kam er vor. Aufgefallen ist das durch eine Rückfrage des Maintainers, denn im Ablauf fragt nichts danach. Den ganzen Vorfall und das, was der erste Lauf dieses Testfalls dann zeigte, erzählt der Artikel Die erste Ausführung testet den Testfall.

Die Lücke lag nicht in der Reihenfolge, denn der Testfall war vor dem Schließen geschrieben. Es fehlte der Zwang. Das Werkzeug, mit dem im Projekt Fehler geschlossen werden, prüft, ob die im Fix genannten Dateien wirklich geändert wurden. Ob ein zugehöriger Testfall gelaufen ist, prüft es nicht. Eine Pflicht, die nur als Satz in einer Beschreibung steht, wird irgendwann unbemerkt übersprungen.

Eine harte Sperre wäre trotzdem die falsche Antwort. Ein Testfall am Bildschirm braucht eine Umgebung, in der man klicken kann, und an einem lokalen Arbeitsplatz fehlt manchmal schon die Anmeldung. Eine Sperre erzeugt dann Vorgänge, die fachlich erledigt und formal offen sind. Tragfähig ist nur die Fassung „gelaufen oder als Rückstand sichtbar vermerkt“. Der eigentliche Mangel war nicht der fehlende Lauf. Es war der unsichtbare Rückstand, vergraben im Fließtext eines Prüfberichts. Auf diesen Punkt geht auch der Artikel zur Kontroll-Schleife ein: Ein Urteil reist weiter als der Vorbehalt, der daran hängt.

Stand heute gibt es diese Prüfung im Projekt nicht. Die Pflicht steht weiter als Satz in der Beschreibung, und sie wird gerade befolgt: Der jüngste Fehler wurde erst nach dem bestandenen Lauf geschlossen. Eine zweite Pflicht derselben Art wird weniger gut befolgt. Aus zwei abgeschlossenen Anforderungen mit Kriterien, die als nur am Bildschirm prüfbar markiert waren, ist kein Testfall entstanden.

Auch ein gemeldetes „pass“ ist zunächst eine Zusage des Ausführenden, und der Artikel zur ersten Ausführung zeigt, wie ein Mitschnitt der Datenbank daraus einen Nachweis macht. Für automatisierte Tests gilt eine verwandte Lehre: Ein grüner Test bestätigt zunächst nur die Annahmen, mit denen er geschrieben wurde. Das ist das Thema des Artikels Der grüne Test, der nichts beweist.

Kernaussage: Ein Testfall, der nur geschrieben ist, ist eine Zusage. Erst das Protokoll eines Laufs weist nach, dass er ausgeführt wurde und was dabei zu sehen war. Dass die Anwendung fehlerfrei ist, weist auch ein Protokoll nicht nach. Eine Pflicht zum Ausführen braucht eine Stelle, an der ein Rückstand sichtbar wird, sonst fällt er nur auf, wenn jemand nachfragt.

Arbeits-Prompts als Beispiel

Die Sitzungen sind nicht versioniert. Die zwei Prompts hier sind aus den Regeln des Katalogs und den Notizen zu den Sitzungen rekonstruiert und keine Zitate. Sie zeigen, was der Maintainer verlangt hat, nicht wie der Agent es umgesetzt hat.

Bei der Frage nach den Feldern brachte der Maintainer die fremde Empfehlung mit und ließ sie prüfen, statt sie umsetzen zu lassen:

Hier ist eine Empfehlung zur Einteilung von Testfällen aus einem anderen
Werkzeug: <Liste einfügen>

Macht es Sinn, das bei uns schon einzuführen? Bewerte gegen unseren
tatsächlichen Bestand, nicht gegen das Lehrbuch. Abnahme: Nenne mir für jede
vorgeschlagene Angabe, welche Werte sie bei unseren heutigen Testfällen hätte
und welche Angaben bei allen denselben Wert bekämen.

Die Antwort nannte für jede Angabe die Werte im Bestand, und daran wurde sichtbar, dass die Testebene überall denselben Wert hätte. Aus dieser Antwort ist die Liste der Fragen beim Schreiben entstanden.

Beim Einwand zur fehlenden zweiten Person ließ der Maintainer die Schieflage zuerst messen:

Prüf unseren Bestand an Testfällen auf zwei Fragen und antworte mit Zahlen:
1. Wie viele wurden vor, wie viele nach der Umsetzung geschrieben?
2. Wie viele gibt es nur, weil vorher ein Fehler aufgetreten ist?

Abnahme: zwei Zahlen, jede hergeleitet aus einer Angabe, die in den Dateien
steht. Wenn du eine Zahl nicht aus den Dateien ableiten kannst, sag das und
rate nicht.

Das Ergebnis war „keiner vor der Umsetzung“ und „5 von 7“. Erst diese zweite Zahl hat aus einem Austausch von Meinungen eine Entscheidung gemacht.

Was am Ende trägt

Die Erwartung steht in der Anforderung, die Folge der Klicks kommt aus der fertigen Oberfläche, und das Protokoll entsteht erst mit dem Lauf. Wer diese drei Dinge auseinanderhält, schreibt Erwartungen, die nicht vom Code abgeschrieben sind. Eine solche Erwartung kann auch dann fehlschlagen, wenn der Code von Anfang an etwas anderes tut, als die Anforderung zusagt. Eine zweite Person ersetzt das nicht ganz, und der eine Fall im DI²-Projekt, in dem die Erwartung wirklich vor dem Code feststand, hat genau das gezeigt.

Bevor ein Testfall in den Katalog kommt, lohnen sich fünf Fragen:

FrageWoran man es prüft
Kommt die Erwartung aus der Anforderung?Der Bezug nennt das Kriterium, und die Erwartung lässt sich darauf zurückführen.
Stehen Schritt und Erwartung nebeneinander?Jede Zeile der Tabelle hat beides oder bewusst einen Strich.
Ist der Zeitpunkt benannt, wo er zählt?Die Erwartung sagt, wann etwas sichtbar wird, nicht nur dass.
Gibt es eine Aussage darüber, was nicht passieren darf?Mindestens eine Erwartung ist eine Verneinung.
Ist der Testfall einmal gelaufen?Er steht in einem Protokoll.

FAQ

Was gehört in einen manuellen Testfall?

In einen manuellen Testfall gehören ein Kopf mit den Angaben, wann er fällig ist und worauf er sich bezieht, das Ziel in einem Satz, die Vorbedingung, der Ablauf als Tabelle und das Aufräumen. In der Tabelle steht jeder Schritt neben seinem erwarteten Ergebnis. Datum, Ergebnis und Umgebung eines Laufs gehören nicht hinein, sie stehen im Protokoll. Eine Vorlage zum Übernehmen zeigt der Abschnitt zum Aufbau.

Was unterscheidet einen Testfall von einem automatisierten Test?

Ein automatisierter Test läuft bei jeder Änderung von selbst und endet grün oder rot. Ein manueller Testfall ist ein aufgeschriebener Ablauf mit Erwartungen, den ein Mensch am Bildschirm ausführt und protokolliert. In einen Katalog manueller Testfälle gehört nur, was ein Programm nicht zuverlässig selbst prüfen kann, etwa der Moment, in dem eine Meldung erscheint.

Wer soll die Testfälle schreiben, wenn es nur eine Person und einen Coding-Agenten gibt?

Es bleibt nur der Agent, und das ist das Problem, denn er hat auch den Code geschrieben. Im DI²-Projekt wird die fehlende zweite Person durch einen zeitlichen Abstand ersetzt: Die Erwartung steht als Kriterium in der Anforderung, bevor der Code entsteht. Das soll die Verzerrung abschwächen, beseitigen kann es sie nicht. Das Urteil am Bildschirm bleibt beim Menschen.

Wie viele Testfälle braucht ein Katalog?

Die Zahl sagt wenig. Aussagekräftiger sind zwei andere Angaben: wie viele Testfälle aus einer Anforderung entstanden sind und nicht aus einem Fehler, und wie viele mindestens einmal in einem Protokoll stehen. Im DI²-Projekt waren zuletzt 27 von 32 Testfällen aus einem Fehler entstanden. Im ersten vollständigen Lauf fanden die Erwartungen dieses Katalogs zwei von 19 Fehlern, alle anderen fielen nebenbei auf.

Braucht ein Testfall eine Priorität?

Nur, wenn sie eine Entscheidung ändert. Im DI²-Katalog sagt die Lauf-Klasse, was bei jeder Auslieferung laufen muss, und die Abdeckung sagt, was nach einer Änderung fällig ist. Eine Priorität wäre eine dritte, von Hand gepflegte Antwort auf dieselbe Frage. Eine neue Einteilung lohnt sich dort erst, wenn zwei Testfälle verschiedene Werte bekämen und der Wert ändert, wann oder wo der Testfall läuft.

Verwandte Artikel

Spokes dieses Artikels:

Übergeordnet:

Kontrolle und Regeln:

Nebenan: