Field Note: Warum „funktioniert bei mir“ kein Testverfahren ist

Ich teste lieber Bedingungen als Behauptungen

Ich teste mittlerweile weniger, ob eine Funktion funktioniert, und stärker, unter welchen Bedingungen sie nicht funktioniert. „Bei mir geht es“ ist eine Beobachtung. Ein Testverfahren wird daraus erst, wenn klar ist, in welchem Zustand ich geprüft habe und was genau dabei funktionieren sollte.

Der Unterschied klingt klein, verändert aber den Blick auf digitale Systeme. Eine Funktion steht selten für sich allein. Sie hängt an einem Zugang, einer Rolle, einem Gerät, einem Browser, einem Datenbestand und manchmal auch daran, was vorher schon im System passiert ist. Ändert sich eine dieser Bedingungen, kann sich auch das Ergebnis ändern.

Das heißt nicht, dass jede Prüfung kompliziert oder vollständig sein muss. Es heißt für mich zunächst nur: Ich sollte wissen, was meine Beobachtung tatsächlich belegt. Wenn ich als eingeloggter Admin am Desktop eine Seite öffne, weiß ich danach noch nicht, ob ein Kunde dieselbe Ansicht erhält, ob die Seite mobil nutzbar ist oder ob ein ausgeloggter Besucher denselben Weg durchlaufen kann.

Der erste Impuls ist oft zu eng

Mein erster Impuls war lange, den beschriebenen Ablauf nachzustellen: Seite öffnen, Funktion ausführen, Ergebnis ansehen. Wenn es klappte, war die Sache für diesen Moment erledigt. Das ist nicht wertlos. Es beantwortet aber nur eine begrenzte Frage: Funktioniert dieser Ablauf in genau diesem Zustand?

Was mich misstrauisch macht, sind die kleinen Unterschiede, die dabei unsichtbar bleiben. Eingeloggt oder ausgeloggt. Admin oder Kunde. Desktop oder Mobil. Safari oder Chrome. Cache oder kein Cache. Bestehender oder neuer Nutzer. Echte Daten oder Testdaten.

Diese Unterschiede sind keine Liste von Sonderfällen, die man mechanisch vollständig abhaken muss. Sie sind Hinweise darauf, an welchen Stellen sich der Zustand des Systems verändert. Eine Rolle kann andere Rechte haben. Ein neuer Nutzer kann andere Ausgangsdaten mitbringen als ein bestehender. Ein Browser kann einen anderen gespeicherten Zustand verwenden. Und Testdaten können einen Weg abbilden, der mit echten Daten so nicht vorkommt.

Was ich zuerst prüfe: Welche Bedingungen müssen erfüllt sein, damit der Ablauf funktioniert? Und welche davon waren in meinem eigenen Test stillschweigend gesetzt?

Ein Test braucht einen Zustand

Wenn ein Test fehlschlägt oder gelingt, hilft mir die Aussage allein wenig. Ich brauche den Zustand, in dem das Ergebnis entstanden ist. Nicht als aufwendige Dokumentation für jeden Klick, sondern so konkret, dass ich den Unterschied zwischen zwei Prüfungen erkennen kann.

Dazu gehört, wer den Ablauf ausführt, mit welchem Zugang und von welchem Gerät aus. Ebenso wichtig ist, ob die Daten neu angelegt oder schon vorhanden sind und ob ein Cache das angezeigte Ergebnis beeinflussen kann. Je nach Funktion kommen weitere Bedingungen hinzu. Entscheidend ist nicht, möglichst viele Begriffe aufzuschreiben. Entscheidend ist, die Bedingungen festzuhalten, die das Ergebnis verändern können.

Dann lässt sich eine Beobachtung besser einordnen. Wenn etwas im einen Zustand funktioniert und im anderen nicht, ist das kein Widerspruch, den ich wegmoderieren sollte. Es ist ein Signal: Zwischen diesen Zuständen gibt es einen Unterschied, den das System offenbar relevant behandelt. Der nächste Schritt ist, diesen Unterschied einzugrenzen.

Ich versuche deshalb, nicht mehrere Bedingungen gleichzeitig zu verändern, wenn ich eine Ursache verstehen will. Wechsle ich zugleich Rolle, Browser und Datenbestand, weiß ich am Ende zwar, dass das Ergebnis anders ist, aber nicht, welcher Unterschied dafür ausschlaggebend war. Ein sauberer Vergleich hält möglichst viel konstant und verändert gezielt das, was ich prüfen möchte.

Nicht alle Kombinationen sind gleich wichtig

Es wäre einfach, aus den möglichen Unterschieden eine große Matrix zu machen und jede Kombination zu testen. In der Praxis wäre das oft mehr Aufwand als Erkenntnis. Nicht jede Funktion hängt von jeder Bedingung ab. Ein rein redaktioneller Ablauf braucht möglicherweise eine andere Prüfung als ein Bereich, in dem Kunden eigene Daten sehen oder bearbeiten.

Ich frage deshalb zuerst, welche Zustände für die Funktion tatsächlich relevant sind. Wenn eine Ansicht unterschiedliche Rechte berücksichtigt, sind die Rollen wichtig. Wenn eine Eingabe auf verschiedenen Geräten genutzt wird, gehört die mobile Darstellung zur Prüfung. Wenn ein Ablauf Daten anlegt oder verändert, ist der Unterschied zwischen einem neuen und einem bestehenden Nutzer naheliegend. Und wenn die Anzeige gecacht werden kann, sollte ich wissen, ob ich gerade den aktuellen Zustand oder eine gespeicherte Antwort sehe.

Das ist für mich keine Garantie, alle Fehler zu finden. Es ist eine bessere Ausgangslage, um die wichtigen Wege bewusst zu prüfen. Ich teste nicht einfach mehr, sondern gezielter: Welche Annahme steckt in diesem Ablauf? Was muss gleich bleiben, damit ich das Ergebnis vergleichen kann? Und welche Änderung würde meine Schlussfolgerung widerlegen?

Was ich heute anders mache

Eine Sache hat sich bei mir verändert: Ich betrachte einen erfolgreichen Durchlauf nicht mehr als Abschluss, sondern als einen Beleg für einen bestimmten Zustand. Danach prüfe ich, welche nahegelegenen Bedingungen ebenfalls relevant sind und ob sich das erwartete Ergebnis dort verändert.

Das bedeutet auch, Fehlerberichte anders zu lesen. „Bei mir geht es“ und „bei mir geht es nicht“ können beide stimmen, wenn zwei Personen nicht denselben Zustand geprüft haben. Statt die Aussagen gegeneinanderzustellen, suche ich nach dem Unterschied: Zugang, Rolle, Gerät, Browser, Cache, Nutzerstatus oder Daten. Oft ist die genauere Frage hilfreicher als die erste Vermutung über die Ursache.

Inzwischen versuche ich, den erwarteten Ablauf und die Bedingungen vor dem Test zu benennen. Danach vergleiche ich die Beobachtung mit dieser Erwartung. Wenn etwas nicht passt, ändere ich nicht sofort mehrere Dinge auf einmal. Ich prüfe, welche Bedingung den Unterschied erklären könnte, und wiederhole den Vergleich so, dass die Aussage belastbarer wird.

Das ist ein unspektakulärer Teil der Arbeit. Aber er verändert, worauf ich mich verlasse. Eine Funktion, die einmal sichtbar funktioniert hat, ist nicht automatisch unter anderen Rollen, auf anderen Geräten oder mit anderen Daten geprüft. Umgekehrt ist ein Fehler unter einer bestimmten Bedingung nicht automatisch ein Fehler überall. Beides muss ich auseinanderhalten können.

Meine Faustregel: „Funktioniert bei mir“ gilt nur für den Zustand, den ich tatsächlich geprüft habe. Für alles andere formuliere ich eine neue Frage und teste die Bedingungen, die das Ergebnis verändern können.

Weiterführend

• Know → Change → Prove: Wie WordPress-Änderungen sicher werden
• WordPress technisch dokumentieren: Was eine gute Systemdokumentation enthalten sollte