Warum ich modellbasiertes Testen so cool finde

appartment mockup on top of architect's blueprintsKennen Sie so etwas auch? Sie haben Komponenten für ein komplexes System zu testen, Fehler nach Freigabe müssen unbedingt vermieden werden, es gibt schier unüberschaubar viele Testfälle und dann erbringt ein Review viele Lücken und Ungenauigkeiten in der Testspezifikation und den Testfällen.

Die Korrekturversuche schlagen fehl, man hat eine Lösungsidee, die erstmal nicht umsetzbar scheint, und erst viel später findet man eine wirklich gute und umsetzbare Lösung.

Notfall beim manuellen Testdesign

Vor einigen Jahren arbeitete ich für eine Firma, in der genau diese Situation bestand. Meine Aufgabe war die Qualitätssicherung der Anforderungs- und Testspezifikationen. Für die Komponente mit der höchsten Komplexität existierten anfangs 1500 Testfälle.

Zu jeder funktionalen Anforderung waren ein oder mehrere Test-Anforderungen definiert worden und zu jeder Test-Anforderungen ein oder meist mehrere Testfälle. Daraus resultierte eine hohe Redundanz zwischen den Testfällen. Vielfach wurde der gleiche Testablauf in verschiedenen Testfällen zum Test unterschiedlicher Anforderungen wiederholt.

Andererseits gab es die schon erwähnten Schwächen bei Vollständigkeit und Korrektheit und das war ein echtes Problem.

Rettungsversuche

Um das zu überwinden wurden mit viel Anstrengung und hohem Aufwand Testspezifikation und Testfälle überarbeitet. Die Anzahl der Testfälle stieg auf 1900. Ein erneutes Review zeigte jedoch, dass keine grundsätzliche Verbesserung erreicht worden war.

Eine grobe Schätzung ergab, dass man mit dieser Vorgehensweise, bei korrekter Berücksichtigung aller zu testenden Anforderungen, 2500 bis 3500 Testfälle erhalten würde.

Unzufriedenheit und Überforderung

Die Situation war für alle Beteiligten belastend. Die Autoren der Anforderungs-Spezifikationen waren unzufrieden oder verärgert, weil sie das Gefühl hatten, dass ihre Spezifikation nicht ausreichend berücksichtigt worden war. Die Vorwürfe, die sie gegen die Testabteilung äußerten, lagen zwischen ungenauer und hemdsärmeliger Arbeitsweise und Unfähigkeit.

Die Testspezialisten wussten nicht, wie sie im vorgegebenen Termin- und Kosten-Rahmen zu einer Testspezifikation und Testfällen kommen sollten, die die Menge und Komplexität der Anforderungen korrekt berücksichtigen. Zur Reduktion der Redundanzen waren sie nicht in der Lage. Zu unüberschaubar war die Menge der Testfälle, zu groß erschien ihnen das Risiko, bei einer Optimierung anscheinend redundante aber in Wahrheit doch notwendige Testfälle zu streichen oder gar bei späteren Änderungen der Anforderungsspezifikation nicht mehr korrekt ermitteln zu können, welche Testfälle anzupassen sind.

Die Testexperten fühlten sich vollkommen überfordert. Wegen der lauter werdenden Kritik hatten sie das Gefühl, verurteilt und nicht wertgeschätzt zu werden, obwohl sie doch lange und hart gearbeitet hatten.

Lösungssuche

Ich versuchte Verbesserungs- und Lösungsmöglichkeiten für diese Situation zu finden. Mir war klar, will man auf manuelle Weise sicherstellen, dass wirklich alle prüfrelevanten Aspekte der Anforderungen berücksichtigt werden, muss man geeignete Vorgehensweisen erarbeiten und diese dann strikt befolgen. Das hätte jedoch erneut einen sehr großen Aufwand erfordert und eine Reduktion der Redundanzen in den Tests wäre weiterhin enorm schwierig gewesen.

Ich dachte, es wäre doch echt cool, wenn man ein Tool hätte, dem man die Funktionsspezifikationen in formaler Form als Input zur Verfügung stellt und das dann die notwendigen Testfälle generiert, wirklich alle zu prüfenden Aspekte der Anforderungen berücksichtigt und unnötige Redundanzen vermeidet.

Der größte Teil der funktionalen Anforderungen an die Komponente war als Folgen von Bearbeitungsschritten, so genannten „Technical Use Cases“, formuliert. Mit einer Modellierungssprache, die ganz ähnlich wie eine imperative objektorientierte Programmiersprache (beispielsweise Java) aufgebaut ist, könnte man leicht die „Technical Use Cases“ in eine formale Darstellung „übersetzen“, überlegte ich.

Leider gelang es mir damals nicht, ein geeignetes Tool zu finden, das den Eindruck vermittelte, dass es das Experimental- und Forschungs-Stadium bereits verlassen und die für den vorgesehenen Einsatz nötige Reife erreicht hatte.

Eine Lösung – modellbasiertes Testen

Heute kenne ich ein geeignetes Tool. Die verwendete Modellierungs-Sprache ist ganz ähnlich, wie ich sie mir damals vorstellte. Zusätzlich besteht die Möglichkeit, die Funktionalität des zu testenden Systems mittels UML Zustandsdiagrammen zu beschreiben. Man erstellt ein Modell der zu testenden Funktionalität. Auf Basis dieses Modells werden die Testfälle automatisch generiert. Der Grad der Abdeckung des Modells durch die Tests wird dabei auf valider Basis ermittelt. Auch ein Überblick, welche Funktionen durch die Tests wirklich getestet werden, ist leicht zu bekommen.

Echt super – mit dieser Technologie, die man modellbasiertes Testen nennt, gehört eine Problematik, wie die oben beschriebene, nun der Vergangenheit an. Die Testeffizienz ist damit auch viel besser, die Arbeit macht mehr Spaß und diese langweiligen Reviews von schier endlosen Testspezifikationen und Testfällen sind nun überflüssig.

Was war/ist ihre Lösung?

Befanden Sie sich auch schon in Situationen, wie der beschriebenen? Was war/ist Ihre Antwort auf die Probleme?

Nie wieder einen Blogartikel verpassen >>> Zum Blog-Newsletter anmelden

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

zwanzig − 11 =