Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Ritschi und habe wieder eine Folge vom German Testing Day 2024 mit dabei. Heute geht es um Formulartesten. Stellt euch mal vor, ihr müsstet eine schier unendlich große Varianz an Formularen, Eingabefeldern etc. testen. Da kann man schnell verzweifeln. Lilia und Simon standen vor diesem Problem und welche Lösung sie gegangen sind, erzählen sie uns
in der heutigen Folge. Viel Spaß beim Weg durch den Formulartschungel. Hallo Lilia, hallo Simon, schön, dass ihr da seid. Schön, dass wir hier sind und schön, dass du uns eingeladen hast. Ja, vielen Dank. Herzlich gerne. German Testing Day 2024 hier in Frankfurt. Es geht schon langsam in die Zielgerade. Ihr habt ja einen unfassbar coolen Stand, haben wir gerade schon festgestellt mit dieser LED Wall im Hintergrund. Das ist ja echt super.
Also immer hingucken. Ein großer Dank an MGM Marketing für die innovativen Ideen. Genau, für diese Innovationen hier. Das ist einmal etwas Neues. Deswegen ist vielleicht, nehme ich das Grafikdruck, MGM, unser Slogan ist Innovation Implemented. Ja, genau. Das ist dann echt so der Beweis dafür, der Proof. Nicht nur in der Software. Ja, jetzt schauen wir mal, ob ich das beim Testing auch kann. Ich habe in einem Abstract gelesen, war ganz spannend, das Thema ganz viele
Formularvarianten zu testen. Also spätestens da habt ihr mich schon gehabt, weil ich habe selber mal so ein Projekt gehabt vor vielen, vielen Jahren und ich bin daran verzweifelt. Und dann habe ich mir gedacht, das müssen wir doch mal besprechen. Holt uns mal rein, was war denn das Thema? Was war denn das Projekt? Also im Wesentlichen ging es darum, dass wir uns um sehr, sehr viele Formulare gleichzeitig kümmern durften mit Support für alle Bundesländer. Das heißt,
jedes Bundesland hat auch sein eigenes Formular. Also behördliche Formulare? Richtig, genau. Also es kommt aus dem steuerlichen Kontext. Hat sicherlich jeder schon mal verwendet. Vielleicht zu Beginn nur einen kleinen Hinweis. Das habe ich auch beim Vortrag, vor dem Vortrag gesagt. Wir haben während des gesamten Vortrags Begriffe verwendet wie digital Roulette, Zivilplattform,
Buchstaben, Steuerformular. Das sind alle fiktive Namen von uns. Denn aus Gründen der Geheimhaltung dürfen wir die tatsächlichen Namen des Kundenprojekts, Plattformen und auch Formulare dürfen wir nicht sagen, müssen wir anonymisieren. Okay, verstehe. Wir bitten dich um Verständnis. Das heißt, falls wir über Zivilplattform jetzt quatschen, das ist fiktiv. Ja, okay, gut, gut,
gut zu wissen. Haben wir alles ersetzt. Ja, und da kam quasi einer der Schmerzpunkte, den wir hatten während der Entwicklung drauf, dass wir einen wahnsinnig hohen manuellen Testaufwand hatten, bei dem wir im Endeffekt nicht mehr hinterhergekommen sind, dass wir alle Variationen wirklich abdecken innerhalb von unseren Testphasen. Man hat ja auch nicht
mehr viel Zeit, vier Wochen Sprints und mit jedem Release quasi muss alles durchgetestet sein. Und dann muss man eben schauen, wie man eine gute Testabdeckung hinbekommt, dass man sich nicht nur auf wenige Funktionalitäten beschränkt. Ich meine, es gibt weniger wichtige und mehr wichtige Funktionalitäten. Aber trotzdem die Testabdeckung einmal gleichmäßig über das ganze Projekt ordentlich hinzubekommen, wird schwierig, je mehr Formularvariationen man quasi hat.
Außerdem ist man dann von den Bundesländern abhängig. Richtig, genau. Und dann, das darfst du ruhig auszählen. Worauf möchtest du hinaus? Ja, die Bundesländer, dann die Formularvariationen, über 255 Formularvariationen auf 16 Bundesländer. Jedes Formular hat über 100 Felder auf der UI. Das heißt, das ist nichts, was du gerne manuell jetzt mal einfach so durchspielen möchtest. Außer man möchte jemanden bestrafen.
Dafür ist es auf jeden Fall geeignet. Es gibt noch eine bestimmte Steuer, die hat bis zu 100.000 Felder. Das ist nochmal eine ganz andere Kategorie. Und da ist die Automatisierung wirklich super wichtig, dass man die als Tool dabei hat für die Befüllung von solchen Formularen. Andernfalls wird man da wahnsinnig, wenn man das auch als Tester Tag für Tag machen muss. Also eine irre Kombinationsmöglichkeit an Varianten. Und von der Technologie her, waren ja dann keine PDF-Formulare, sondern HTML?
Oder wie war das? Das ist eine Web-Anwendung. Die Zivilplattform ist eine Software, die entwickelt wurde, basierend auf der A12-Low-Code-Plattform. Mit der A12-Low-Code-Plattform entwickelt wurde und wird weiterhin. Und jedes Formular, und das ist das gute, weil das eine A12-Low-Code-Plattform ist, jedes Formular der Zivilplattform, hinter jedem Formular verbergen sich unter anderem zwei wichtige Models.
Weil das ist Low-Code, also es wird alles modelliert am Anfang. Und zwar ein Datenmodell und ein UI-Modell. Das bedeutet, die Experten der Fachlichkeit, das sind im Falle der Zivilplattform die Sachbearbeiter und die Business-Analysten, sie gießen die gesamte Fachlichkeit des Formulars zunächst und als erstes in einem Datenmodell. Was heißt das? Sie definieren erstmal was und spezifizieren, was brauche ich für Felder auf dieses Formular? Ein String-Feld für Name, ein Date-Feld für Datum,
brauche ich ein Ja/Nein-Feld, keine Ahnung. Also sie definieren ihre Felder, die sie brauchen für diese Fachlichkeit. Dann modellieren sie mit diesem Modellierungstool von A12, definieren sie auch ihre Validierungs- und Berechnungsregeln für dieses Formular. Und zwar, sie benutzen eine Regelsprache, die von der Low-Code-Plattform angeboten wird, von MGM. Ich gebe Ihnen ein Beispiel, wir bleiben bei Name und Geburtsdatum. Fällt angegeben Name und fällt nicht angegeben Geburtsdatum,
dann soll diese Regel folgende Fehlermeldung feuern. Bitte tragen Sie Ihr Geburtsdatum ein, zum Beispiel. Das ist eine einfache, banale. Und bei dem Buchstaben "Steuerformular", das haben wir nur als Beispiel fiktiv gezeigt, da reden wir über 2400 Felder und über 2200 Regeln. Das übersteigt jede mögliche menschliche Ability. Das ist einfach, das geht in die Decke und das ist nur ein Formular von 255. Und die Herausforderung, sie ändern sich ständig, pro Jahr, pro Bundesland, pro, keine Ahnung.
Das bedeutet, selbst wenn ich einen validen Testdatensatz finde, der alles validiert, das ändert sich ständig. Das heißt, die Aufwände gehen sofort schnell in die Decke, in jede Richtung. Okay, also ich bin überzeugt, manuell ist das eine Aufgabe für jemanden, der ganz, ganz schwerwiegendes verbrochen hat. Das heißt, ihr habt euch da anders genähert. Was habt ihr denn gemacht dann? Also außer vielleicht mal geweint im Keller, also Gott,
wieso haben wir das gemacht? Vielleicht eine kleine Ergänzung, auch wenn du anfängst, die UI zu automatisieren, damit du irgendeinen Happy Path abdeckst, läufst du sofort in die Wartungsfalle automatisierte Tests, abgesehen von den Aufwänden bei der Implementierung, dieses einzige Testfall. Was wir gemacht haben, ist sehr generisch. Also wir haben heiß diskutiert bei den Dailys, wie wir da aus dieser Lage kommen und wie wir dann eine nachhaltige Lösung,
ja nach Lösungswege, wie können wir das machen? Dann entstand die Idee, einen Versuch zu machen, mal uns die Modelle zunutze zu machen, diese Zivilplattform. Das Datenmodell umfasst die Felder, dann Validierungs- und Berechnungsregeln. Alleine aus diesem Datenmodell, das ist eine JSON Datei, die haben wir konvertiert in einem arithmetischen Modell. Dann haben wir eine Open Source Library, das ist SMT Solver. Dieser SMT Solver umfasst die Implementierung von
Algorithmen für die Feldbelegung. Dann haben wir diese Implementierung ergänzt, um Implementierung für bestimmte projektspezifische Validierung, wie zum Beispiel die Belegung von der Steuernummer. Das ist jetzt nichts, was Open Source ist. Und letzten Endes, wir geben dieses arithmetische Modell diesem SMT Solver. Er löst dieses arithmetische System und findet einen Testdatensatz mit möglichst vielen Belegungen. Das ist High Test Coverage von diesem Testdatensatz.
Und dann nehmen wir diese Lösung, diesen validen Testdatensatz und gießen das oder speichern das in einem Excel-File. Dann haben wir am Ende Testdatensätze. Jede Spalte ist ein valider Testdatensatz und der kann sofort verwendet werden für manuelles oder automatisiertes Testen. Das reduziert schon mal die Aufwände. Am Anfang finde mal einen validen Testdatensatz, weil das würde dich blockieren, egal ob du manuell oder automatisiertes testen musst. Das war das erste
Werkzeug, was uns erheblich entlastet hat. Ändert sich die Fachlichkeit, so ändern sich diese Validierungsdiese. Wir generieren neuen Tests dort und unsere Tests können sofort wieder ausgeführt werden. Der zweite Ansatz, und der ist auch generisch und modellbasiert, weil ohne
generischen Ansatz hast du bei dieser Größe und dieser Dimension keine Chance. Der zweitgenerische Ansatz, und das ist auch die Grundidee, ist, können wir aus diesem Datenmodell, eine Sache habe ich dir vorenthalten, das ist diese UI-Modell, das heißt, diese Modellierer, die das, diese Fachlichkeit gießen im Datenmodell, haben die Möglichkeit, auch das Formular, das Aussehen
des Formulars selber zu modellieren. Im gleichen Modellierungs-Tool von A12, das ist dieser Simple Model Editor, da können sie bestimmen, welche Labels, also welche Überschriften haben meine Felder, wie werden meine Felder auf der UI gruppiert, welche Überschrift hat die Gruppe, wie wird die Darstellung eines Stringfeld, ist es ein Textfeld oder Textarea, was brauche ich da, ist es eine Checkbox oder ein Radio Button, du designst die UI, brauche ich ein Footer,
welche Aktionen brauche ich im Footer und so weiter. Da entsteht ein UI-Modell, der hat drin in dieser JSON-Data, da sind so viele Informationen über die UI, die haben wir uns zu Nutze gemacht, wir haben alle Informationen für die UITest-Automatisierung daraus extrahiert, zusätzlich dann die Felddefinition, die Validierung brauchst du nicht, um ein Formular zu befüllen, dir ist es egal, ob die Daten, mit denen du befüllst, valide sind oder nicht und haben
daraus dann Code und zwar, das sind die Selektoren in Cypress oder die Lokatoren in Playwright, wir haben Smart-IDs, die wir benutzen bei MGM für die UITest-Automatisierung, das Tool QFTest von der Firma QFS, Quality First Software, das ist eine Tochterfirma von MGM seit September 2022, deswegen ist es naheliegend, dass wir dann dieses Tool für die UITest-Automatisierung benutzen, also haben wir den Code extrahiert und dann die Smart-IDs, also die Identifikatoren,
unsere Widgets auf der UI automatisiert, generiert und zwar, das ist die Kombination letzten Endes zwischen den Feldtypen und seiner Überschrift, wir identifizieren jedes Element auf der UI anhand des Typs, es ist ein Textfeld und dann die Überschrift Name, Vorname, ja und dann haben wir eine Bibliothek geschrieben, die dann, also du sagst, die Identifikation ist ein Textfeld, dann holen wir aus der Library genau die Methode,
die ein Textfeld bedienen kann, egal ob befüllen oder überprüfen, das heißt Simon in seinem Testfall, er schreibt nur, befülle mir das Formular, QFTS liest dieses Excel-File, also die Identifikatoren, natürlich haben wir jetzt valide Testdatensätze, die sind kombiniert zusammen im Excel, dann wird dieses Excel iteriert von oben nach unten, also befüllt QFTS blind von oben nach unten das Formular, Wahnsinn, richtig? Ja, sehr generisch angesetzt, das ist schon klasse.
Ich habe noch eine Frage zu dem Modell davor, also ist das das Modell, das auch für die Implementierung genutzt wird, das heißt, oder wo trennt sich die Implementierung vom Test, weil Gefahr ist natürlich, dass ich das gleiche Modell für beides nehme und dann eigentlich das eine gegen das andere prüfe, das findet mir dann gar keine Fehler, weil bei der Basis immer das Modell ist, aber das Modell könnte ja schon falsch sein, wo ist denn da die Trennung passiert?
Also deine Frage ist, dieses Modell für die Entwickler der Software, also diese Modelle sind die Basis, die Entwickler müssen gar nichts tun, sie müssen nur dazu entwickeln, falls es irgendeine Besonderheit, also projektspezifische Anforderungen gibt, die man nicht abbilden kann mit der Regelsprache, was sehr selten passiert, aber sollte das passieren oder sollte ich einen extra Wunsch haben, dann kann ich das implementieren,
das heißt, die Rolle der Entwickler ist eigentlich, die Fachlichkeit ist schon modelliert. Übrigens, das möchte ich ergänzen, weil das ist ein sehr guter Punkt, den du angesprochen hast, diese Testdatengenerator, dieses Feldbelegung, finde mir einen validen Testdatensatz, diese SMT-Solver, wenn er hat, hat in diesem Gleichungssystem und Regeln aus Versehen, die Modellierer, also die Business-Analysen haben Fehler gemacht und Regeln schließen sich aus
Versehen gegenseitig aus, dann kracht es sowieso bei der Testdatengenerierung, es geht nicht, weil und dann findest du diese Fehler und dann behilfst du das very early und zwar bevor diese Modelle, diese Jasons später deployed werden, das heißt, der Entwickler, der greift in gar nichts, diese Modelle aus dem Datenmodell, UI-Modell, sobald das deployed ist, entsteht das Formular.
Ja. Ja, die Entwickler können nur Zusatzsachen, also sollten nur, es ist zu empfehlen, nur die Zusatzsachen, die du wirklich sehr projektspezifisch sind und später, wenn du dann deine UI testest, das gesamte Modell solltest du nicht mehr testen müssen, weil das wurde schon sehr früh getestet. Ja, okay, verstehe. Das heißt aber auch, ich gehe dann schon davon aus, dass das Modell dann auch an sich korrekt ist, also dass das valide ist, mit dem ich dann arbeiten
kann. Das ist natürlich wichtig, weil sonst finde ich ja auch andere Fehler. Das heißt, die Idee, die Fachlichkeit wird sehr früh gegossen, sie wird nicht implementiert, das ist auch nichts, was du implementieren kannst. Stell dir vor, 220 Regeln feuern. Ja. Ja, viel Spaß beim Implementieren und Warten. Ja, verstehe. Wie viel ist es denn geworden? Also diese ganzen Varianten, was habt ihr denn so an Testfällen und Testsets dann im Endeffekt gehabt, um zu sagen, okay, damit können wir gut testen?
Also wenn wir alles aufrechnen, dann, oder sagen wir es mal so, wir haben diverse automatisierte Tests geschrieben und man braucht ja quasi, pro Release wollen wir so viel wie möglich testen. Und wenn wir alles zusammenrechnen und alles mal laufen lassen, dann schauen wir auf eine Gesamttestdauer von 12 bis 14 Stunden für ein Bundesland. Jetzt können wir das Ganze noch versechzehnfachen, dann sind wir bei dem echten Testaufwand. Und jetzt kann man auch sagen,
unser QF-Test testet optimal und in hoher Geschwindigkeit. Wenn man jetzt das umrechnen würde in manuelle Testdauer, dann wären wir wahrscheinlich bei Hunderten von Stunden, mindestens 500 wahrscheinlich. Da liegt auch noch mehrere Sachen auch noch dazwischen, die QF-Test dann für einen tut. Und besonders für mich als Automatisierer ist es super praktisch, wie Lilia schon gesagt hat, ich brauche eine Zeile Code, die sagt, befülle mir das gesamte
Formular. Es gibt aber noch eine weitere Zeile, die heißt, checke das gesamte Formular. Ich kann also auch überprüfen, dass auch wirklich das da drin steht, was ich mir erwarte. Und allein nur zwei Zeilen Code als Vorbereitung für ein gesamtes Formular nutzen zu können, ist wahnsinnig flexibel.
Denn ich habe dann auch die Möglichkeit, dass ich sage, ich teste nicht nur auf den gesamten Prozess hinweg, also Formular erstellen, ausfüllen, abschließen, archivieren, sondern ich kann auch sagen, dass ich denselben Testcode flexibel benutzen kann oder dieselben Testschritte für Feature-Tests. Also ich kann bis zu einer bestimmten Stelle gehen, das nutze ich dann
als Vorbereitung. Und ab da kann ich mich dann auch als manueller Tester selber nochmal drauf schalten und sagen, ich möchte jetzt dieses spezielle Feature testen oder ich schreibe halt einen Tester dafür, der genau auf dieses eine Feature, was jetzt irgendwie zum Beispiel im letzten Sprint sehr kritisch war, genau darauf abzielt. Das ist ja dann auch gewachsen über die Sprints wahrscheinlich auch. Was habt ihr denn im Endausbau, wie viele Tests habt ihr denn so
gehabt? Ich meine, wenn man es jetzt so überschlägt, kommt man ja auf zigtausend Varianten und Möglichkeiten. Wie viele Tests habt ihr denn dann wirklich konkret noch am Schluss rausgehabt? Wenn man auf die einzelnen Feature-Tests schaut, dann glaube ich, haben wir aktuell circa 20 Stück implementiert. Wenn man auf die Happy Path-Geschichten schaut, dann sind es an die, also quasi für jeden Testlauf, den man nutzen kann, sind es an die 200, 300. Also ich meine, natürlich wird sehr viel
davon recycelt, weil es ist sehr nachhaltig, wir können sehr viel davon wiederverwenden. Aber wenn wir alles hochrechnen, dann haben wir innerhalb von kürzester Zeit 300, 400 Tests hochgezogen, die wir und die nicht nur die Tester ansteuern können, sondern sie sind auch breiter verwendbar. Wenn man zum Beispiel einen Fehler findet, dann muss ja der Entwickler erst mal zu dieser Stelle hin navigieren können, um überhaupt Troubleshooting machen zu können, um rauszufinden, wo liegt denn
der Fehler begraben. Und da können wir natürlich innerhalb von unserer Rolle aus auch unterstützen, dass wir sagen, wir haben für dich hier einen manuellen Test vorbereitet, der ist für dich so und so ansteuerbar. Und dann läuft die Vorbereitung, anstatt dass er das zwei Stunden lang manuell macht, innerhalb von acht bis zehn Minuten ab. Ja, verstehe. Vielleicht noch eine Information, um den Kreis zu schließen. Das haben wir nicht in unserem Vortrag erzählt, weil das ist noch
in Bearbeitung oder in Implementierung. Und zwar, wenn man diesen Happy Path macht, also mit UiTest Automatisierung, ohne irgendwas zu mocken, du loggst dich ein und simulierst letzten Endes den End-User mit QFTS, befüllst diese langen Formular und dann schickst du das ab. Dann bekommst du eine Bestätigung, eine E-Mail-Bestätigung in der Regel. Und dann du kriegst
irgendwann mal ein PDF, was du herunterladen kannst. Und dieses PDF ist sehr sensibel, hat sehr sensible Daten und hat sogar irgendwelche gesetzliche Richtlinien drin und die dürfen nicht verletzt werden. Jetzt musst du diese PDFs auch inhaltlich prüfen. Das Coole ist, wir haben sie ja abgeschickt. Das heißt, wir haben den Testdatensatz und wir wissen, welche Felder wir befüllt haben bei der Befüllung. Das heißt, wir sind eigentlich sehr prädestiniert, auch den Inhalt
der PDF sehr minutiös automatisiert testen zu müssen. Gerade arbeiten wir tatsächlich an einer Library in QFTS. Das ist das Coole, wenn QFTS Teil der MGM-Familie ist, dann geben wir das in Auftrag und dann sagen wir, wo unsere Schmerzen sind, weil den Inhalt der PDF, das ist jetzt nicht Web-UI-Testing, das ist jetzt was anderes. Das willst du gar nicht. Das willst du weder
implementieren noch maintainieren. Das ist noch viel schlimmer als UI. Und da gerade sind wir dabei tatsächlich zusammen mit der Firma QFTS, also mit unserer Tochterfirma, eine Lösung, eine generische, nachhaltige Lösung für PDF-Inhalte. Und das ist sehr wichtig für Versicherungsbranche und auch für E-Government. Ja, super, sehr cool. Wenn ihr jetzt so in die
Weitheit zuführen, das ist jetzt eine Sache, die ihr auch gerade umsetzt. Gibt es denn noch etwas, wo ihr sagt, okay, da wäre es mal cool, wenn wir zukünftig noch eine Lösung haben, um das noch einfacher oder besser zu machen in diesem Konstrukt? Ja, und zwar, das ist auch eine andere Sache, die wir auch daran gerade arbeiten. Das ist aber ein bisschen außerhalb der A12-Logo-Plattform, aber im Allgemeinen für alle MGM-Projekte. Wir sind ein Software-Haus und wir haben so viele
Software-Produkte für diverse Kunden, unter anderem in Versicherung, aber auch, ja. Das ist Accessibility. Das ist ein großes Thema und das wird zum großen Thema auch für Versicherung, nicht nur im öffentlichen Bereich. Also im öffentlichen Bereich ist das eines unserer MGM-Produkte sehr bekannt. Die Plattform, jeder Bürger bundesweit kann seine Einkommensteuer, unter anderem elektronisch abgeben. Diese Formulare müssen stubenrein sein,
was die Accessibility angeht. Und ganz ehrlich, wenn du nicht Accessibility-Experte bist, du hast keine Ahnung. Und dann sagst du, okay, es gibt die Achse Standardbibliothek für Accessibility. Ich kenne sie nicht, ich habe mich nicht, da muss ich mich erstmal einlernen. Welche Regeln soll ich testen, welche nicht? Wie reagiere ich, wenn jetzt ein Fehler kommt und so weiter?
Und hier tatsächlich, wir arbeiten gerade auch zusammen mit unserer Tochterfirma QFS, arbeiten wir an einer Accessibility-Library, unser eigenes Produkt, wo wir die Achse, und zwar, das ist die Standard-Library für Accessibility, und zwar mit all ihren Checks und Rules. Es gibt Rules für die Accessibility. Und darüber hinaus, wir haben Gott sei Dank in A12 und bei MGM ein Accessibility-Experten-Team. Sie geben uns die Anforderungen, was noch zu
beachten ist und welche Regeln. Wir haben mit ihnen Fehler-Codes für die Accessibility benutzerfreundlich definiert. Und dann, wenn der Code kommt, ist es die Regel, du musst das machen. Und wir haben sehr sauber sichtbare Run-Logs für die normalen Leier wie wir, dass man sagt, okay, ich will nichts verstehen von der Accessibility, ich will die Library benutzen und sage, checke, checke für mich. Das ist wie, ich befühle mein Formular,
ja. Checke bitte für mich diese UI. Wo habe ich Probleme? Und dann zeigt sie mir genau in rot, das ist genau dieses kleine Ding hier, da fehlt dir das und das, das ist der Error-Code so. Super, da kommen ja noch ein paar spannende Dinge, da freue ich mich drauf, wenn man vielleicht… Vielleicht bei der TACON. Genau, das nächste Mal auch wieder draufschauen. Vielen herzlichen Dank für diese Einsicht, wie man so ein Projekt angehen kann, wie man sowas testen kann,
auch automatisiert testen kann. Das ist, glaube ich, eine gute Inspiration, auch gerade, wenn man solche Unmengen an Formularen hat. Und da gibt es ja durchaus die ein oder andere Parallele zu anderen Themen auch, wo man sowas umsetzen kann. Ich danke euch herzlich, wünsche euch noch ganz viel Spaß auf der Konferenz und bis bald. Ja, Richard, vielen, vielen Dank und bis demnächst. Genau, danke. Mach's gut. [Musik]