Modellbasiertes Testen bezeichnet einen Ansatz, bei dem Testfälle systematisch aus einem formalen Modell des Systemverhaltens abgeleitet werden. Das zentrale Problem in der Praxis ist die Lücke zwischen abstraktem Modell und konkreter Testdurchführung. Ein Zwei-Phasen-Ansatz überbrückt diese Lücke: Erst entstehen abstrakte Testfälle aus dem Modell, dann werden konkrete Testdaten und Automatisierungsskripte interaktiv ergänzt.
Das Wichtigste in Kürze
- Modellbasiertes Testen scheitert in der Praxis oft an der Lücke zwischen abstraktem Testentwurf und konkreter Testrealisierung, weil konkrete Testdaten und GUI-Aktionen das Modell unnötig komplex machen.
- Ein Zwei-Phasen-Ansatz löst dieses Problem: Zuerst werden abstrakte Testfälle aus dem Modell generiert und manuell ausführbar gehalten, erst danach werden konkrete Daten und Automatisierungsskripte ergänzt.
- Testautomatisierung erreicht laut dem World Quality Report von Capgemini die gesetzten Geschäftsziele bislang nicht: weder reibungslose CI/CD-Pipelines noch Effizienzsteigerungen noch messbar bessere Softwarequalität.
- Systematische Testentwurfsverfahren wie Äquivalenzklassenbildung oder Grenzwertanalyse werden von ausgebildeten Testern in der Praxis kaum angewendet, stattdessen dominiert Bauchgefühl beim Schreiben von Testfällen.
Was modellbasiertes Testen ist und wo es klemmt
Modellbasiertes Testen leitet Testfälle aus einem Modell ab, statt sie einzeln von Hand zu schreiben. Der Tester legt fest, was abgedeckt werden soll, modelliert das und generiert daraus die Testfälle. Die Idee ist alt und attraktiv. In der Praxis läuft sie selten rund.
Matthias Hamburg hat den Ansatz als Testmanager in mehreren Projekten eingeführt. Sein Urteil ist nüchtern: “Es lief nie so rund.” Das deckt sich mit Branchenbeobachtungen. Der World Quality Report von Capgemini und Sogeti stellt fest, dass Testautomatisierung insgesamt die geschäftlichen Ziele nicht erreicht hat, die man mit ihr verbunden hatte.
Drei Erwartungen blieben offen: ein reibungsloser CI/CD-Betrieb mit Automatisierung, die erhoffte Effizienzsteigerung und eine messbar bessere Softwarequalität. Befragt wurden Manager und Unternehmensleitung, die auf Geschäftsziele schauen. Genau diese Ziele wurden verfehlt.
Warum die meisten MBT-Ansätze an der Realität scheitern
Zwei Hürden stehen modellbasiertem Testen im Weg. Die erste betrifft die Menschen, die zweite den Werkzeug-Workflow.
Die erste Hürde: Wer Modelle erstellt, ist meist nicht in Modellierung ausgebildet. Formale Modelle verlangen Training, das Tester selten haben. Praktikabel sind deshalb nur Modelle, die ohne langen Vorlauf verständlich bleiben und nah an der Denkweise des Testers liegen.
Die zweite Hürde sitzt im Ablauf selbst. Modellbasiertes Testen bietet derzeit keinen nahtlosen Übergang von der Modellierung bis zum durchgeführten Test. Genau in dieser Lücke entstehen die Probleme.
Wo die Lücke im Testprozess sitzt
Das ISTQB-Modell der Testaktivitäten ordnet die Schritte klar: Testanalyse, Testentwurf, Testrealisierung, Testdurchführung. Im Testentwurf wird festgelegt, was abgedeckt werden soll, das sind die Testbedingungen. Aus dem Modell lassen sich dann Testfälle generieren. Die Durchführung ist mit Tools wie Selenium oder Playwright längst automatisierbar.
Dazwischen liegt die Testrealisierung, und sie ist der Knackpunkt. Hier werden konkrete Testdaten ausgewählt, hier wird festgelegt, welche Buttons gedrückt und welche konkreten Ergebnisse geprüft werden. Es ist der Schritt vom Abstrakten zum Konkreten.
Die übliche Antwort der MBT-Werkzeuge: Sie packen die konkreten Daten gleich mit ins Modell. Das macht das Modell jedoch sehr komplex. Ein Modell soll abstrahieren, eine logische Sicht liefern. Konkrete Daten hineinzuziehen, bricht diese Sicht. Genau diese Überfrachtung ist ein Grund, warum sich modellbasiertes Testen nicht durchgesetzt hat.
Der Zwei-Phasen-Ansatz schließt die Lücke, ohne das Modell zu überladen
Ein neuerer Ansatz trennt Abstraktion und Konkretisierung in zwei Phasen. Zuerst entstehen aus dem Modell abstrakte Testfälle. Diese müssen manuell durchführbar sein, denn beim manuellen Testen ergänzt der Mensch die offenen Stellen ohnehin selbst.
Phase eins lässt sich früh erledigen, bevor die Software fertig ist. Das ist der Shift-Left-Vorteil: Wer früh modelliert, sichert über die Modellierung die Qualität der Testbasis und der Spezifikation. Dann hält man an, ohne Angst vor einem Paradigmenwechsel.
Phase zwei beginnt, sobald die echte Anwendung läuft. Das Werkzeug führt die abstrakten Testfälle aus und fragt an den offenen Stellen zurück: Was heißt “Text eingeben” hier konkret? Es blendet die Dialogoberfläche ein, du gibst den passenden Text ein und lässt die Aktion aufnehmen.
Das ist kein simples Capture-and-Replay. Frühere Capture-Tools erzeugten Skripte, die hinterher oft nicht mehr liefen, mit entsprechenden Wartbarkeitsproblemen. Hier wird aus der fachlichen Ebene zuerst die Aktion auf GUI-Ebene generiert. Diese Aktion ist lesbar und im konkreten Testfall nacheditierbar. Daraus entsteht dann das ausführbare Skript für die Automatisierungsplattform, im erprobten Fall Playwright.
Warum dieser Ansatz wartbar bleibt
Wartbarkeit ist der eigentliche Gewinn. Ändert sich eine Aktion, weil die Implementierung sich geändert hat, werden alle Stellen aktualisiert, an denen diese Aktion vorkommt. Die Redundanz wird zwar formal nicht reduziert, aber das Werkzeug hält sie konsistent.
Ein typisches Praxisproblem zeigt den Nutzen besonders deutlich. Manche UI-Frameworks generieren bei jeder kleinen Änderung neue IDs für die GUI-Elemente. Sobald irgendwo ein Button dazukommt, ist alles dahinter umbenannt. Das bricht klassische Automatisierung.
Das Tool geht damit pragmatisch um. Es stoppt an der Stelle, an der es einen Selektor nicht findet, und fragt nach. Du passt den Selektor in der Liste an, danach läuft der Test wieder. Aktualisiert werden muss nur, was sich tatsächlich geändert hat.
Action State Testing: ein Zustandsmodell in der Sprache der Tester
Das erprobte Werkzeug bringt ein eigenes Modell mit, gekoppelt an ein Blackbox-Verfahren namens Action State Testing. Inhaltlich liegt es nah am zustandsbasierten Testen, ist aber näher an der Arbeitsweise des Testers formuliert.
Das Modell ist aktuell textbasiert, nicht grafisch. Du schreibst Testschritte so auf, wie du es beim Testen ohnehin gewohnt bist: eine Aktion, ein zu prüfendes erwartetes Ergebnis, ein Folgezustand. Der Folgezustand eines Schritts ist die Voraussetzung für den nächsten.
Ein Beispiel aus der Glossar-Anwendung macht das greifbar. Anfangszustand: die Suche wird angezeigt. Aktion: einen Suchtext eingeben. Prüfung: die Trefferzahl ist mindestens eins und der Suchtext steht in den Treffern. Folgezustand: die Ergebnisliste ist angezeigt. Wählt man ein Element, erscheinen die Details, ein Back-Button führt zurück zur Trefferliste.
Die Abfolge der Schritte lässt sich als Ablaufdiagramm darstellen. Das Ergebnis ist szenario-basiert und nutzt zugleich die Zustände, ein testrelevantes Zustandsmodell, das sich systematisch abdecken lässt.
Ein Verfahren allein reicht nicht
Modellbasiertes Testen ersetzt die klassischen Entwurfsverfahren nicht, es kombiniert sie. In der Glossar-App kam neben dem zustandsbasierten Ansatz auch Äquivalenzklassenbildung zum Einsatz. Gesucht wurde nicht nur nach Texten aus dem Namen eines Begriffs, sondern auch nach Abkürzungen und Synonymen, weil die Suche für alle drei funktionieren muss.
Hier liegt eine verbreitete Schwäche in der Praxis. Viele Tester lernen Äquivalenzklassen, Grenzwertanalyse, Zustands- und Entscheidungstabellen einmal, wenden sie im Alltag aber eher nach Bauchgefühl an. Ein strukturiertes Vorgehen, kombiniert mit Modellierung, holt diese Verfahren zurück in die tägliche Arbeit.
Wie weit es ohne solche Disziplin geht, zeigt ein Negativbeispiel aus der Industrie. Ein großes Unternehmen mit vierteljährlichen Releases ließ alle Fachleute am Release-Wochenende ins Büro kommen und ad hoc testen. Auf die Frage, wann denn gefundene Fehler behoben würden, lautete die Antwort: “Wir hoffen, es gibt keinen.” Ein klares Zeichen, dass ausgebildete Tester ihren Job nicht erfüllten und keine Testverfahren kannten.
Offene Baustellen des Ansatzes
Kein Werkzeug ist fertig, und dieser Ansatz ist neu am Markt. Zwei Wünsche bleiben.
- Datengetriebenes Testen: Testdaten wie der Suchtext sollten sich separat ablegen und in weiteren Testfällen wiederverwenden lassen, statt nur als loser Textverweis im Schritt zu stehen.
- Mehr Entwurfsverfahren: Über das zustandsbasierte Testen hinaus wären Äquivalenzklassenbildung und Grenzwertanalyse direkt im Tool hilfreich, um die gewünschte Testabdeckung sauber zu erreichen.
Trotz dieser Lücken ließ sich die Anwendung umfangreich testen. Auch wenn die Glossar-App geschäftlich unkritisch ist und niemand einen Cent verliert, bleibt es eine Frage der Haltung: Ein Testexperte gibt keine Anwendung aus der Hand, die nicht gut getestet ist.
Wie du mit modellbasiertem Testen anfängst
Die Scheu vor modellbasiertem Testen kommt oft daher, dass unklar ist, was man damit überhaupt tun kann. Der pragmatische Einstieg führt über das Ausprobieren, nicht über die Theorie.
Lade dir eine Probeinstallation eines guten Werkzeugs herunter, es gibt mehrere. Probiere aus, wie sich damit arbeiten lässt, und prüfe, was zu dir passt und womit du leicht umgehen kannst.
Wenn ich tagelang lernen muss, bevor ich überhaupt den ersten kleinen Testfall generieren kann, dann lass die Finger davon. — Matthias Hamburg
Zugänglichkeit ist der Maßstab. Ein Pluspunkt des erprobten Tools ist die No-Code-Generierung. Als Fachtester legst du direkt an der GUI fest, was geprüft und wie eingegeben wird, ohne ein Automatisierungsskript zu schreiben. In früheren Großprojekten brauchte es dafür ein eigenes Teilprojekt aus Automatisierern, das umsetzte, was die Fachtester entworfen hatten.
