Die drei Laufzeitfehler, die Web-App-Testing abdecken muss
Zurückgebliebener Zustand
Ein Modal schließt sich und hinterlässt eine Scroll-Sperre. Ein Filter bleibt bestehen, wo er keinen Sinn mehr ergibt.
Zeigt sich erst bei der zweiten Interaktion, weshalb ein frischer Reproduktionsversuch ihn nie findet.
Rendern vor den Daten
Die Seite ist gezeichnet, der Fetch kommt zurück, nichts wird neu gerendert.
Meist sporadisch, weshalb es jedes Review übersteht.
Der zweite Nutzer
Annahmen über Besitz und Sichtbarkeit, die aus der eigenen Session des Entwicklers stammen.
Funktioniert einwandfrei für alle, die es gebaut haben.
Die Prüfung, die das meiste davon findet
Führen Sie die Aktion zweimal aus, als zwei verschiedene Nutzer, mit einem Reload dazwischen. Dieses eine Muster trifft alle drei Kategorien – und genau das überspringt manuelles Testen, weil der erste Versuch ja funktioniert hat.
Worauf Sie prüfen sollten
Auf etwas, das ein Reload bestätigen würde. Eine Erfolgsmeldung ist kein Beleg dafür, dass irgendetwas gespeichert wurde. Rufen Sie es erneut ab.
Auf das Fehlen dessen, was nicht da sein sollte. Nach dem Löschen ist die Zeile verschwunden. Nach dem Abmelden sind die Daten nicht mehr sichtbar.
Auf das Verhalten für jemand anderen. Das zweite Konto kann die Datensätze des ersten Kontos nicht sehen.
Welche Rolle die lokale Entwicklung spielt
Die Arbeit an einer Web-App findet auf localhost statt, lange bevor irgendetwas deployt wird, und eine Prüfung, die nur gegen eine öffentliche URL funktioniert, kommt zu spät, um noch zu beeinflussen, was Sie bauen. Für Frontend-Läufe kann die CLI einen Tunnel zu einer App auf Ihrem eigenen Rechner aufbauen, sodass die Prüfung schon während der Arbeit verfügbar ist. Details finden Sie im CLI-Repository.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Das Dashboard deckt dasselbe ab, wenn Sie keine lokale Installation möchten.
Der Zwei-Tab-Test
Es gibt eine manuelle Prüfung vor jedem Release, die mehr findet, als sie kostet, und fast niemand führt sie durch: Öffnen Sie die App in zwei Tabs.
Machen Sie etwas im ersten Tab und sehen Sie dann im zweiten nach. Die meisten Web-Apps verhalten sich hier auf irgendeine Weise schlecht, und die Art des Fehlverhaltens ist aufschlussreich. Eine Liste, die sich nicht aktualisiert, ist meist unproblematisch. Eine veraltete Aktion, die durchgeht und neuere Daten überschreibt, ist ein echter Bug. Eine Session, die einen Tab abmeldet, sobald der andere ein Token erneuert, ist ein echter Bug. Ein optimistisches Update, das nie abgeglichen wird, ist ein echter Bug.
Das dauert zwei Minuten, braucht kein Tooling und trifft genau die Nahtstelle, an der Server-Zustand, Browser-Zustand und Nutzererwartung auseinandergehen. Wenn Sie von dieser Seite nur eine einzige Gewohnheit übernehmen, dann diese.
Machen Sie es kontinuierlich
Laufzeitfehler sind genau die Fehler, die wiederkommen, weil sich die Bedingungen, die sie erzeugen, leicht versehentlich wiederherstellen lassen.
Die GitHub App ist ein Webhook, den Sie im TestSprite-Dashboard einrichten. Sie lauscht auf das Deployment-Event, das Ihre Pipeline ohnehin schon erzeugt, sodass sich in Ihrem Repository nichts ändert.
GitHub Actions bringt den Schritt in Ihren eigenen Workflow, konfiguriert aus dem Terminal.
Wie TestSprite die laufende App durchspielt
TestSprite öffnet die deployte Anwendung und bedient sie so, wie es ein Mensch tun würde – nur so werden zurückgebliebener Zustand, Rendern vor den Daten und das Verhalten für den zweiten Nutzer sichtbar. Die Testfälle sind in natürlicher Sprache beschrieben und werden aus Ihrem Produkt generiert; geprüft wird auf das, was ein Reload bestätigen würde, und nicht auf eine Meldung, die der Client gerendert hat.
Die Prüfung für den zweiten Nutzer ist dabei ein vollwertiger Testfall und keine Setup-Fleißaufgabe. Das ist wichtig, weil Annahmen über Berechtigungen der Fehler sind, der am ehesten beim Kunden ankommt und demjenigen, der das Feature gebaut hat, am wenigsten auffällt.
Die Prüfungen laufen anschließend bei jeder Änderung weiter, sodass die Widersprüche zwischen den drei Zuständen, die einmal einen Bug verursacht haben, nach dem Merge des Branches nicht unbemerkt zurückkehren können.
Warum tauchen diese Fehler im Code-Review nicht auf?
Weil sie Eigenschaften eines Zusammenspiels von Server-Zustand, Browser-Zustand und Verlauf sind. Ein Diff zeigt davon nichts.
Können wir das mit Unit-Tests testen?
Teilweise, mit viel Mocking – und die Mocks kodieren dieselben Annahmen wie der Code. Den Ausschlag gibt erst der Lauf gegen die echte Anwendung.
Wie testen wir den zweiten Nutzer zuverlässig?
Halten Sie pro Umgebung ein zweites Konto vor und durchlaufen Sie denselben Flow mit beiden. Das ist die günstigste Prüfung mit hohem Ertrag im Web-App-Testing.
Was ist mit mobilen Browsern?
Unterschiedliche Viewports bringen eine eigene Klasse von Layout- und Interaktionsproblemen ans Licht. Wenn Sie mobilen Traffic haben, lohnt es sich, die wichtigsten Flows in mobiler Größe abzudecken.
Wie viel davon läuft lokal?
Frontend-Läufe erreichen eine App auf Ihrem Rechner über einen Tunnel. Backend-Ziele, die nicht erreichbar sind, brauchen weiterhin eine öffentlich zugängliche Umgebung.
Führen Sie es zweimal aus, als zwei Nutzer, mit einem Reload.
Web-App-Testing muss zurückgebliebenen Zustand, Rendern vor den Daten und das Verhalten für den zweiten Nutzer abdecken – nichts davon ist im Quellcode sichtbar. Prüfen Sie auf das, was ein Reload bestätigt, prüfen Sie das Fehlen dessen, was verschwunden sein sollte, und durchlaufen Sie denselben Flow als jemand anderes.