Modellbasiertes Testen beschreibt einen Ansatz, bei dem Prozesse grafisch in einem Testmodell abgebildet werden, um Anforderungen gemeinsam mit Fachbereich und Testern zu erarbeiten und daraus automatisch Testfälle zu generieren. Das Modell ersetzt Fließtext durch eine visuelle Sprache, macht Lücken in Anforderungen sofort sichtbar und dient gleichzeitig als Grundlage für Impact-Analysen bei Änderungen.
Das Wichtigste in Kürze
- Modellbasiertes Testen schafft eine gemeinsame visuelle Sprache zwischen Fachbereich, Testern und Entwicklern, die Diskussionen von technischen Detaildebatten auf relevante Fragen lenkt.
- Aus rund einem halben Jahr Arbeit entstanden bei der Lufthansa CityLine etwa 700 Testfälle, die in 60 Modellen strukturiert abgelegt sind und per Knopfdruck generiert wurden.
- Das Modell macht Lücken in Anforderungen sofort sichtbar: Ein Kick-off-Workshop lieferte gleichzeitig verbesserte Anforderungen und die passenden Testfälle.
- Änderungen im Betrieb, etwa neue Tarifabschlüsse, lassen sich über das Modell gezielt als Impact-Analyse durchführen, ohne hunderte Testfälle einzeln zu sichten.
- Wer Modelle zu komplex gestaltet, riskiert eine Testfall-Explosion; kleine, verständliche Modelle mit engem Scope funktionieren nachweislich besser als der Versuch, alles in einem abzubilden.
Modellbasiertes Testen bringt die Stakeholder an einen Tisch
Modellbasiertes Testen löst ein Grundproblem in großen Softwareprojekten: Das Wissen, das man für gute Tests braucht, liegt verteilt bei drei Parteien. Fachexperten kennen die Prozesse. Tester wissen, wie gute Testfälle entstehen. Entwickler bauen auf Basis der Informationen die Software. Diese drei zusammenzubringen, ist die eigentliche Arbeit, und ein Modell schafft dafür eine gemeinsame Basis.
Ein Modell funktioniert wie eine Sprache. Es ist eine Art, etwas auszudrücken, auf die sich alle Beteiligten einigen können. Weil es grafisch aufbereitet ist, bleibt es simpel und verständlich. Marvin Jakob beschreibt den Kerneffekt so: Man kann mit dem Finger auf eine Stelle zeigen und sagen, hier müssen wir noch mal reden. Genau diese Sichtbarkeit fehlt in reinem Fließtext.
Bei der Lufthansa CityLine wurde der Ansatz in einem Crew-Management-System eingesetzt, das im Zuge einer neu gegründeten Airline aufgebaut wurde. Die Herausforderung bei einem extern beauftragten System ist immer dieselbe: Liefert der Lieferant genau das, was bestellt wurde? Um das abnehmen zu können, braucht man Fachwissen und Kommunikation zwischen Fachbereich und Test.
Wie entsteht ein Testmodell aus verteiltem Wissen?
Ein Testmodell entsteht durch Interviewtechnik, nicht aus fertig vorliegenden Diagrammen. Solche Modelle liegen in einem Projekt nicht herum, sie werden im Frage-Antwort-Spiel erarbeitet.
Der Einstieg ist eine einzelne Anforderung und die Frage, wie man sie testen würde. Was ist der erste Schritt, was der zweite? Diese Schritte landen als Aktivitäten im Modell. Von dort führt das Modell fast von selbst zur nächsten Frage: Was passiert dann? Passiert hier noch etwas anderes? Brauchen wir an dieser Stelle eine Verzweigung?
Das Vorgehen ist anfassbar und beweglich. Aktivitäten lassen sich verschieben, Lücken einfügen, vergessene Schritte nachtragen. Irgendwann steht das Modell vor einem Endpunkt, der noch nicht erreicht ist, und genau dort wird klar, welche Aktivität noch fehlt. Am Ende eines Workshops steht ein greifbares Ergebnis, was in der Softwareentwicklung nicht selbstverständlich ist.
Fang auf hoher Flughöhe an, nicht im Detail
Die wichtigste Praxisregel beim modellbasierten Testen lautet: Beginne auf einer sehr hohen Flughöhe und komme erst dort von Anfang bis Ende durch, bevor du über Details sprichst.
Wer sich gleich zu Beginn in Unterdiagramme und Low-Level-Verzweigungen verzettelt, verliert den Überblick. Besser ist der umgekehrte Weg: ein High-Level-Modell bauen, darüber sprechen, und erst wenn alle es verstanden haben, eine Ebene tiefer gehen und mehr Testinformationen einbringen. Schritt für Schritt, bis sich auf Knopfdruck fertige Testfälle generieren lassen.
Dieses Vorgehen hat einen handfesten Vorteil bei der Diskussion. Die Gespräche bewegen sich weg von technischen Details und Klein-Klein hin zu den relevanten Fragen. Wenn man auf einer hohen Ebene bleibt, bleibt man im Lösungsmodus, statt sich in der gefühlten Nichtmachbarkeit zu verlieren.
Die Sortierung, was getestet wird und was nicht, verschiebt sich nach hinten. Man bringt zuerst die Fachlichkeit ins Modell und entscheidet später über die Abdeckung: Edge Coverage, Full-Path-Coverage, Testdatenvarianten, Äquivalenzklassen. Diese Entscheidung lässt sich entspannt treffen, ohne dass das Modell darunter leidet.
Gute Tests setzen gute Anforderungen voraus
Man kann nur gute Tests schreiben, wenn die Anforderungen gut sind. Anforderungen und Tests bilden eine Einheit, weil sie zusammen das Feature beschreiben.
Das Modell macht Lücken in den Anforderungen offensichtlich. Sehr konkret lässt sich besprechen, an welcher Stelle nachgebessert werden muss. Bei der CityLine ging das Team aus dem Kick-off-Workshop mit verbesserten Anforderungen und den passenden Tests dazu heraus, beides in einem Schritt.
Der Workshop lief in einem klaren Ablauf: Vormittags wurde ein Refinement der mitgebrachten User Stories gemacht, um sie zu verstehen, mit ersten Verbesserungen. Danach setzte sich jemand an das Tool, der es vorher noch nie benutzt hatte, und baute das erste Testmodell. Am Nachmittag gegen drei fuhren die Teilnehmer mit verfeinerten Stories und den dazu generierten Testfällen nach Hause.
Halte Modelle einfach, sonst tragen sie nicht
Ein gutes Modell ist einfach und verständlich, kein Versuch, die ganze Welt mit Unterdiagrammen abzubilden. Beliebig komplexe Modelle funktionieren in den seltensten Fällen.
Ein praktischer Test für die Verständlichkeit: Hol jemanden Drittes dazu, der das Modell vorher nicht gesehen hat, und lass ihn erklären, was dort steht. Wenn das gelingt, ist das Modell in der Sprache des Modells einfach genug formuliert. Luftfahrtprozesse sind komplex, trotzdem ließ sich das für zahlreiche Fälle so umsetzen.
Genauso wichtig ist ein klarer Testscope. Es gibt nicht das eine Modell, das alle Geschäftsprozesse abbildet. Wer alles in ein Modell packt, produziert eine Testfall-Explosion, und im schlimmsten Fall steht der Rechner beim Generieren still. Fokus auf einen Scope schützt davor.
Vom Modell zum Testfall auf Knopfdruck
Steht das Modell, lassen sich die Testfälle per Generieren-Knopf erzeugen. Die Fleißarbeit, Tests so aufzubereiten, dass sie ausführbar sind, übernimmt das Tool, und damit ist ein Teil automatisiert.
Bei der CityLine entstanden auf diesem Weg rund 700 Testcases, die sich in etwa 60 Modellen verteilen. Die Modelle ließen sich in das bereits genutzte Jira übertragen, dort ansehen, mit Anmerkungen versehen und reviewen. Die bestehende Infrastruktur wurde genutzt, statt neue aufzubauen.
In Jira wird das Modell auch farblich sichtbar: Was wurde getestet, was funktioniert, was nicht. Das schafft eine Kommunikationsgrundlage mit den Stakeholdern und baut Vertrauen auf, weil die Arbeit transparent und jederzeit erklärbar bleibt.
Ich kann sehr schön darüber mit meinen Stakeholdern kommunizieren, Vertrauen aufbauen und total transparent arbeiten. Das ist das, was für mich im Test wichtig ist.
Oliver Schuhmacher
So bleibt die Testbasis bei Änderungen aktuell
Das Modell vereinfacht die Impact-Analyse, wenn sich Anforderungen ändern. Statt seitenweise Jira-Listen durchzugehen, schaust du ins Modell und siehst die betroffenen Testfälle dahinter.
Im Luftfahrtumfeld kommen regelmäßig neue Tarifabschlüsse und Regeln hinzu, die berücksichtigt werden müssen. Bei 700 Testfällen ist es schmerzhaft, jeden einzeln auf Gültigkeit zu prüfen. Sind die Modelle strukturiert abgelegt, erkennt man schnell, welche Bereiche betroffen sind und wo die Änderung eingepflegt werden muss.
Aus dem angepassten Modell lassen sich die Testfälle direkt überschreiben oder versioniert hochzählen. Damit bleiben sie auf dem neuesten Stand. Arbeit steckt weiterhin darin, aber der Aufwand fließt in die relevanten Fragen: Was hat sich geändert, wie teste ich das am besten?
Das Modell soll weiterleben, nicht im Projekt enden
Ein Testmodell gehört in die Analysephase, gleichwertig zu den Anforderungen. Es steht am Anfang, wenn das Team versteht, was es bauen will und wohin es will.
Damit der Nutzen vollständig gehoben wird, sollte das Modell über das Projektende hinaus bestehen. Bei der CityLine sollen die Modelle in der Transitionphase als eine Art Dokumentation an die Linienorganisation übergeben werden. Wer das Modell am Projektende wegwirft, hebt nur den halben Benefit.
Die Voraussetzung dafür ist ein Team aus Testern, Fachbereich und Entwicklern, das über den gesamten Zeitraum bis in den Betrieb zusammenarbeitet. In großen Projekten ist es fast unmöglich, alle Anforderungen von Anfang an vorliegen zu haben. Das Modell ist die Grundlage, auf der dieses Team kontinuierlich Informationen austauscht und dokumentiert.
Einfach loslegen und ausprobieren
Der wichtigste Rat für den Einstieg ist, es auszuprobieren. Bei einem neuen Tool gibt es eine Lernkurve, und am Anfang macht man zwangsläufig Fehler.
Trotzdem spart der Ansatz am Ende Zeit. Weil viel Aufwand in die Analyse fließt und dort die richtigen Dinge diskutiert werden, ist man danach schon weitgehend fertig. Falsch machen kann man dabei wenig, selbst wenn man sich Stück für Stück herantastet.
Wer unsicher ist, muss nicht allein starten. Die Testing-Community ist eine gute Anlaufstelle für Hilfe, Coaching oder einen zweiten Blick aufs Modell. Im Kern liegt der Wert dort, wo verteiltes Wissen zusammenkommt, Anforderungen schärfer werden und aus dem Modell direkt die Tests entstehen, die für den Business Value zählen.
Häufig gestellte Fragen
Wann lohnt sich modellbasiertes Testen überhaupt?
Der Ansatz zahlt sich dort aus, wo das nötige Testwissen auf drei Parteien verteilt liegt: Fachexperten kennen die Prozesse, Tester wissen, wie gute Testfälle entstehen, Entwickler bauen die Software. Besonders hilfreich ist er bei extern beauftragten Systemen, weil die Abnahmefrage lautet, ob der Lieferant genau das geliefert hat, was bestellt wurde. Das Modell liefert die gemeinsame Grundlage dafür.
Braucht man fertige Prozessdiagramme, bevor man mit einem Testmodell starten kann?
Nein. Solche Modelle liegen in Projekten nicht herum, sie entstehen im Frage-Antwort-Spiel. Der Einstieg ist eine einzelne Anforderung und die Frage, wie man sie testen würde: erster Schritt, zweiter Schritt, jeder davon wird zur Aktivität im Modell. Von dort führen die nächsten Fragen weiter: Was passiert dann, brauchen wir hier eine Verzweigung?
Was ist der häufigste Fehler beim Aufbau von Testmodellen?
Modelle zu komplex zu bauen. Wer die ganze Welt mit Unterdiagrammen abbilden oder alle Geschäftsprozesse in ein Modell packen will, produziert eine Testfall-Explosion, im schlimmsten Fall steht der Rechner beim Generieren still. Ein enger Testscope und kleine, verständliche Modelle funktionieren besser. Ein praktischer Test: Jemand Drittes soll erklären können, was im Modell steht.
Muss die Testabdeckung feststehen, bevor man modelliert?
Nein, diese Entscheidung verschiebt sich bewusst nach hinten. Zuerst kommt die Fachlichkeit ins Modell, erst danach wird über Abdeckung gesprochen: Edge Coverage, Full-Path-Coverage, Testdatenvarianten, Äquivalenzklassen. Das lässt sich entspannt entscheiden, ohne dass das Modell darunter leidet. Sinnvoll ist außerdem, auf hoher Flughöhe von Anfang bis Ende durchzukommen, bevor Details verhandelt werden.
Hilft modellbasiertes Testen auch, wenn die Anforderungen noch lückenhaft sind?
Ja, das ist einer der Haupteffekte. Das Modell macht Lücken sofort sichtbar, weil man mit dem Finger auf eine Stelle zeigen und sagen kann, hier müssen wir noch mal reden. Bei der Lufthansa CityLine verließ das Team einen Kick-off-Workshop mit verbesserten Anforderungen und den passenden Testfällen: vormittags Refinement der User Stories, nachmittags fertige Ergebnisse.
Wie viele Testfälle lassen sich mit diesem Vorgehen realistisch erzeugen?
Bei der Lufthansa CityLine entstanden aus rund einem halben Jahr Arbeit etwa 700 Testfälle, verteilt auf rund 60 Modelle. Erzeugt wurden sie per Knopfdruck aus den Modellen. Die Fleißarbeit, Tests so aufzubereiten, dass sie ausführbar sind, übernimmt dabei das Werkzeug. Der Aufwand verlagert sich in die Analyse und die Modellierung.
Wie hält man hunderte Testfälle bei Anforderungsänderungen aktuell?
Über eine Impact-Analyse am Modell statt über seitenweise Ticketlisten. Sind die Modelle strukturiert abgelegt, erkennt man schnell, welche Bereiche eine Änderung betrifft und wo sie eingepflegt werden muss. Im Luftfahrtumfeld kommen etwa regelmäßig neue Tarifabschlüsse hinzu. Aus dem angepassten Modell lassen sich die Testfälle direkt überschreiben oder versioniert hochzählen.
Wann im Projektverlauf gehört ein Testmodell hin, und was passiert damit am Projektende?
Das Testmodell gehört in die Analysephase, gleichwertig zu den Anforderungen, also an den Anfang, wenn das Team klärt, was es bauen will. Wer es am Projektende wegwirft, hebt nur den halben Nutzen. Bei der CityLine sollen die Modelle in der Transitionphase als eine Art Dokumentation an die Linienorganisation übergehen und dort weiterleben.
