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 Formularvarianten 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 deployt werden.
- Aus dem UI-Modell der Low-Code-Plattform lassen sich Selektoren und Testcode automatisch ableiten, sodass ein gesamtes Formular mit einer Codezeile befüllt und mit einer zweiten 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 einzelnes 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.
Häufig gestellte Fragen
Wie viele Felder und Regeln kann ein einzelnes behördliches Steuerformular umfassen?
Die Größenordnungen sprengen jede manuelle Durchprüfung. Im beschriebenen Projekt kommen über 255 Formularvarianten für 16 Bundesländer zusammen, jedes Formular mit mehr als 100 Feldern auf der Oberfläche. Ein einzelnes Steuerformular liegt bei rund 2400 Feldern und etwa 2200 Validierungs- und Berechnungsregeln, eine einzelne Steuerart erreicht bis zu 100.000 Felder.
Warum löst UI-Testautomatisierung das Problem großer Formularlandschaften nicht von allein?
Weil sie den Aufwand nur verschiebt. Schon das Automatisieren eines einzigen Happy Path führt bei dieser Formularvielfalt in die Wartungsfalle: Zur Implementierung des Testfalls kommen laufende Pflegekosten, sobald sich Felder oder Regeln ändern. Der eigentliche Engpass liegt ohnehin davor, denn ohne gültigen Testdatensatz kommt weder ein manueller noch ein automatisierter Test ins Laufen.
Was leistet ein SMT-Solver bei der Erzeugung von Testdaten?
Er berechnet gültige Testdatensätze aus dem Regelwerk. Das Datenmodell wird dazu in ein arithmetisches Modell konvertiert, der Solver löst dieses Gleichungssystem und sucht eine Lösung mit möglichst vielen belegten Feldern. Das Ergebnis landet in einer Excel-Datei, in der jede Spalte einen vollständigen, gültigen Datensatz enthält, nutzbar für manuelles wie automatisiertes Testen.
Kann Testdatengenerierung Fehler im Fachmodell aufdecken?
Ja, und das ist ein wesentlicher Nebeneffekt. Schließen sich Validierungsregeln versehentlich gegenseitig aus, findet der Solver keine Lösung, und die Generierung bricht ab. Der Modellierungsfehler wird damit sichtbar, bevor die Modelldateien überhaupt deployt werden. Der Test des Modells fällt so als Nebenprodukt der Datengenerierung an.
Was passiert mit den Tests, wenn sich die Fachlichkeit jedes Jahr ändert?
Die Testdaten werden neu generiert, die Tests laufen danach sofort wieder. Genau hier liegt der Unterschied zum manuellen Vorgehen: Ein einmal gefundener valider Datensatz verliert seine Gültigkeit, sobald sich eine Regel verschiebt, und die Fachlichkeit ändert sich pro Jahr und pro Bundesland. Der modellbasierte Weg macht diese Neuberechnung zu einem Routineschritt.
Wie viel Testcode braucht ein Formular mit hunderten Feldern bei diesem Ansatz?
Zwei Zeilen genügen als Vorbereitung. Eine Zeile befüllt das Formular, indem das Werkzeug die Excel-Datei mit den gültigen Datensätzen liest und die Felder von oben nach unten abarbeitet. Die zweite Zeile prüft das gesamte Formular gegen die Erwartung. Die Zahl der Felder spielt dabei keine Rolle, weil Selektoren und Methoden aus dem UI-Modell abgeleitet werden.
Wie groß ist der Zeitunterschied zwischen automatisiertem und manuellem Formulartesten?
Alle automatisierten Tests für ein Bundesland laufen in 12 bis 14 Stunden durch. Manuell wären dafür schätzungsweise mehrere hundert Stunden nötig, mindestens rund 500. Auch für die Fehlersuche zahlt sich das aus: Statt zwei Stunden manuell zur betroffenen Stelle zu navigieren, erledigt der vorbereitete Lauf diesen Weg in acht bis zehn Minuten.
Lässt sich Barrierefreiheit testen, ohne Accessibility-Expertise im Testteam zu haben?
Nur mit Vorarbeit. Ohne Fachwissen weiß ein Tester nicht, welche Regeln zu prüfen sind und wie auf einen Fehler zu reagieren ist, und die Einarbeitung in die Standardbibliothek kostet Sprintzeit. Das Team kapselt sie deshalb in einer eigenen Bibliothek mit benutzerfreundlichen Fehlercodes, die ein Accessibility-Expertenteam mitdefiniert hat. Der Tester ruft die Prüfung auf und liest die Treffer im Run-Log.
