Die Autoren stellen ein neues Verfahren zum modellbasierten Testen vor. Das Verfahren verbessert die Effektivität und Effizienz von GUI-Tests erheblich, insbesondere bei DevOps. Zuerst werden die Probleme der heutigen MBT-Ansätze analysiert. Anschließend wird das neue Verfahren vorgestellt, das diese Probleme löst. Dabei wird in der ersten Phase ein abstraktes, aber für Tester leicht verständliches Testmodell entworfen. Die zweite Phase dient der effizienten werkzeuggestützten Testimplementierung. Veranschaulicht wird das Verfahren mit einem Fallbeispiel aus der eigenen Praxis mit dem MBT-Tool Harmony und dem Automatisierungstool PlayWright.

Zielpublikum: Fachtester, Testanalysten, GUI-Tester, Testmanager, DevOps-Tester, MBT-Spezialisten
Voraussetzungen: Grundlagen des Testens
Schwierigkeitsgrad: Advanced

Extended Abstract:
Die geschätzten jährlichen Kosten von Softwareproblemen in den USA übersteigen eine Billion Dollar. Die Ausgaben für die Fehlerbehebung machen etwa 20 % der gesamten IT-Kosten aus und belaufen sich weltweit auf viele weitere Milliarden Dollar in nur einem Jahr. Ein Großteil dieser Verluste ist nicht auf die inhärente Schwierigkeit zurückzuführen, Softwarefehler zu finden, sondern darauf, dass der Testentwurf ineffektiv und ineffizient ist. Die Autoren sind der Meinung, dass ein erheblicher Teil dieser Kosten durch die Anwendung modernster Testentwurfsverfahren und Automatisierung gemindert werden kann. Eine effiziente Testautomatisierung umfasst sowohl den Testentwurf als auch die Testimplementierung und -Durchführung. Automatisierter Testentwurf wird dabei durch modellbasierte Testwerkzeuge (MBT) umgesetzt. Die heute gängigen MBT-Werkzeuge haben allerdings mehrere Probleme. Sie erfordern einerseits sehr umfassende Modellierungskenntnisse, die über ein Analysemodell weit hinausgehen. Herkömmliche Modelle sollten "computerlesbar" sein, d.h., das Modell sollte von einem Computerprogramm analysiert und verarbeitet werden können. Wenn das erfolgt ist, werden die ausführbaren Tests generiert. Daher muss das Modell alle Details der Anwendung einschließlich Design und Implementierung enthalten, sodass eine Automatisierung von vornherein fast unmöglich ist. Ein weiteres Problem stellt das erwartete Ergebnis dar. Auch die Ausgaben des Testobjekts sollten im Modell enthalten sein, sodass der Tester sie bei der Modellierung berechnen muss. In diesem Vortrag stellen die Autoren ein neues MBT-Verfahren, das Zwei-Phasen-MBT vor, das diese Probleme löst. Sie zeigen an einem Fallbeispiel aus der Praxis die Vorteile des Verfahrens. Beim Zwei-Phasen-MBT wird zuerst ein abstraktes und dann ein konkretes Testmodell erstellt. Das abstrakte Modell, das die Autoren im Fallbeispiel genutzt haben, besteht aus einem speziellen Flussgraphen, dessen Knoten Testschritte sind. Jeder Testschritt enthält eine (Benutzer-)Aktion, eine oder mehrere (System-)Antworten — optional — und einen Testzustand — optional. Dieses Testmodell ist für manuelle Tester leicht erlernbar und deckt sowohl das Verhalten des Testobjekts in den Interaktionen, wie z.B. das bei Anwendungsfallspezifikationen oder verhaltensgetriebener Entwicklung (behavior-driven development, BDD) der Fall ist, als auch das zustandsabhängige Verhalten. Testfälle werden aus dem Graphen generiert. Ein Testfall ist ein Pfad vom Anfangsknoten zu einem Blattknoten. Das abstrakte Modell ist "menschenlesbar", aber noch nicht „computerlesbar“, d.h., aktuelle Anwendungen sind nicht in der Lage, es zu verarbeiten, um Testcode zu erzeugen. Stattdessen werden aus dem abstrakten Modell abstrakte Testfälle generiert. Diese Testfälle können von den Testern ausgeführt werden, aber auch hier kann kein ausführbarer Testcode erzeugt werden. Abstrakte Testfälle können die Anforderungen vor der Implementierung validieren. Auf diese Weise können verschiedene Fehler, nicht erwarteter Code usw. eliminiert werden, was den SDLC kostengünstig und den Code qualitativ hochwertig macht. In der zweiten Phase erfolgt die Generierung eines konkreten Modells und des ausführbaren Testcodes. Dies kann durch die manuelle Ausführung der abstrakten Testfälle am implementierten Testobjekt erfolgen. Während der Ausführung wird ein konkretes Modell generiert. Der ausführbare Testcode wird vom MBT-Werkzeug sofort generiert und ausgeführt. Wenn die manuellen Testschritte ausgeführt werden, wird diese Ausführung mit einem geeigneten Werkzeug automatisiert, sofort ausgeführt und man ist fertig. Hierbei hat sich das Testautomatisierungswerkzeig PlayWright in unserer Fallstudie ausgezeichnet bewährt. Das generierte konkrete Modell ist computerlesbar, womit wir bei der traditionellen Lösung angekommen sind. Auf diese Weise kann das Zwei-Phasen-MBT als eine Weiterentwicklung des traditionellen Modells betrachtet werden. Anhand des Fallbeispiels werden die Teilnehmer die Vorteile des Zwei-Phasen-MBT gegenüber herkömmlichem MBT verstehen:

• kompakter
• verständlicher
• viel schneller
• führt zu qualitativ hochwertigem Code
• erfordert keine Berechnung der erwarteten Ergebnisse, es reicht, sie zu validieren
• Abstrakte Tesetfälle können vor der Testimplementierung generiert werden
• In-Sprint-Testautomatisierung ist möglich