MODEL-BASED TESTING · SEIT 2013

Ich male mir meinen Test.

Meine Reise mit Model-Based Testing – von Excel und HP ALM über eine Offshore-TestFactory und Shift Left bis hin zu künstlicher Intelligenz.

Seit 2013 beschäftigt mich Model-Based Testing (MBT). Was mit einem ganz praktischen Problem begann, hat meine Sicht auf Testanalyse, Testdesign und die Zusammenarbeit in Projekten nachhaltig verändert.

Dabei habe ich erlebt, wie aus einem kleinen Versuch eine dauerhaft etablierte Arbeitsweise wurde. Ich habe Menschen kennengelernt, die meine Denkweise verändert haben. Und ich habe gelernt, dass eine gute Methode allein noch lange keine erfolgreiche Veränderung garantiert.

Hier erzähle ich meine Geschichte.

Meine Reise im Überblick

2013 – Wenn Veränderungen zum Problem werden

2013 arbeitete ich in einem agilen Projekt zur Modernisierung einer Schalteranwendung bei einer Bank.

Veränderungen gehörten zum Alltag. Sie waren willkommen und ausdrücklich gewünscht. Mein damaliges Vorgehen in der Testanalyse konnte damit allerdings nicht besonders gut umgehen.

Ich analysierte die Tests in Excel und übertrug die einzelnen Testfälle anschließend manuell nach HP ALM. Änderte sich eine Anforderung, musste ich zunächst meine Excel-Tabellen überarbeiten, die betroffenen Testfälle identifizieren und anschließend jeden einzelnen Testfall in HP ALM anpassen.

Das funktionierte grundsätzlich. Es verursachte allerdings eine Menge Arbeit.

Wenn das Projekt Veränderungen willkommen heißt, muss auch mein Test damit umgehen können.

Also machte ich mich auf die Suche nach einer besseren Lösung.

Und plötzlich hatte ich ein Bild

Bei meiner Suche entdeckte ich die MBTsuite von sepp.med. Dass ich damit gerade in das Thema Model-Based Testing einstieg, war mir damals vermutlich noch gar nicht bewusst. Ich wollte zunächst einfach mein Problem lösen.

Mit der MBTsuite konnte ich das erwartete Systemverhalten in Aktivitätendiagrammen modellieren. Aus diesen Modellen wurden automatisch Testfälle abgeleitet und nach HP ALM übertragen.

Ich musste nicht mehr jeden einzelnen Testfall von Hand eintippen. Noch wichtiger war für mich allerdings etwas anderes: Wenn sich Anforderungen änderten, konnte ich mein Modell anpassen, die Testfälle neu generieren und die Änderungen in HP ALM übernehmen lassen.

Plötzlich konnte ich mit den Veränderungen im Projekt mithalten.

MBT musste ich erst einmal verstehen

Ganz so einfach, wie es heute klingt, war mein Einstieg nicht. Ich musste meine bisherige Denkweise verändern.

Schließlich kam ich aus einer Welt, in der ich Testfälle einzeln analysiert, beschrieben und gepflegt hatte. Jetzt sollte ich nicht mehr zuerst den einzelnen Testfall betrachten, sondern das Verhalten des Systems modellieren.

Bei diesem Umdenken hat mich Martin Beißer von sepp.med sehr unterstützt. Dafür bin ich ihm bis heute dankbar. Ich weiß nicht, ob ich ohne seine Unterstützung damals an dem Thema drangeblieben wäre.

Zum Glück bin ich es.

Der eigentliche Aha-Moment

Anfangs war Model-Based Testing für mich vor allem eine Antwort auf ein Effizienzproblem. Erst später erkannte ich, dass mir das Modell etwas noch Wertvolleres gab: eine andere Diskussionsbasis mit dem Fachbereich.

Ich konnte anhand eines Bildes zeigen, wie ich eine fachliche Anforderung verstanden hatte und wie ich sie testen wollte. Welche Abläufe gibt es? Welche Entscheidungen sind möglich? Welche Varianten müssen wir berücksichtigen?

Statt mit dem Fachbereich 30 oder 50 einzelne Testfälle in HP ALM durchzugehen, konnten wir gemeinsam auf ein Aktivitätendiagramm schauen.

Wenn du dir 50 Testfälle nacheinander durchliest – kannst du danach wirklich sagen, ob wir an alles gedacht haben?

Mit einem Modell wurde das für uns wesentlich einfacher.

Irgendwann wollte ich deshalb einen Vortrag mit dem Titel „Ich male mir meinen Test“ halten. Der Titel war wohl nicht wissenschaftlich genug und wurde abgelehnt.

Vielleicht sollte ich ihn heute noch einmal einreichen.

2014 – Eine Challenge, viel Skepsis und ein erfolgreicher Proof of Concept

Ende 2013 kam ich in ein Projekt bei einer Luftfrachtgesellschaft. Die bestehende Kernsoftware für Sales und Handling sollte abgelöst werden. Meine ursprüngliche Aufgabe lag in der Business Analyse rund um Allotments.

Drei Systeme mussten miteinander integriert werden. Für die späteren Tests war eine Offshore-TestFactory vorgesehen.

Nachdem wir die Business Analyse abgeschlossen hatten, kam die nächste Aufgabe: Wir brauchten ja auch noch Abnahmetests.

Aufgrund meiner bisherigen Erfahrungen schlug ich vor, die Testfälle modellbasiert zu erstellen. Die Begeisterung hielt sich zunächst in Grenzen.

Ich erlebte eine Menge Skepsis. Das Vorgehen war für viele Beteiligte neu, und wir hatten einen engen Zeitplan. Irgendwann wurde daraus eine Challenge. Mein Angebot war ziemlich einfach:

Wenn das mit MBT nicht funktioniert, schreibe ich euch die benötigten Testfälle kostenlos auf traditionelle Art und Weise.

Ich hatte Glück. Nein, eigentlich wusste ich, dass der Ansatz funktioniert.

Wenn die gewohnten Metriken nicht mehr funktionieren

Was ich anfangs unterschätzt hatte, war die Veränderung für das Test- und Projektmanagement.

Die klassischen Testmanager waren gewohnt, den Fortschritt der Testanalyse anhand der Anzahl erstellter Testfälle zu verfolgen. Heute 20 neue Testfälle. Morgen wieder 20.

Bei meinem modellbasierten Vorgehen funktionierte das nicht mehr. Ich analysierte Anforderungen, erstellte Modelle und bereitete die Reviews mit den Fachbereichen vor. Nur entstanden dabei nicht jeden Tag neue Testfälle im Testmanagement-Werkzeug.

Die gewohnten Fortschrittsmetriken funktionierten plötzlich nicht mehr. Test- und Projektmanager begannen, an der Methode zu zweifeln.

Ich machte trotzdem weiter.

Eine Woche vor der Deadline

Pünktlich eine Woche vor der Deadline waren meine Testmodelle fertig. Inklusive der Reviews mit den entsprechenden Fachbereichen.

Anschließend generierte ich die benötigten Testfälle, übertrug sie in das Testmanagement-Werkzeug und stellte die Traceability zu den Anforderungen her. Fertig.

Innerhalb des knappen Zeitfensters hatte ich alles geliefert. Im September 2014 hatten wir damit einen erfolgreichen Proof of Concept.

Zu diesem Zeitpunkt benötigten wir manuelle Testfälle, die später von der Offshore-TestFactory ausgeführt wurden. Model-Based Testing bedeutete für uns also keineswegs, dass wir die Testdurchführung automatisieren mussten.

Wir automatisierten zunächst die Erstellung der Testfälle. Nicht ihre Ausführung.

Das war für unser Projekt genau der richtige Ansatz.

Aus einem Proof of Concept wurde eine neue Arbeitsweise

Dass unser Proof of Concept so reibungslos funktioniert hatte, sorgte für einiges Aufsehen. Auch andere Bereiche des Projekts interessierten sich für Model-Based Testing. Und die Offshore-TestFactory wollte die Methode ebenfalls kennenlernen.

Aus meinem ursprünglichen Versuch wurde etwas Größeres. Gemeinsam entwickelten wir Good Practices und Modelling Guidelines.

Unser Ziel war es, die Offshore-TestFactory in die Lage zu versetzen, mithilfe von MBT die richtigen Testfälle in kürzerer Zeit zu erstellen und anschließend wartbar zu halten. Fachliche Reviews sollten fester Bestandteil des Vorgehens werden. Die manuelle Tipperei im Testmanagement-Werkzeug wollten wir möglichst vermeiden.

Wir begannen mit einzelnen Teams, sammelten Erfahrungen und verbesserten unser Vorgehen. Nach und nach kamen weitere Teams hinzu.

Schließlich arbeiteten alle Teams der TestFactory bei diesem Kunden modellbasiert. Und das ist keine Geschichte, die nach ein paar Jahren wieder zu Ende war.

2014 eingeführt. Stand 8. Oktober 2026 noch immer im Einsatz.

Was mit einer Challenge und viel Skepsis begann, hat sich zu einer dauerhaft etablierten Arbeitsweise entwickelt.

Nicht jedes Modell ist ein gutes Modell

Natürlich hat nicht alles auf Anhieb funktioniert. Wir haben auch Fehler gemacht und daraus gelernt. Zum Beispiel bei der Frage, wie groß ein Modell eigentlich werden sollte.

Ein Modell, das versucht, das komplette Geschäft einer Luftfrachtgesellschaft abzubilden, kann schnell zum Problem werden. Entweder entstehen bei der Testfallgenerierung unüberschaubar viele Testfälle. Oder das Modell wird so groß, dass ein normaler Rechner nicht mehr ausreicht, um daraus Testfälle zu generieren.

Testfallexplosion oder Notebook-Explosion. Beides keine besonders attraktiven Alternativen.

Diese Erfahrungen flossen ebenfalls in unsere Modelling Guidelines ein.

Denn Model-Based Testing bedeutet nicht, möglichst große oder detaillierte Modelle zu erstellen. Es geht darum, die richtige Abstraktion und einen sinnvollen Zuschnitt für die jeweilige Testaufgabe zu finden.

Was ich aus diesem Projekt mitgenommen habe

Dieses Projekt war für mich in mehrfacher Hinsicht prägend.

Ich habe erlebt, dass Model-Based Testing auch unter Zeitdruck funktioniert. Ich habe gelernt, dass sich mit einer neuen Methode nicht nur die Arbeit verändert, sondern auch die Art, wie wir Fortschritt messen müssen.

Und ich habe gesehen, dass aus einem erfolgreichen Versuch eine Veränderung entstehen kann, die weit über die eigene Arbeit hinausgeht.

Eine neue Methode einzuführen bedeutet nicht nur, Menschen ein Werkzeug zu zeigen. Man muss ihnen auch helfen, ihre bisherige Denkweise und Arbeitsweise zu verändern.

2021 – Shift Left. Und eine größere Pizza.

2021 haben wir gemeinsam mit einem Kunden und seiner TestFactory einen weiteren Schritt gemacht.

Die TestFactory arbeitete inzwischen modellbasiert. Ihre Tests begannen allerdings erst nach dem Sprint Review, wenn die Entwicklungsteams ihre Arbeit bereits abgeschlossen hatten. Dabei wurden regelmäßig Abweichungen gefunden.

Wir wollten verstehen, warum.

Bei der Erstellung ihrer Testmodelle hatte die TestFactory die User Stories intensiv hinterfragt, Fragen gestellt und ihre Modelle mit den Fachbereichen überprüft. Dadurch hatte sie häufig ein vollständigeres Verständnis der fachlichen Anforderungen entwickelt als die Entwicklungsteams.

Die Entwicklungsteams wollten von diesem Wissen profitieren. Also integrierten wir die Menschen aus der TestFactory in die Entwicklungsteams.

Statt Wissen zwischen getrennten Teams hin- und herzuschieben, brachten wir die Menschen zusammen.

Natürlich gab es Diskussionen. Zum Beispiel über die Teamgröße. Schließlich gibt es doch diese schöne Regel, dass ein Team von einer Pizza satt werden sollte.

Mal ehrlich:

Dann bestellt einfach eine größere Pizza.

Wenn Menschen gemeinsam Anforderungen verstehen, Fragen klären und Lösungen entwickeln, ist mir das wichtiger als die Frage, wie viele Personen sich eine Pizza teilen.

Und was hat es gebracht?

Eine ganze Menge.

Wir hatten weniger Fehler in den Abnahmetests. Wir konnten die Testautomatisierung gezielt dort ausbauen, wo sie sinnvoll war. Die Kommunikation innerhalb der Teams verbesserte sich spürbar.

Vor allem veränderte sich die Rolle der TestFactory. Sie war nicht mehr die Instanz, die nach dem Sprint Review kam und den Entwicklern die Nase auf ihre Fehler stieß.

Stattdessen wurden Probleme gemeinsam erkannt, besprochen und noch vor dem Review beseitigt. Aus einem zeitlich getrennten Nacheinander wurde ein gemeinsames Miteinander. Auch die Kundenzufriedenheit verbesserte sich.

Für mich zeigte dieses Projekt, dass Model-Based Testing viel früher einen Mehrwert schaffen kann, als wir häufig denken.

Qualität entsteht nicht dadurch, dass wir Fehler möglichst zuverlässig finden. Sondern vor allem dadurch, dass wir gemeinsam dafür sorgen, dass möglichst wenige entstehen.

2023 – Anne, Yest und die nächste Stufe

2023 traf ich auf dem German Testing Day Anne Kramer wieder.

Anne kam auf mich zu und meinte: „Ich muss dir mal was zeigen.“

Was sie mir zeigte, war Yest. Und ich war ziemlich schnell neugierig.

Mit Yest konnte ich Aktivitätendiagramme mit Entscheidungstabellen kombinieren. Bei Bedarf konnte ich sogar Testdaten direkt in mein Modell einbeziehen.

Das eröffnete neue Möglichkeiten für meine Testanalyse und mein Testdesign.

Weniger Werkzeugwechsel, weniger Handarbeit

Lange Zeit hatte ich mehrere Werkzeuge für meinen modellbasierten Ansatz benötigt.

In Enterprise Architect erstellte ich Aktivitätendiagramme. Mit der MBTsuite generierte ich daraus Testfälle. Dann gab es noch die Verbindung zu den Anforderungen.

Entweder musste ich User Stories manuell aus Jira nach Enterprise Architect übertragen oder die generierten Testfälle später im Testmanagement-Werkzeug mit den entsprechenden Anforderungen verknüpfen.

Das funktionierte, bedeutete allerdings zusätzliche Arbeit.

Mit Yest wurde vieles davon einfacher. Ich konnte User Stories direkt mit den passenden Modellen verknüpfen. Damit entstand eine nachvollziehbare Verbindung von der Anforderung über das Modell bis zum generierten Testfall.

Traceability, ohne dass ich die Verbindungen ständig von Hand herstellen musste. Auch die Integration in unsere Jira- und Xray-Umgebung wurde einfacher.

Und damit war ich wieder bei dem Thema, das mich schon 2013 beschäftigt hatte: weniger manuelle Arbeit und ein besserer Umgang mit Veränderungen.

Meine Modelle wurden für alle sichtbar

Fast noch wichtiger war für mich ein anderer Punkt. Meine Modelle waren jetzt direkt in Jira sichtbar.

Menschen im Projekt konnten sie anschauen und überprüfen, ohne selbst mit Yest arbeiten zu müssen.

Der Fachbereich und die Entwicklung konnten die Modelle dort sehen, wo sie ohnehin mit ihren User Stories arbeiteten. Das erleichterte Reviews und half dabei, die Modelle in die gemeinsame Projektarbeit einzubinden.

Ich möchte möglichst wenig Zeit damit verbringen, Informationen zwischen Werkzeugen zu übertragen, und möglichst viel Zeit damit, gemeinsam gute Software zu entwickeln.

2024 – Eine gute Methode verändert noch keine Gewohnheiten

2024 wollten wir in einem weiteren Kundenprojekt modellbasiert arbeiten.

Auch hier halfen uns die Modelle, Anforderungen verständlich zu machen, Änderungen aufzunehmen und passende Testfälle abzuleiten.

Eigentlich alles, was mich seit 2013 an dieser Methode begeistert. Und trotzdem hat es diesmal nicht so funktioniert, wie ich es mir gewünscht hätte.

Wir konnten den Veränderungsprozess im Projekt leider nicht aktiv begleiten. Und wir haben es nicht geschafft, dass die Beteiligten dauerhaft vom klassischen Schreiben einzelner Testfälle zu einem modellbasierten Testansatz wechselten.

Die Methode hatte ihre Vorteile gezeigt. Die neue Arbeitsweise hatte sich allerdings nicht etabliert.

Eine Methode einzuführen ist noch keine Veränderung

Für mich war das eine wichtige Erkenntnis.

Es reicht nicht, Menschen eine neue Methode zu erklären, ihnen ein Werkzeug zu zeigen und die Vorteile zu demonstrieren.

Eine Veränderung der Arbeitsweise muss begleitet werden. Und zwar nicht nur am Anfang.

Menschen haben Gewohnheiten. Wir haben über Jahre gelernt, bestimmte Aufgaben auf eine bestimmte Weise zu erledigen. Das gibt uns Sicherheit.

Wenn wir eine neue Methode einführen, müssen wir diese Gewohnheiten verändern. Das passiert nicht durch einen Workshop oder eine Schulung.

Neue Verhaltensweisen müssen ausprobiert, geübt und immer wieder angewendet werden. Es braucht Zeit, Unterstützung und manchmal jemanden, der daran erinnert, warum wir uns überhaupt verändern wollten.

Sonst ist der Weg zurück zu den alten Mustern erstaunlich kurz.

Irgendwie wie bei meinen Diätversuchen

Während ich das hier schreibe, muss ich an meine eigenen Versuche denken, mich gesünder zu ernähren.

In der Theorie weiß ich ziemlich genau, was ich tun müsste. Weniger von diesem, mehr von jenem. Regelmäßiger essen, bewusster entscheiden und nicht bei jeder Gelegenheit in alte Gewohnheiten zurückfallen.

Klingt eigentlich ganz einfach.

Blöd ist nur, dass zwischen dem Wissen und der täglichen Umsetzung ein ziemlich langer Weg liegt. Und ehe man sich versieht, ist der alte Schlendrian wieder da.

Bei der Einführung neuer Methoden in Projekten ist das gar nicht so anders.

Nur weil wir verstanden haben, dass eine neue Arbeitsweise sinnvoll ist, bedeutet das noch lange nicht, dass wir sie morgen ganz selbstverständlich anwenden.

Aus einer neuen Methode muss erst eine neue Gewohnheit werden.

Und dieser Weg braucht Begleitung.

Was ich daraus mitgenommen habe

2014 hatte ich erlebt, wie wir Model-Based Testing Schritt für Schritt in einer TestFactory etabliert haben. Wir hatten Good Practices und Modelling Guidelines entwickelt, Erfahrungen gesammelt und unsere Arbeitsweise kontinuierlich verbessert.

2024 wurde mir noch einmal deutlich, wie wichtig genau diese Begleitung gewesen war.

Ein Werkzeug kann die Arbeit erleichtern und eine Methode fachlich überzeugen.

Eine nachhaltige Veränderung entsteht allerdings erst, wenn Menschen die neue Arbeitsweise in ihren Alltag übernehmen.

Und das gilt nicht nur für Model-Based Testing.

Heute – Kann ich noch besser werden?

Model-Based Testing begleitet mich inzwischen seit 2013.

Wenn ich heute in einem Projekt eine Testanalyse durchführe, arbeite ich nach wie vor gerne modellbasiert. Für mich ist das längst keine experimentelle Methode mehr, sondern ein bewährter Bestandteil meiner Arbeit.

Aktuell bin ich in keinem Projekt, in dem ich selbst eine Testanalyse durchführe.

Das gibt mir Zeit, mich mit einer Frage zu beschäftigen, die mich gerade besonders interessiert:

Wie kann mich künstliche Intelligenz bei der Erstellung und Validierung meiner Testmodelle unterstützen?

Kann mir KI helfen, aus Anforderungen schneller ein erstes Modell zu entwickeln?

Kann sie mich auf fehlende Abläufe, übersehene Entscheidungen oder Widersprüche aufmerksam machen?

Kann sie meine Modelle hinterfragen und damit meine Testanalyse verbessern? Und wo liegen die Grenzen?

Ich möchte herausfinden, welche Aufgaben KI sinnvoll übernehmen kann und an welchen Stellen mein fachliches Verständnis und meine Erfahrung weiterhin entscheidend sind.

Denn bei aller Begeisterung für neue Möglichkeiten: Ein Modell wird nicht allein dadurch gut, dass es schnell erstellt wurde.

Es muss das erwartete Verhalten des Systems richtig beschreiben. Und es muss uns helfen, die richtigen Fragen zu stellen.

Vielleicht kann KI mich dabei unterstützen, noch besser zu werden. Genau das möchte ich herausfinden.

Meine Reise geht weiter

Wenn ich auf diese Jahre zurückblicke, denke ich nicht nur an Modelle und Testfälle. Ich denke an die Menschen, mit denen ich Neues ausprobieren, Erfolge feiern und aus Fehlern lernen durfte.

Manche haben meine Ideen hinterfragt, andere mir neue Perspektiven eröffnet. Viele haben gemeinsam mit mir Veränderungen möglich gemacht. Dafür bin ich dankbar.

Und ich bin gespannt, wohin mich diese Reise noch führt.

Und vielleicht geht es dir ja ähnlich. Vielleicht hast du selbst Erfahrungen mit Model-Based Testing gemacht, bist von der Methode begeistert oder siehst manches völlig anders.

Ich freue mich auf den Austausch.