Kürzlich habe ich in München an der diesjährigen „Trends in Testing“, einer Fachveranstaltung für Softwaretester teilgenommen, die seit 2009 jährlich von der imbus AG organisiert wird. Das Thema dieses Jahres war das modellbasierte Testen. Nachdem sich Konzepte wie agile und modellbasierte Softwareentwicklung immer mehr verbreiten, gewinnt auch das modellbasierte Testen immer mehr an Popularität. Auch wenn sich das Konzept gerade auf dem Gardner-Hype-Cycle in der Phase des Abstürzens ins „Tal der Enttäuschungen“ befindet, durch die fast jede Idee durch muss, die vom Hype-Thema zur einsatzreifen Lösung heranreift. Obwohl die Diskussion ums modellbasierte Testen („scriptless testing“) bereits seit etlichen Jahren geführt wird.
Referenten wie Thomas Roßner von imbus und Helmut Götz von Siemens stellten vor, was mit modellbasiertem Testen möglich ist und wie Unternehmen dabei vorgehen können. Testen kostet in erster Linie Zeit und Geld. Da beides in Projekten regelmäßig knapp ist, wird das Testen gerne zum Sparschwein für projektbezogene Unwägbarkeiten „umgenutzt“, was man an den mittlerweile im Wochentakt bekanntwerdenden Sicherheitslücken populärer Software-Produkte und Internetdiensten mitverfolgen kann.
Daher drehen sich zahlreiche methodische Innovationen im Testing-Bereich um das Thema Kostensparen bei gleichbleibender oder gar steigender Testabdeckung und Testqualität. Hierbei kann modellbasiertes Testen einen bedeutenden Fortschritt bewirken, da sich damit beträchtliche Einsparungen bei der Testspezifikation sowie z.T. auch bei der Testautomation erreichen lassen.
Modellbasiertes Testen bedeutet, dass der Kern der Arbeiten bzgl. Testplanung und Testspezifikation an einem grafischen Modell des zu testenden Systems stattfindet. Und das Testfälle, Testfallskripte für Testautomationstools sowie der größte Teil der Testdokumentation automatisch aus diesem zentralen Modell generiert wird. Dieses Modell bildet einen logischen Zwischenschritt zwischen Anforderungsmanagement und Testen der Software, da bereits aus Anforderungen Modellinhalte und Testfälle gebildet werden können. Es wird i.d.R. auf der Basis von UML-Diagrammen (Use-Case-, Activity- und Sequenz-Diagramme) sowie spezifischen Anpassungen der grafischen Elemente gebildet. Erfahrungen aus der bisherigen Praxis zeigen, dass so bereits in einer frühen Phase konzeptionelle Defizite des geplanten Softwaresystems aufgedeckt werden können, die mit „traditionellen“ Methoden erst sehr spät oder auch gar nicht bemerkt würden, wenn sie nicht zu fehlernhaften Tests führen.
So stellte Referent Götz mehrere Entwicklungsprojekte im industriellen Umfeld vor, in denen Siemens das selbst entwickelte Tool Tedeso für modellbasiere Tests eingesetzt und damit beträchtliche Einsparungen bei der Durchführung und Dokumentation von Tests erzielen konnte.
Auswirkungen von Anforderungsänderungen, geplanten Bugfixes und Implementierungsvarianten auf das Projekt lassen sich mit Hilfe des modellbasierten Testens leichter transparent machen, da entsprechende Tools auch „Was wäre wenn“-Szenarien durch Veränderungen am zu testenden Modell ermöglichen.
Grundsätzlich werden beim modellbasierten Testen deutlich mehr Testfälle generiert als bei herkömmlicher Testautomation. Allerdings lassen sich methodisch Filter setzen, um z.B. die Testabdeckung bestimmter Bereiche der zu testenden Software zu optimieren oder um die Ergebnisse bereits vorangegangener Tests mit zu berücksichtigen.
Den Abschluss der Veranstaltung bildete eine Podiumsdiskussion unter dem Motto „Where 2 go 2“, die Möglichkeiten zum raschen Anpacken des Themas im Unternehmen aufzeigen sollte.
Vortragsbegleitend konnte man sich an Testinstallationen der TestBench von imbus sowie der neu hinzugekommenen Komponente tedeso von Siemens ansehen, wie die Toolunterstützung von modellbasiertem Testen in der Praxis aussieht. So lassen sich z.B. Testfälle in der TestBench als „Prosatext“ oder als Objekte (Interaktionen und Datentypen) anlegen, parametrisieren oder auch gleich in Testskripte zur Ansteuerung eines Testautomationstools umwandeln. Das Arbeiten an einem Modell anstatt an einzelnen Interaktionen stellt daher für die TestBench-Nutzer i.W. nur einen neue Art des Zugangs zu ihren Tests da. Ähnlich dürfte es sich bei vergleichbaren Testmanagementumgebungen verhalten.
