Modellbasiertes Testen (MBT)

Modellbasiertes Testen bedeutet, grafische Darstellungen wie Flowcharts zu nutzen, um Testabläufe sichtbar zu machen und daraus systematisch Testfälle zu generieren. Es klärt früh, was getestet werden soll, macht implizite Annahmen in Anforderungen explizit und bildet eine Brücke zur Testautomatisierung. Werkzeuge generieren aus dem Modell entweder textuelle Testfälle oder ausführbare Skripte.

Das Wichtigste in Kürze

• Modellbasiertes Testen funktioniert ohne UML-Kenntnisse: Kästchen, Pfeile, Entscheidungsknoten und Unterdiagramme reichen als Werkzeugpalette aus.
• Flowcharts machen implizite Annahmen explizit, weil jeder Beteiligte Lücken in Anforderungen unbewusst mit seinem eigenen Erfahrungsschatz füllt und das voneinander abweichende Verständnis erst im Modell sichtbar wird.
• Aus demselben Modell lassen sich sowohl manuelle Testfallbeschreibungen als auch Keyword-Skripte für die Testautomatisierung generieren, ohne das Modell selbst zu verändern.
• Testfallexplosion durch Schleifen und Kombinatorik wird über Überdeckungskriterien beherrscht: Mindestanforderung ist, dass jede modellierte Testvariante in mindestens einem generierten Testfall vorkommt.

Was modellbasiertes Testen wirklich bedeutet

Modellbasiertes Testen heißt, eine grafische Darstellung dessen zu nutzen, was getestet werden soll, und daraus Testfälle abzuleiten. Das ISTQB definiert es zwar sehr breit als jedes Testen, das Modelle einbezieht. Im Kern geht es aber um grafische Modelle und um die Tools, die aus diesen Modellen Testfälle oder Testskripte generieren.

Die grafische Repräsentation ist das wirklich Wichtige an der ganzen Sache. Statt von UML- oder Aktivitätsdiagrammen zu sprechen, hilft der schlichtere Begriff Flowchart. Jeder Pfad durch einen Flowchart ergibt einen möglichen Testfall. Dasselbe Prinzip greift bei Zustandsdiagrammen: Die verschiedenen Pfade durch das State Chart bilden die verschiedenen Testfälle.

Anne Kramer arbeitet seit Jahren mit dieser Methode und plädiert dafür, sie von ihrem schwergewichtigen Ruf zu lösen. Der Begriff “modellbasiertes Testen” trägt einen Beigeschmack von kompliziert, von Expertenwissen, von zwingend vorhandener Testautomatisierung. Treffender wäre oft “visuelles Testdesign”. Denn genau das passiert, wenn jemand mit Kästchen und Pfeilen beschreibt, was ein System tun soll.

Welche Testarten sich besonders eignen

Modelle aus Flowcharts spielen ihre Stärke dort aus, wo der Blick auf das System abstrakt bleibt. In der Sprache des V-Modells sind das die oberen Ebenen, in der Sprache der Testpyramide ebenfalls die oberen Schichten. Gemeint sind Systemtests und Systemakzeptanztests.

Diese Tests beschreiben ganze Abläufe statt einzelner Klicks. Ein Beispiel: vom Anlegen des Kunden über den Datensatz in der Datenbank bis zur tatsächlich versendeten Ware. Der Tester denkt in Fällen, nicht in Mausbewegungen. Wer unter 16 ist, bekommt in Bayern kein Bier. Wer zwischen 16 und 18 ist, bekommt Bier, aber keinen Schnaps. Über 18 gibt es alles. Wie der Ablauf an der Kasse konkret aussieht, ist für diese Überlegung egal.

Zustandsbasierte Modelle lassen sich auch für Unit-Tests einsetzen. Und neben den grafischen gibt es Ansätze, die auf textuellen Modellen basieren. Die Bandbreite ist groß, der praktische Schwerpunkt liegt aber auf den Abläufen weiter oben.

Das Modell entsteht früh, oft beim Tester

Der größte Vorteil liegt darin, sich früh zu klären, was wie getestet werden soll. Sobald feststeht, was ein System leisten soll, lassen sich Abläufe definieren, lange bevor klar ist, wie ein Button heißt oder in welcher Reihenfolge die Eingabemasken kommen.

Eigentlich gehört das Modellieren ins Requirements Engineering. Die Idee stammt aus dem Umfeld des Unified Process, dort kommt UML her. Der Gedanke war: Anforderungen grafisch darzustellen macht sie leichter erfassbar. In der Praxis passiert das selten. Projekte starten mit textuellen Anforderungen oder einem Product Backlog, und ein Großteil der nötigen Information bleibt in den Köpfen der Stakeholder.

Genau diese verborgene Information sichtbar zu machen, ist der eigentliche Mehrwert. Und auffällig oft sind es die Tester, die das Modell bauen. Entwickler denken sich etwas aus und fragen, ob es funktioniert. Tester wollen vorher wissen, was richtig und was falsch ist, was gefordert ist und was nicht. Dieses Klärungsbedürfnis macht sie zu guten Modellierern.

Warum jedes Modell Fragen ans Licht bringt

Sobald jemand anfängt, ein Modell zu zeichnen, entstehen Fragen, die im Text nie auftauchten. Was passiert beim Klick auf Cancel? Wird wirklich jeder Datensatz gespeichert? Die ersten Versionen eines Modells sind voller gelber Notizzettel. Das Notizfeld ist ein zentrales Modellierungselement, weil sich daran offene Punkte festmachen lassen.

Das Modell wird damit zum Kommunikationsmittel. Du kannst zeigen: So habe ich den Ablauf verstanden, stimmt das mit deinen Plänen überein, und hier und hier habe ich noch Fragen. Diese Fragen lassen sich gezielt adressieren.

Modelle machen implizite Annahmen explizit. Das menschliche Gehirn mag keine Lücken und füllt fehlende Information mit dem eigenen Erfahrungsschatz auf. Jeder ist zufrieden, weil jeder glaubt, den Text verstanden zu haben. Nur sind die Erfahrungsschätze unterschiedlich, und das Verständnis weicht voneinander ab. Erst das gezeichnete Modell macht sichtbar, dass dein Verständnis von dem des anderen abweicht.

Im Requirements Engineering gibt es dafür sogar eine eigene Review-Methode: die Transformation in eine andere Dokumentationsform. Wer Anforderungen vom Text in ein Modell überführt, stößt zum ersten Mal auf die Unstimmigkeiten, die beim wiederholten Lesen unsichtbar blieben. Je früher dieser Schritt passiert, desto mehr Shift-Left-Testing entsteht daraus.

Modelle funktionieren auch mit Papier und Bleistift

Modellbasiertes Testen braucht keine vollständige UML-Notation und keine fertige Testautomatisierung. Es lässt sich sogar mit Papier und Bleistift betreiben. Dabei geht zwar der Vorteil der automatischen Testfallgenerierung verloren, doch selbst dieser pragmatische Ansatz mit geringem Reifegrad schlägt die Variante ganz ohne Modell.

Je pragmatischer ich vorgehe, desto besser funktioniert es. Die Modellierungspalette reicht: Ich brauche Kästchen und Pfeile, die Möglichkeit für Unterdiagramme, Startknoten, Endknoten und vielleicht einen Entscheider.

— Anne Kramer

Schon dieser einfache Einstieg zahlt sich aus, bei der Kommunikation, bei der Klarheit und beim Beherrschen von Komplexität. Ein Modell kann sogar aus einem Meeting oder einer Vorführung entstehen, nicht nur aus formalen Anforderungen.

Vom Modell zum Testfall: wie die Generierung läuft

Nach den Abläufen folgt der zweite Schritt: festlegen, was getestet werden soll. Hier greift das Teile-und-herrsche-Prinzip. Die Abläufe bestehen aus Blöcken, meist Aktionen. Zu jeder Aktion lässt sich überlegen, was zu testen ist. Auf dieser Ebene geht es um einzelne Requirements oder User Stories und ihre Akzeptanzkriterien.

Auch diese Überlegungen lassen sich mit der Entwicklung teilen, damit klar ist, was im Fehlerfall geschehen soll, also was das erwartete Ergebnis ist. Danach wird es toolspezifisch. Ein Testfallgenerator läuft vom Startpunkt durch das Modell, sammelt Schritt für Schritt die hinterlegten Informationen über die verschiedenen Pfade ein und baut daraus ein Szenario.

Was am Ende herauskommt, hängt davon ab, was im Modell steckt. In den meisten Fällen entstehen textuelle Szenarien für den manuellen Test. Hinterlegst du dagegen Schlüsselwörter aus einem Keyword-Driven-Ansatz, baut das Tool ein Skript aus Funktionsaufrufen. Die Keywords müssen anschließend noch implementiert werden, doch der Aufbau des Skripts steht bereits.

Genau hier bildet modellbasiertes Testen eine Brücke. Aus demselben Modell lassen sich sowohl manuelle Textbeschreibungen als auch Automatisierungsskripte erzeugen.

Tools unterscheiden sich in Offenheit und Anbindung

Bei der Werkzeugwahl lassen sich grob zwei Typen unterscheiden. Die einen sind relativ geschlossen und binden ihr eigenes Testautomatisierungsframework direkt an, für das sie dann auch generieren. Die anderen sind offener und exportieren in verschiedenste Formate.

Gängige Testmanagement- und ALM-Werkzeuge wie X-Ray, Jira oder ALM lassen sich anbinden, ebenso Durchführungswerkzeuge. Fehlt ein benötigtes Ausgabeformat, ist es laut den Herstellern meist kein großer Aufwand, es zu ergänzen, weil im Grunde nur eine passende Formatierung erzeugt werden muss.

Testfallexplosion bewusst beherrschen

Mit modellbasiertem Testen wird oft das Stichwort Testfallexplosion verbunden. Sie entsteht zum Beispiel durch Rückschleifen: Wenn ein Schritt fehlschlägt und der Ablauf vorne wieder einsteigt, lässt sich die Schleife ein-, zwei- oder beliebig oft durchlaufen. Zusammen mit der Kombinatorik wächst die Zahl der Pfade rasch.

Der zentrale Hebel dagegen ist Überdeckung. Im Modell steht hinterlegt, was getestet werden soll, also alle Fälle, die mindestens einmal vorkommen müssen. Die minimale Forderung lautet: Jeder definierte Testfall taucht in mindestens einem generierten Szenario auf.

Darüber hinaus lassen sich verschiedene Überdeckungsziele wählen:

• alle Aktivitäten
• alle Äquivalenzklassen von Datenwerten
• im Zustandsdiagramm alle Zustandsübergänge

Welche Methoden konkret zur Verfügung stehen, hängt stark vom Werkzeug ab.

Modelle aktuell halten: zwei Strategien

Im agilen Kontext ändert sich das System ständig, und das Modell verändert sich mit. Voraussetzung für den Umgang damit ist Konfigurationsmanagement für die Modelle. Du musst wissen, welches Modell zur Generierung welcher Testfälle diente und was sich zwischen den Versionen geändert hat. Sonst lässt sich irgendwann nicht mehr zuordnen, welches Modell zu welchem Sprint gehörte.

Für den Umgang mit geänderten Testfällen gibt es zwei Grundstrategien.

Das reine Wegwerfen scheitert oft am Prozess. Wer manuell testet, will Teile des letzten Durchlaufs wiederverwenden oder begründen, dass ein Ergebnis noch gültig ist, weil sich nichts geändert hat. Beim synchronisierenden Ansatz behalten die Testfälle ihre ID, sehen weitgehend aus wie zuvor und enthalten nur die neuen Schritte, etwa eine zusätzliche Abfrage, die jetzt weggeklickt werden muss. Beide Wege haben ihre Berechtigung.

Drei Gründe, die für visuelles Testdesign sprechen

Der Nutzen lässt sich auf drei Punkte verdichten.

Erstens ist es ein starkes Kommunikationsmittel, um früh zu klären, was zu tun ist. Wer das ganz vorne im Prozess macht, kann sich die separate Detaillierung der Anforderungen teilweise sparen und gleich in den Testfällen arbeiten. So entsteht eine akzeptanztestgetriebene Entwicklung, auch mit Modellen.

Zweitens macht es die Arbeit einfacher und effizienter. Ein Modell zu zeichnen macht mehr Spaß als seitenweise Testspezifikationen zu schreiben, und es lässt sich leichter reviewen. Ein Modell schaut sich jemand ein drittes oder viertes Mal an. Eine 200-seitige Testspezifikation tut das niemand. Außerdem zeigt das Modell besser, ob alle Anforderungen abgedeckt sind, und die Testqualität wird messbar.

Drittens bildet es die Brücke zur Automatisierung. Auch wer nicht programmiert, kann zur Automatisierung beitragen, weil sich aus dem Modell Keyword-Skripte generieren lassen.

Visuelles Testdesign kommt zurück, KI senkt die Hürde

Die pragmatische Variante des modellbasierten Testens erlebt gerade ein Comeback. Lange war das Thema zu eng mit Embedded Systems und Automatisierung verknüpft. Nun rückt das rein Grafische in den Vordergrund, vergleichbar mit dem Trend zu No-Code- und Low-Code-Automatisierungstools. Neue Werkzeuge kommen auf den Markt, das Interesse wächst.

Ein Grund liegt in der Agilität selbst. Der Blick auf User Stories funktioniert gut, doch der systematische Gesamtblick leidet. Über Epics und Features ist der Überblick längst nicht so klar, und vieles landet im explorativen Testen. Genau diese Systemsicht liefert ein Modell zurück.

Der nächste Schub kommt von künstlicher Intelligenz. Modellieren erfordert Abstraktionsvermögen, und gerade dieser erste Schritt fällt vielen schwer, die jahrzehntelang Schritt für Schritt beschrieben haben. KI könnte bestehende Modelle, Testfälle und Requirements analysieren und einen ersten Entwurf erzeugen. Solche Aktivitäten gibt es bereits, teils sind sie schon in Produkte eingebaut.

Es bleibt ein Vorbehalt. Der mentale Aufwand, sich mit dem zu testenden System auseinanderzusetzen, ist einer der großen Mehrwerte. Übernimmt die KI das, bekommst du einen vorgekauten Text, den du nur noch durchwinkst, ohne selbst nachgedacht zu haben. Ob das der Sache dient, ist fraglich. Was KI aber leistet: Sie senkt die Hemmschwelle. Vielleicht funktioniert es in zwei Schritten. Die KI nimmt die erste Hürde, und wer sich an die Art der Formulierung gewöhnt hat, schreibt das nächste Modell leichter von null an selbst.