Modellbasiertes Testen beschreibt einen Ansatz, bei dem Prozesse grafisch als Modell 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 liegen nicht alle Anforderungen von Anfang an vor, das ist fast unmöglich. 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.
