Effiziente Formulartests

Modellbasiertes Formulartesten bezeichnet einen Ansatz, bei dem Daten- und UI-Modelle einer Low-Code-Plattform automatisch Testdatensätze und UI-Lokalisatoren erzeugen. Ein SMT-Solver berechnet valide Testdatensätze aus Validierungs- und Berechnungsregeln. Daraus generierter Code befüllt Formulare mit hunderten Feldern und tausenden Regeln vollautomatisch, statt manuell oder mit wartungsintensiven Einzeltests.

Das Wichtigste in Kürze

• Über 255 Formularvariantenten auf 16 Bundesländer, mit jeweils mehr als 100 Feldern pro UI und einzelnen Formularen mit bis zu 100.000 Feldern, machen manuelles Testen praktisch unmöglich.
• Ein SMT-Solver-basierter Testdatengenerator erkennt widersprüchliche Validierungsregeln bereits beim Generieren und verhindert so, dass fehlerhafte Modelle überhaupt deployed werden.
• Aus dem UI-Modell der Low-Code-Plattform lassen sich Selektoren und Testcode automatisch ableiten, sodass ein gesamtes Formular mit einer einzigen Codezeile befüllt oder geprüft werden kann.
• Was manuell mehrere hundert Stunden Testaufwand erfordern würde, läuft automatisiert in zwölf bis vierzehn Stunden pro Bundesland ab.

Warum sich behördliche Formulare manuell kaum noch testen lassen

Behördliche Steuerformulare erreichen eine Kombinatorik, die manuelles Testen unmöglich macht. Das Beispielprojekt umfasst über 255 Formularvarianten, verteilt auf 16 Bundesländer. Jedes Bundesland hat seine eigene Variante, und jedes Formular trägt über 100 Felder auf der Oberfläche.

Bei einzelnen Steuerarten wächst diese Dimension weiter. Ein Buchstaben-Steuerformular kommt auf rund 2400 Felder und etwa 2200 Validierungs- und Berechnungsregeln. Eine bestimmte Steuer erreicht sogar bis zu 100.000 Felder. Solche Mengen übersteigen jede menschliche Kapazität, ein Formular einfach von oben nach unten durchzuspielen.

Hinzu kommt die ständige Änderung. Die Fachlichkeit ändert sich pro Jahr und pro Bundesland. Selbst ein einmal gefundener gültiger Testdatensatz verliert seine Gültigkeit wieder, sobald sich eine Regel verschiebt. Der Aufwand schießt damit in jede Richtung nach oben.

Selbst wenn ich einen validen Testdatensatz finde, der alles validiert, das ändert sich ständig. Die Aufwände gehen sofort in die Decke, in jede Richtung.

Lilia Gargouri

Die Wartungsfalle trifft auch automatisierte Tests

Wer einfach anfängt, die Oberfläche zu automatisieren, löst das Problem nicht, sondern verschiebt es. Schon das Automatisieren eines einzelnen Happy Path landet bei dieser Formularvielfalt direkt in der Wartungsfalle. Zur Implementierung eines einzigen Testfalls kommen die laufenden Pflegekosten, sobald sich Felder oder Regeln ändern.

Der zweite Engpass liegt davor: Bevor ein Tester überhaupt prüfen kann, braucht er einen gültigen Testdatensatz. Dieser Schritt blockiert beide Wege gleichermaßen, das manuelle und das automatisierte Testen. Ohne valide Daten kommt kein Test ins Laufen.

Die Konsequenz für das Projekt war klar. In Vier-Wochen-Sprints mit Release am Ende muss alles durchgetestet sein, und eine gleichmäßige Testabdeckung über das gesamte Projekt zu erreichen, wird mit jeder zusätzlichen Formularvariante schwerer.

Modelle als Quelle für Tests nutzen

Der Lösungsansatz von Lilia Gargouri und Simon Bergler setzt an den Modellen an, die ohnehin existieren. Die Plattform ist mit einer Low-Code-Plattform entwickelt, in der jede Fachlichkeit zuerst modelliert wird. Hinter jedem Formular liegen zwei Modelle: ein Datenmodell und ein UI-Modell, jeweils als JSON-Datei.

Das Datenmodell enthält die Felder sowie die Validierungs- und Berechnungsregeln. Die Sachbearbeiter und Business-Analysten gießen die Fachlichkeit hier hinein, statt sie zu implementieren. Sie definieren etwa ein String-Feld für den Namen oder ein Date-Feld für ein Datum und formulieren Regeln in einer Regelsprache der Plattform.

Ein einfaches Beispiel: Ist ein Name angegeben, aber kein Geburtsdatum, feuert eine Regel mit der Fehlermeldung, das Geburtsdatum einzutragen. Genau dieses Regelwerk macht das Modell zur idealen Quelle für Tests. Wer 2200 Regeln stattdessen klassisch ausprogrammieren wollte, würde an Implementierung und Wartung scheitern.

Wie aus dem Datenmodell gültige Testdaten entstehen

Aus dem Datenmodell generiert das Team automatisch gültige Testdatensätze mit hoher Abdeckung. Die JSON-Datei wird dazu in ein arithmetisches Modell konvertiert. Ein SMT-Solver aus dem Open-Source-Bereich löst dieses Gleichungssystem und findet einen Testdatensatz mit möglichst vielen belegten Feldern.

Den Open-Source-Solver hat das Team um projektspezifische Validierungen ergänzt, etwa für die Belegung der Steuernummer. Das Ergebnis landet in einer Excel-Datei: Jede Spalte ist ein vollständiger, gültiger Testdatensatz, sofort verwendbar für manuelles oder automatisiertes Testen.

Dieser Schritt bringt einen Nebeneffekt, der früh Fehler aufdeckt. Schließen sich Regeln im Modell versehentlich gegenseitig aus, kracht es bereits bei der Testdatengenerierung. Der Solver findet keine Lösung, und der Modellierungsfehler wird sichtbar, bevor die JSON-Dateien deployt werden.

Ändert sich die Fachlichkeit, ändern sich die Regeln, und das Team generiert die Testdaten einfach neu. Die bestehenden Tests laufen danach sofort wieder.

Das UI-Modell liefert den Code für die Oberflächentests

Der zweite generische Ansatz extrahiert die Automatisierung der Oberfläche direkt aus dem UI-Modell. In diesem Modell legen die Modellierer fest, welche Labels ein Feld trägt, wie Felder gruppiert werden, ob ein String-Feld als Textfeld oder Textarea erscheint und ob eine Auswahl als Checkbox oder Radio-Button dargestellt wird.

Aus diesem Modell zieht das Team alle Informationen für die UI-Testautomatisierung. Für die Befüllung braucht es weder die Validierungen noch die Regeln, denn beim reinen Ausfüllen ist es egal, ob die eingegebenen Daten valide sind. Aus den Felddefinitionen entstehen die Selektoren beziehungsweise Lokatoren für das eingesetzte Werkzeug.

Jedes Element wird über die Kombination aus Feldtyp und Überschrift identifiziert, etwa ein Textfeld mit dem Label “Name”. Eine Bibliothek hält zu jedem Feldtyp die passende Methode bereit, die das Element befüllen oder prüfen kann. Für ein Textfeld holt sie genau die Methode, die ein Textfeld bedient.

Zwei Zeilen Code für ein ganzes Formular

Für den Tester schrumpft der Aufwand auf wenige Zeilen. Ein Befehl lautet sinngemäß “befülle das Formular”. Das Werkzeug liest die Excel-Datei mit den gültigen Testdatensätzen und arbeitet das Formular blind von oben nach unten ab.

Eine zweite Zeile prüft das gesamte Formular und stellt sicher, dass tatsächlich darin steht, was erwartet wird. Zwei Zeilen Code als Vorbereitung decken damit ein komplettes Formular ab, unabhängig von der Zahl seiner Felder.

Diese Flexibilität erlaubt verschiedene Testtiefen mit demselben Code. Der Tester kann den gesamten Prozess durchlaufen, also ein Formular erstellen, ausfüllen, abschließen und archivieren. Er kann aber auch nur bis zu einer bestimmten Stelle gehen, diesen Lauf als Vorbereitung nutzen und ab dort manuell oder mit einem gezielten Feature-Test ansetzen.

Was der modellbasierte Ansatz an Zeit spart

Die Testdauer zeigt, warum manuelles Testen hier keine Option ist. Lässt man alle automatisierten Tests für ein einziges Bundesland laufen, kommt man auf 12 bis 14 Stunden Gesamttestdauer. Hochgerechnet auf 16 Bundesländer ergibt das den echten Testaufwand.

Übersetzt in manuelle Arbeit wäre der Aufwand um ein Vielfaches höher, geschätzt mehrere hundert Stunden, mindestens rund 500. Das automatisierte Werkzeug testet dagegen schnell und gleichmäßig.

An konkreten Tests hat das Team in kurzer Zeit 300 bis 400 Stück aufgebaut, dazu rund 20 dedizierte Feature-Tests. Vieles davon wird recycelt, weil sich die Bausteine breit wiederverwenden lassen.

Der Nutzen reicht über die Testrolle hinaus. Findet jemand einen Fehler, muss der Entwickler erst zur betroffenen Stelle navigieren, um die Ursache zu suchen. Statt diesen Weg zwei Stunden manuell nachzustellen, läuft die vorbereitete Navigation in acht bis zehn Minuten ab.

Der nächste Schritt: PDF-Inhalte automatisiert prüfen

Nach dem Absenden eines Formulars entsteht ein PDF, und genau das wird zum nächsten Prüffeld. Der Endnutzer wird über den Happy Path simuliert, das lange Formular ausgefüllt und abgeschickt. Danach folgt eine Bestätigung und schließlich ein PDF zum Download, das sensible Daten und gesetzliche Richtlinien enthält, die nicht verletzt werden dürfen.

Für diese Prüfung ist das Verfahren gut aufgestellt, weil der verwendete Testdatensatz bekannt ist. Das Team weiß genau, welche Felder es befüllt hat, und kann den PDF-Inhalt entsprechend minutiös abgleichen. PDF-Inhalte zu testen ist allerdings kein Web-UI-Testing mehr, sondern eine eigene Aufgabe, die niemand selbst implementieren oder pflegen will.

Deshalb arbeitet das Team an einer generischen Bibliothek dafür, gemeinsam mit der Tochterfirma, die das eingesetzte Testwerkzeug verantwortet. Eine solche Lösung ist besonders für die Versicherungsbranche und für E-Government relevant.

Accessibility wird zum eigenen Testfeld

Barrierefreiheit entwickelt sich zu einem großen Thema, im öffentlichen Bereich wie bei Versicherungen. Steuerformulare, über die Bürger ihre Einkommensteuer elektronisch abgeben, müssen bei der Accessibility einwandfrei sein.

Das Problem für Tester: Ohne Accessibility-Expertise weißt du nicht, welche Regeln zu prüfen sind und wie du auf einen Fehler reagierst. Die Einarbeitung in die Standardbibliothek für Barrierefreiheit kostet Zeit, die im Sprint fehlt.

Die Antwort folgt demselben Muster wie beim Formular-Testen. Das Team baut eine Accessibility-Bibliothek auf, die auf der Standardbibliothek mit ihren Checks und Regeln aufsetzt. Ein Accessibility-Experten-Team liefert die zusätzlichen Anforderungen, und gemeinsam wurden benutzerfreundliche Fehlercodes definiert. Der Tester ruft sinngemäß “prüfe diese Oberfläche” auf und bekommt in lesbaren Run-Logs rot markiert angezeigt, an welcher Stelle welcher Fehlercode greift.