Antwort.

Mehrstufige Formulare (Assistenten, Multi-Step-Formulare) sind ein alltägliches Phänomen bei der Registrierung, der Kontoeinrichtung und langwierigen Geschäftsprozessen (z.B. der Beantragung eines Kredits oder der Bestellung von Dienstleistungen). Ihr manuelles Testen ist fehleranfällig und zeitaufwändig; die Automatisierung spart hier Ressourcen und gewährleistet die Abdeckung aller "eckigen" Szenarien.

Historie des Themas: Seit der Einführung von Assistenten und langen Formularen wurden solche Szenarien am häufigsten nur durch manuelles Testen abgedeckt. Mit dem Aufkommen von Frameworks wie Selenium, Cypress und Playwright wurde es möglich, komplexe mehrstufige Geschichten automatisch zu reproduzieren, was die Stabilität der Software erheblich erhöhte und die Anzahl der regressiven Defekte reduzierte.

Problem: Assistenten und lange Formulare unterliegen häufig Änderungen in der Logik (Schritte kommen hinzu/verschwinden, Validierungsbedingungen ändern sich, dynamische Felder erscheinen). Es ist wichtig, die Stabilität der Tests bei solchen Änderungen zu gewährleisten. Die Hauptprobleme: Zerbrechlichkeit der Locator aufgrund der dynamischen Natur der Schritte, korrekte Handhabung des Wechsels zwischen den Schritten, Verwaltung von Testdaten, Emulation von Benutzerfehlern sowie das Klicken auf nichtlineare Szenarien mit Rückgaben und verändertem Zustand.

Lösung: Es wird das Step-Object-Muster (eine Erweiterung des Page-Object-Musters) verwendet, das es ermöglicht, die Logik der Arbeit mit jedem Schritt in separate Entitäten zu zerlegen. In den Tests sollten alle möglichen Szenarien einschließlich Rückgaben und falscher Daten implementiert werden. Zur Erhöhung der Stabilität werden dynamische Erwartungen und Suchmethoden verwendet, die nicht von der Position auf der Seite abhängen. Die Testdaten werden so strukturiert, dass sie umfassend alle Verzweigungen der Logik abdecken.

Schlüsselfeatures:

Implementierung des Step-Object für jeden Schritt.
Überprüfung nicht nur der "grünen Wege", sondern auch alternativer, fehlerhafter Durchgänge (Eingabe fehlerhafter oder Grenzdaten).
Verwendung eines data-driven Ansatzes: Gestaltung der Szenarien basierend auf einem Array von Testdaten für eine maximale Abdeckung der Logikübergänge.

Fangfragen.

Fangfrage 1

"Reicht es aus, nur den Happy Path (hauptsächliche Benutzerszenarien) abzudecken, wenn das Formular stabil ist?"

Antwort: Nein, oft treten Fehler gerade bei der Verarbeitung unerwarteter Szenarien auf — Rückgaben, das Überspringen von Schritten, Grenzwerte. Ohne diese Tests gibt es keine vollständige Sicherheit in Bezug auf die Stabilität.

Fangfrage 2

"Kann man Übergänge zwischen den Schritten nur durch den Wechsel der URL umsetzen?"

Antwort: Nicht immer. Viele Assistenten verwenden dynamische Routen oder werden nur durch internen JS-Zustand gesteuert, weshalb Klicks und Interaktionen wie ein echter Benutzer nachgebildet werden müssen.

Fangfrage 3

"Das Management von Testdaten spielt keine wesentliche Rolle, wenn alle Schritte obligatorisch und statisch sind?"

Antwort: Falsch. Selbst für statische Formulare kann unterschiedliche Datenfütterung zu völlig unterschiedlichen Reaktionen, dem Auftreten von Hinweisen, Fehlern und dynamischen Hinweisen führen.

Typische Fehler und Anti-Patterns

Speicherung aller Logik des mehrstufigen Assistenten in einem einzigen langen Test („Monolith“), anstatt auf Schritte/Komponenten aufzuteilen.
Fehlen der Generierung negativer Szenarien, der Abdeckung von Grenzfällen und Rückgaben.
Bindung der Tests an instabile Locator/Positionen der Elemente.

Beispiel aus dem Leben

Negativer Fall

In der Automatisierung des Prozesses einer Bankbewerbung wurde ein einziger End-to-End-Test auf den Happy Path geschrieben, ohne Rückgaben und Fehler. Bei der Änderung eines der Schritte (Hinzufügen eines dynamischen Blocks) versagte der Test nicht nur, sondern erkannte auch keine Fehler beim Rückwechsel zum vorherigen Schritt oder der Verarbeitung fehlerhafter Daten.

Vorteile:

Schnelle Abdeckung der Hauptszenarien.

Nachteile:

Jede Änderung des Formulars erforderte eine vollständige Bearbeitung des langen Tests.
Kritische Fehler wurden nicht getestet – insbesondere an "Verzweigungen" und seltenen Fällen.

Positiver Fall

Eine Struktur des Step-Objects wurde implementiert, jeder Schritt wurde durch einen separaten Test abgedeckt, dem Assistenten wurden Rückgaben, Fehler und Wechsel zwischen verschiedenen Verzweigungen simuliert. Alles wurde über Datensätze verwaltet. Neue Schritte oder Änderungen ruinierten nicht den Wert der Testbasis.