Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Ritchie und freue mich wieder eine Folge vom German Testing Day 2024 aus Frankfurt mit dabei zu haben. Bei mir zu Gast ein langjähriger Wegbegleiter im Bereich Software Testing und Qualität, nämlich Matthias Hamburg. Er setzt sich seit vielen Jahren für Testentwurfsverfahren ein, für Teststrukturen und ganz besonders auch für die richtige Nutzung der Begriffe,
indem er nämlich das IST-Cubi bzw. GTB-Glossar pflegt und hegt und weiterentwickelt. Und mit ihm spreche ich über das Thema modellbasiertes Testen, warum es manchmal nicht funktioniert und was wir besser tun können. Viel Spaß dabei! Hallo Matthias, schön, dass du da bist. Hallo Ritchie, es ist mir ein Vergnügen. Ja, ich freue mich total. Wir sind ja hier am German Testing Day 2024 in Frankfurt. Es driftet in den Nachmittag rein, die Konferenz, Mittagspause gerade vorbei. Du
hast deinen Vortrag schon gehalten, habe ich gerade gehört. Und ich freue mich auch sehr, dass du jetzt mal im Podcast bist, weil du bist ja auch ein Urgestein der Software Community. Du hast ja da viel auch bewegt in den letzten Jahren im GTB, im IST-Cubi, in der Community. Du hast dich immer eingesetzt für Qualität. Deswegen freut es mich, dass wir heute auch mal hier eine Folge gemeinsam machen. Ja, sehr gerne. Dein Vortragstitel war ja auch in Richtung Model-Based Testing und da auch mal so
einen anderen Ansatz, einen neuen Ansatz auch zu fahren. Und mir ist so eine Aussage hängen geblieben, dass du da auch sprichst über die Probleme, die MBT heute hat. Da würde ich gerne einsteigen damit, weil ich glaube, für viele ist das einfach auch nicht wirklich greifbar. Die kennen das so aus, Model-Based-Testen, aber was ist das eigentlich und was soll das? Und was sind denn da so die Herausforderungen, die gerade so da sind? Ja, also Model-Based-Testen hat mir immer sehr gut gefallen
und ich habe es auch in der Praxis ausprobiert. Als Testmanager habe ich das auch in ein paar Projekten eingeführt und es lief nie so rund. Und ich habe neulich dann noch mal in Studien nachgerecherchiert und geschaut und es gibt zum Beispiel die World Quality Report, die jährlich erscheint. Von Capgemini und Soveti. Und die haben in ihrer letzten Ausgabe festgestellt, dass Testautomatisierung
insgesamt nicht die geschäftlichen Ziele erreicht hat, die man sich gewünscht hat. Also weder funktioniert CI/CD mit Testautomatisierung glatt, noch hat man die Effizienzsteigerung erreichen können, noch hat man die Qualität der Software dadurch besser machen können und so weiter. Also die Umfrage fragt ja in der Regel Manager oder Unternehmensleitung und die fokussieren auf die Geschäftsziele und diese
Geschäftsziele oder Erwartungen sind nicht erreicht worden. Und das deckt sich mit meinem subjektiven Gefühl, dass Model-Based-Testen oder die Automatisierung des Testens von Anfang an eine sehr schöne Idee ist, die sehr gerne genutzt oder ich unterstütze sie sehr gerne und trotzdem in der Praxis hat sie sich noch nicht bewährt. Und das war mein Anlass zu gucken, was kann man da machen und das passte dann auch damit zusammen, dass ich im Moment Produktdonor bin bei ISCQB für eine kleine
Applikation, nämlich die Größerapplikation. Da habe ich die Freiheit auch neue Sachen auszuprobieren und auch wie soll ich sagen, den Anspruch an mich selber da so zu testen, wie es im Buche steht. Ah ja, okay. Da hast du quasi eine Spielwiese, wo du das auch gut nutzen kannst. Genau, genau. Ja und deswegen habe ich mich umgeschaut und habe ein Werkzeug gefunden, das zumindest mal verspricht die Schwierigkeiten zu beheben. Jetzt hast du ja die Schwierigkeiten angesprochen,
welche Schwierigkeiten sehe ich beim modellbasierten Testen und da gibt es verschiedene. Die eine Schwierigkeit ist, dass die Leute, die die Modelle erstellen, in Modellierung nicht professionell
ausgebildet sind. Das kann man so oder so sehen, aber wir müssen halt versuchen mit dieser Situation zu leben und modellbasiertes Testen mit Modellen zu entwickeln, die nicht so formal sind und nicht so viel Training, sondern leichter zu verstehen und auch für die Testernähe oder leichter verständlich sind. Das andere große Hindernis, das ich erfahren habe, ist, dass modellbasiertes Testen keinen nahtlosen
Übergang bietet im Moment von der Modellierung bis zum durchgeführten Test. Also es gibt in diesem Ablauf Lücken. Und die machen es schwierig. Wenn man sich das ESCB Modell der Testaktivitäten anschaut, dann gibt es erstmal eine Testanalyse, dann einen Testentwurf, dabei entstehen die Testfälle, dann kommt eine Testrealisierung und dann kommt die Testdurchführung. Die Durchführung können wir automatisieren, da haben
wir schon etablierte Tools, da können wir Selenium, Playrite und so weiter benutzen. Für den Testentwurf können wir ja erst einmal sozusagen als intellektuelle kreative Tätigkeit festlegen, was wir testen wollen, was wir beim Testen abdecken wollen, das sind die Testbedingungen. Und daraus, wenn wir das modellieren, dann können wir daraus beim Testentwurf Testfälle generieren. Und das macht das modellbasierte Testen.
Aber dazwischen gibt es eine Lücke und die macht Probleme, nämlich die Testrealisierung, in der ich die konkreten Testdaten auswähle, in der ich sage, welche Buttons muss man drücken, was muss man genau prüfen am Ergebnis, was sind die erwarteten Ergebnisse konkret, also vom abstrakten zum konkreten. Und die meisten Ansätze versuchen das zu lösen, indem sie auch diese konkreten Daten ins Modell packen. Aber das
macht das Modell unheimlich kompliziert. Und das ist auch ein wichtiger Hindernisgrund, oder ein Grund, warum sich das nicht durchgesetzt hat. Es ist ja bei dem Modell, es ist ja eine Abstraktion eigentlich, eine logische Sicht und dann natürlich wieder mit konkreten Daten reinzugehen, das ist natürlich auch so ein Schiefstand von der Optik dann auch. Ja, man empfiehlt, da soll man dann Objektemodelle nutzen, aber das hilft nicht sehr viel.
Und dieses Werkzeug oder dieser neue Ansatz versucht das so zu überbrücken, dass man sagt, ich generiere erstmal die abstrakten Testfälle aus dem Modell, die müssen manuell durchführbar sein, weil ich beim manuellen Testen ja sozusagen als Mensch die weiteren Lücken der Implementierung ergänze. Und ich denke mir aus, aha, ich will jetzt eine Suche nach einem Begriff, der in Glossar vorkommt, dann tippe ich mal A/B ein, weil ich weiß, das kommt davor. Aber das muss man der Maschine immer sagen.
Und dieses kann ich früh machen und ich kann dann die Vorteile des modellbasierten Testen auch mit dem Shift Left nutzen, dass ich früh modelliere, durch die Modellierung habe ich dann wieder eine Qualitätssicherung der Testbasis oder Spezifikation und das verspricht auch mal ein modellbasiertes Testen, aber das kann ich dann wirklich, aber dann halte ich an und habe keine Angst vor dem Paradigmenwechsel.
Und wenn die Software da ist, fange ich bei diesem Zwei-Phasen-Ansatz an, mit dem modellbasierten Testtool die konkreten Fälle zu generieren. Dazu brauche ich die echte Anwendung und dann sage ich dem System, führe mir jetzt diese abstrakten Testfälle durch und der fragt mich zurück, was heißt, dass jetzt Text eingeben und der blendet mir dann die Dialog-Oberfläche vor.
Und dann kann ich da den Test eingeben, der passt und sagen, nimm das bitte auf, aber es ist trotzdem kein simples Capture Replay Tool, mit dem wir ja früher sehr viele Wartbarkeitsprobleme hatten, dass dieses Capture Script nicht lauffähig war hinterher, sondern er macht von der fachlichen Ebene und generiert erstmal die Aktionswörter auf der Wii-Ebene und sagt, okay, er hat jetzt A-B eingegeben und er hat Enter gedrückt und das kann ich lesen und auch nacheditieren im konkreten Testfall.
Und er generiert dann das ausführbare Script für den Testautomatisierungs-Plattform, in unserem Fall war das halt Pre-Write. Und dann wird der Testfall durchgeführt und so mache ich Schritt für Schritt und beim nächsten Mal läuft das durch und wenn etwas geändert wird in der Software, dann muss ich nur das aktualisieren, was geändert wurde, weil er dann an der Stelle stoppt und sagt, das klappt jetzt nicht, ich finde das Element nicht oder sonst irgendetwas gecheat.
Und dann muss ich den Schritt aktualisieren. Also das heißt, also wenn du, sagen wir mal so, der Clou steckt jetzt darin, dass diese abstrakten Testfälle, die der Automat oder ein Automat, der auch durchführt und immer wenn er nicht weiterkommt, sagt, was muss ich denn jetzt hier tun, was brauche ich hier für WT, um diese konkreten Werte auch mit aufzunehmen und abzuspeichern und so. Ja, genau.
Aber das hat auch technisch, hat das auch den Vorteil, dass das wachbar wird, weil in dem Moment, wo ich eine Aktion ändern muss, weil sich die Softwareimplementierung geändert hat, dann werden alle Stellen, wo diese Aktion durchgeführt wird, auch aktualisiert. Also es wird, Redundanzen werden zwar formal nicht reduziert, aber das MBT-Werkzeug ist in der Lage, diese Redundanzen dann auch zu aktualisieren, durchzuhalten.
Oder wenn, was bei uns in unserem Fall auch typischerweise vorkommt, ist, wenn die Entwickler nutzen ein Framework, um eine neue Oberfläche zu generieren. Und ich kann sie nicht davon überzeugen, dass die GUI-Elemente eine konstante ID haben müssen. Also einen Namen, der immer so bleibt und differenzierbar ist von den anderen. Und das heißt, dieses Framework, das generiert immer einen neuen Namen.
Und sobald sie ein kleines Buttonchen oder ein Elementchen eingefügt haben in der GUI, ist alles dahinter geändert. Und das ist ein ganz typisches Problem beim Automatisieren. Und das Tool kann damit recht vernünftig umgehen, indem es mich dann fragt: Hier ist ein Selektor, den ich nicht finde. Was soll ich machen? Und dann kann ich in die Liste der Selektoren gehen und die Selektoren anpassen. Und dann funktioniert es wieder. Jetzt hast du das ja mit der Glossar-App verprobt, quasi ausprobiert.
Ja. Das ist eine schöne Spielwiese. Wie können wir uns denn da so ein Modell vorstellen, von dem die Testfälle abgeleitet werden? Ja, das ist eine gute Frage. Ich habe mich in dem Vortrag vor allem auf diese zwei Phasen Lösung fokussiert. Das Werkzeug, das ich genutzt habe, hat ein eigenes Modell. Das hängt auch mit einem eigenen Testentwurfsverfahren zusammen, einem Blackbox-Verfahren. Und das sie action-stay-tut. Action-State-Testing nennen oder Aktion-Zustand-Test.
Es ist aber sehr ähnlich wie das zustandsbasierte Testen. Nur halt dem Tester näher gebracht. Das heißt also, das Modell, mit dem das arbeitet, geht in Richtung des Zustandsmodells. Ja. Allerdings ist es aktuell kein grafisches Modell. Sondern ein textbasiertes Modell. Und in dem Modell schreibe ich praktisch genau solche Testschritte auf, wie ich beim Testen auch gewohnt bin. Das heißt, ich schreibe eine Aktion auf, ein erwartetes Ergebnis, das zu prüfen ist, und einen Folgezustand.
Und im nächsten Schritt ist der Folgezustand vorausgesetzt. Und dann geht es weiter mit der nächsten Aktion. Zum Beispiel, ich gebe ein Such-Stand. Ich gebe einen Such-Text ein. Also der Anfangszustand muss dann sein, dass die Suche angezeigt wird. Und dann gebe ich einen Such-Test ein und prüfe, ob die Ergebnisse korrekt angezeigt werden. Dass die Anzahl der Ergebnisse mindestens eins ist. Und dass dieser Such-Test in den Treffern drin ist.
Und der Folgezustand ist, die Ergebnisliste ist angezeigt. Und dann wähle ich zum Beispiel ein Element aus. Was so spezifiziert ist. Und dann werden die Details dieses Begriffs angezeigt. Dann bin ich in dem nächsten Dialogzustand im Detailanzeigen. Oder ich drücke dann ein Back-Button und komme zurück zur Suchergebnisliste. Diese Zustände kann ich durch diese Schritte beschreiben. Und die Abfolge der Schritte im Modell durch ein Abflussdiagramm darstellen. Verstehe.
Das ist also schon eher szenario-basiert. Aber nutzt auch die Zustände. Und das hat mir geholfen. Natürlich habe ich nicht nur das als Test-Denturs-Verfahren genutzt. Sondern ich habe auch Äquivalenz-Klassen genutzt. Zum Beispiel, ich suche nicht nur nach Texten, die im Namen des Begriffs vorkommen. Sondern ich suche auch nach Texten, die in der Abkürzung vorkommen. Weil die Suche auch dafür funktionieren muss. Und nach Testen, die im Synonymen vorkommen.
Oder nach, was weiß ich, ich stelle die Parameter anders ein und suche. Also es ist insgesamt komplex. Aber man hat schon ein testrelevantes Zustandsmodell, das man abdecken kann. Jetzt, quasi dieses Zwei-Phasen-Modell, das du dann auch verprobt hast. Das schließt dir dann so ein bisschen die Lücke? Dazwischen. Gibt es denn da Herausforderungen, wo du sagst, da hängt es noch. Da müsste es noch besser werden. Es gibt immer Potenzial zur Verbesserung, sage ich mal.
Insbesondere, das ist ein ganz neues Tool. Das kommt jetzt gerade auf den Markt. Und ich habe die Gelegenheit genutzt, etwas Innovatives auszuprobieren. Aber wo ich zum Beispiel noch ein bisschen Verbesserungspotenzial sehe. Ist einerseits beim datengetriebenen Testen. Das heißt, die Testdaten, zum Beispiel der Text, den ich in den Begriffen suche. Dass ich diese Daten vielleicht auch separat ablegen kann und wiederverwenden kann in den nächsten Testfällen.
Und nicht nur so irgendwie irgendwelche Textverweise drauf, suche Text 1. Ein anderes, anderer Wunsch von mir wäre, eben mehr Testentflussverfahren zu unterstützen, wie zum Beispiel Qualitätsklassenbildung und Grenzwertanalyse. Nicht nur den zustandsbasierten Test. Dann könnte ich eine Testabdeckung erreichen, wie sie mir lieb ist. Insgesamt habe ich sehr viel getestet. Und auch wenn diese Anwendung geschäftlich vollkommen unkritisch ist. Niemand verliert einen Cent, wenn die nicht funktioniert.
Geschweige denn Personenschäden oder sowas. Aber es ist einfach eine Image-Sache. Ich als Testexperte möchte keine Anwendung aus der Hand geben, die nicht gut getestet ist. Ja klar, das muss dann schon passen. Ich finde es ist auch ein tolles Beispiel, einfach auch zu sehen, Testmethoden wirklich auch im Einsatz zu sehen. Und die Entwurfsverfahren auch wirklich nutzbar zu machen. Ich hatte gerade heute noch eine andere Aufnahme.
Das kriege ich so oft gespiegelt, dass viele Unternehmen oder viele Tester, die lernen die irgendwann mal. Äquivalenzklassen, Grenzwerkzustand, Entscheidungs-Tabellen und so. Aber in der Anwendung ist das dann doch eher so ein Bauchgefühl, wie ich die Testfälle schreibe. Also da ein strukturiertes Herangehen. Und das in Kombination mit dem Modellbasierten ist natürlich eine tolle Sache. Ja, ich finde es absolut wichtig. Und ich habe schon in der Industrie auch solche Erfahrungen gemacht.
Am interessantesten war ein Kunde, ich möchte jetzt keinen Namen nennen, aber ein Kunde, der ein großes Unternehmen, das vierteljährliche Releases implementiert hat, eingeführt hat. Und wo alle Fachleute über das Wochenende des Releasetags im Büro sein mussten und ad hoc getestet haben. Ja. Alle. Ich habe nur gefragt: "Ja und wann könnt ihr die Fehler beheben?" Ja. Na, wir hoffen es gibt keinen.
Aber das war für mich ganz klar das Zeichen, dass die Tester, die ausgebildeten Fachtester da ihren Job nicht richtig erfüllt haben. Und die kannten auch keine Testverfahren. Ja, da ist auf jeden Fall einiges noch zu tun. Ja. Wenn du jetzt so ein modellbasiertes Testen, viele, ich habe es ja am Anfang auch schon gesagt, viele haben ja da so ein bisschen eine Scheude von, weil man auch gar nicht wirklich weiß, was kann man denn damit machen, wie funktioniert denn das?
Was würdest du denn jemandem raten, der sagt, okay, ich möchte mich da ein bisschen intensiver damit auch auseinandersetzen? Hast du da irgendeinen Tipp, wie anfangen? Ja, ich würde für den Anfang, würde ich mir einfach eine Probeinstallation von einem guten Werkzeug herunterladen. Es gibt mehrere. Und ausprobieren, wie es damit geht. Und dann schauen, was mir passt und womit ich leicht umgehen kann.
Und wenn ich tagelang lernen muss, bevor ich überhaupt den ersten kleinen Testfall generieren kann, dann lasse die Finger da. Ja, das muss schon gut zugänglich sein. Das ist ja auch immer wichtig. Es muss ja im Alltag auch gut funktionieren. Ich glaube gerade auch für Tester, die näher am Fachlichen sind oder so, die eher aus der Ecke kommen, dass die dann einfach auch gut umgehen können mit so etwas.
Ja. Ein anderer wichtiger Faktor oder Vorteil dieses Tools, den ich empfunden habe, ist, dass das eine No-Code-Generierung ist, wenn man heute so modisch sagt. Das heißt also, ich kann als Fachtester wirklich an der GUI sagen, was man prüft und wie man das eingibt. Und ich muss kein Automatisierungsskript schreiben. Ja, sehr spannend. Was ich von früher her kenne. Da waren wirklich Automatisierer in der Hand. Automatisierer in unserem großen Projektteam.
Ein ganzes Style-Projekt, das nur automatisiert hat, was ich als Fachtester entworfen habe. Ja, ja, ja. Ja, sehr spannend. In fünf Jahren, 2029, treffen wir uns hier im German Testing Day wieder. Gerne. Und wir sagen: "Ach, Matthias, kannst du dich erinnern, vor fünf Jahren hatten wir doch diese coole Podcast-Folge da aufgenommen zum modellbasierten Testen. Was hat sich denn seitdem supergroßes getan?
Was glaubst du, wird das in den nächsten fünf Jahren im modellbasierten Testen so das "next big thing"? Also ich hoffe, dass in modellbasierten Testen halt die Werkzeuge so gut sein werden, dass man das auch in der Industrie viel breiter nutzt. Und dadurch kommt die Anwendung der systematischen Testverfahren auch viel breiter zum Einsatz. Und das ist mein Wunsch. Ja, gut. Wir werden das prüfen in fünf Jahren, ob das so ist, ob das so geklappt hat.
Und diese Sogetik, ich habe die Umfrage gemacht, hat resigniert festgestellt, wir haben schon so lange Jahre daran gearbeitet an der Automatisierung und es klappt nicht. Ich gebe die Hoffnung nicht auf. Ja, ja. Ein positiver Blick in die Zukunft. Ja. Sehr schön. Matthias, vielen lieben Dank für die Einsichten hier zu dem Thema. Gern geschehen. Hat mir großen Spaß gemacht, dich hier mal auch im Podcast zu haben. Wird wahrscheinlich nicht das letzte Mal gewesen sein.
Und auf jeden Fall, ich wünsche dir noch eine schöne Konferenz. Dankeschön. Bis bald. Bis dann. Untertitelung des ZDF, 2020