Es gibt grundsätzlich gegensätzliche Meinungen zur Automatisierung des Testens.
Der Glaubenskrieg
Einerseits lautet das bekannte Mantra von DevOps „automatisiere alles, was du mehr als zweimal ausführst“, und insbesondere die Befürworter aus dem Bereich der Continuous Delivery setzen als qualitätssichernde Maßnahme auf automatisierte Tests, die vor jedem Deployment durchgeführt werden.
Andererseits setzen Kritiker entgegen, dass jede Art von Automatisierung bis auf gewollt heuristische Verfahren typischerweise eine Art Standardisierung voraussetzt, die einen kreativen Prozess unmöglich macht. Entsprechend hieße das, dass jeder Test kreativ und unbedingt manuell durchzuführen sei.
Hier sollten wir also genauer hinsehen. Was genau wollen wir überhaupt automatisieren? Welche Aktivitäten sollen unter solch kontrollierten Bedingungen wiederholt werden, damit ihre Automatisierung nicht nur sinnvoll ist, sondern sich auch lohnt? Wo sind die Grenzen der sinnvollen Automatisierung? Dabei wollen wir uns auf die Kernaktivitäten des dynamischen Testens fokussieren. Verwandte Aktivitäten wie Planung und Steuerung des Testens, Einrichtung und Verwaltung der Testumgebung oder Fehlermanagement klammern wir bewusst aus, da sie weniger umstritten sind. Der Einfluss dieser Aktivitäten auf die Entscheidung für oder gegen Testautomatisierung und vice versa ist offenkundig, soll jedoch nicht Gegenstand dieses Artikels sein. Für vollständige Testprozessmodelle sei auf [ISO29119-2] oder [ISTQB-CTFL] verwiesen.
Hauptaktivitäten des dynamischen Testens
Bevor wir uns intensiver damit beschäftigen, was Testautomatisierung bedeutet, wollen wir noch mal die Hauptaktivitäten des dynamischen Testens und ihre Arbeitsergebnisse sowie deren Beziehungen genauer anschauen [Ham19].
Abbildung 1 zeigt die Beziehung verschiedener Artefakte in den vier Aktivitäten des Testprozesses nach [ISTQB-CTFL]: Testanalyse, Testentwurf, Testrealisierung und Testdurchführung. Im Folgenden betrachten wir die Automatisierung in den drei letztgenannten Aktivitäten.
Abb. 1: Testdurchführung und Verfolgbarkeit
Die grundlegende Frage ist: Wie weit können wir die Erstellung dieser Arbeitsergebnisse automatisieren und was ändert sich dabei?
Automatische Testdurchführung
Die Automatisierung der Testdurchführung ist laut ISTQB-Glossar „Die Verwendung einer Software, z. B. eines Capture/Replay-Werkzeugs, um die Ausführung von Tests zu steuern, tatsächliche mit erwarteten Ergebnissen zu vergleichen, die definierten Vorbedingungen herzustellen sowie weitere Testüberwachungs- und Berichtsfunktionen durchzuführen.“ [ISTQB-Glossar] Bereits hier ist ersichtlich, dass mehr dazu gehört als die reine automatische Steuerung der Testskripte in einem Testlauf.
Architekturen der Testautomatisierung stellen dafür eine Testausführungsschicht bereit (siehe Abbildung 2). Diese Schicht unterstützt die Steuerung der Ausführung der in den Testsuiten enthaltenen Testskripte, inklusive der Behandlung von Abweichungen, die Protokollierung der Ausführung und die Generierung von Testberichten. Weitere Details liefert die generische Testautomatisierungsarchitektur im [ISTQB-TAE].
Abb. 2: Komponenten einer Testausführungsschicht
Darüber hinaus enthält eine Testautomatisierungsarchitektur eine Testadaptierungsschicht, die den notwendigen Code zur Anpassung automatisierter Testskripte auf einer abstrakten Stufe für verschiedene Komponenten, Konfigurationen oder Schnittstellen des Systems unter Test zur Verfügung stellt [ISTQB-Glossar]. Abbildung 3 zeigt eine generische Liste von Komponenten einer solchen Schicht (vgl. [ISTQB-TAE]).
Abb. 3: Komponenten einer Testadaptierungsschicht
Die Automatisierung der Testdurchführung ist oftmals der erste und intuitive Ansatz zur Automatisierung von wiederholten Aktivitäten im Test. Der Aufbau der Architektur und die Wartung sind jedoch aufwendig. Für die gängigen Umgebungen stehen deshalb heute viele standardisierte Mittel einschließlich Open-Source-Frameworks zur Verfügung. Diese machen die Automatisierung der Testdurchführung unter günstigen Umständen effizienter als die manuelle Durchführung. Auf der anderen Seite wissen wir, dass die wiederholte Durchführung ein und derselben Testsuite einen relativ beschränkten Nutzen hat. Um hier weiter zu kommen, müssen wir die Testsuiten in allen Aspekten flexibler machen. Dies betrifft auch die jeweils enthaltenen Testfälle mit ihren Aktionen, Eingaben und erwarteten Ergebnissen. Dies führt uns zum Bedarf nach einer Automatisierung der Testrealisierung (z. B. der Testdaten) und des Testentwurfs.
Automatische Testrealisierung
Die Testrealisierung bereitet auf Basis der Testanalyse und des Testentwurfs die Testmittel vor, welche für die Testdurchführung benötigt werden [ISTQB-Glossar]. Ausgangspunkt sind die Testbedingungen und Testfälle. Um diese Aktivität zu automatisieren, sollten Testdaten aus Datenmodellen einerseits und den Angaben der Testfälle (Eingaben und erwartete Ergebnisse) andererseits generiert werden. Testskripte können aus einem Modell von Testfällen generiert werden.
Dementsprechend braucht eine generische Testautomatisierungsarchitektur [ISTQB-TAE] auch eine Testdefinitionsschicht (siehe Abbildung 4), die die Testrealisierung durch Definition von Testfällen und/oder Testskripten unterstützt, zum Beispiel durch Anbieten von Vorlagen beziehungsweise Richtlinien [ISTQB-Glossar].
Abb. 4: Komponenten einer Testdefinitionsschicht
Die Testrealisierung ist folglich sehr gut für eine Automatisierung geeignet. Aus den Vorbedingungen, Eingaben und erwarteten Ergebnissen von Testfällen, unter Zuhilfenahme eines Objektmodells, lassen sich zum Beispiel die nötigen Testdaten generieren oder verlinken, oder auch Setup-Prozeduren für die Testskripte generieren. Ähnlich lassen sich Konfigurationsparameter der Testumgebung in der Adaptationsschicht generieren.
Wiederum muss man die Kosten für die Entwicklung und Wartung der Testdefinitionsschicht gegen den Nutzen abwägen. In manchen Situationen – zum Beispiel bei Anwendungen, die auf zahlreichen Plattformen laufen – lohnt sich die Automatisierung sehr. In anderen Situationen ist es sinnvoller, auch die Basis der Testrealisierung flexibel und automatisch zu erzeugen: die Testbedingungen und die Testfälle.
Automatischer Testentwurf
Beim Automatisieren des Testentwurfs spricht man oft von modellbasiertem Testen (MBT). ISTQB widmet den Grundlagen des MBT einen eigenen Lehrplan [ISTQB-MBT]. Im Grunde ist aber modellbasiertes Testen ein sehr allgemeiner Begriff, definiert als Testen, das auf Modellen basiert oder diese involviert [ISTQB-Glossar]. Streben wir eine umfassende Automatisierung des Testens an, dann müssen wir im Grunde alle Informationen in Modellen pflegen, aus denen alle anderen Arbeitsergebnisse des dynamischen Testens generiert werden können. Das ergibt eine gleichfalls komplexe und mächtige Grundlage.
Die für den Testentwurf passende Schicht einer generischen Testautomatisierungsarchitektur ist die Testgenerierungsschicht, die den manuellen oder automatisierten Entwurf von Testsuiten und/oder Testfällen unterstützt [ISTQB-Glossar].
Wollen wir zum Beispiel Black-Box-Tests generieren, so brauchen wir ein Verhaltensmodell des Testobjekts als Basis. Auch die Testbedingungen (wie z. B. 2-Switch-Zustandsübergänge, oder paarweise Kombinationen von Parameter-Werte-Paaren) müssen dem Modell angefügt werden. Um konsistente abstrakte Testfälle generieren zu können, kann auch ein Modell der Testdaten oder der Struktur des Testobjekts hilfreich sein (normalerweise ein UML-Klassendiagram). Für konkrete Testfälle kommen weitere mögliche UML-Objektmodelle hinzu. Damit ergibt sich unser Entwurf einer Testgenerierungsschicht, wie in Abbildung 5 beschrieben.
Abb. 5: Komponenten einer Testgenerierungsschicht
Grenzen der Testautomatisierung
Modellbasiertes Testen ist nicht neu und birgt viel Potenzial [Win09, FTM13]. Es ist eine Schlüsseltechnologie, wenn man systematisches Testen in Continuous Delivery anwenden will.
Der Aufbau einer umfassenden Automatisierung von Testentwurf, -realisierung und -durchführung erfordert jedoch hohe Investitionen. Möchte man so umfassend wie möglich automatisieren, müssen das Modell zusammen mit der Architektur alle Informationen für den Testentwurf, -realisierung und -durchführung enthalten oder Referenzen auf deren Definition konsistent einbinden. Das bringt andererseits deutliche Einsparungen bei häufiger Anpassung der Testbasis. Ein weiterer Vorteil ist, dass die Test-Modellierung ein sehr früher und effektiver statischer Test der Testbasis ist.
Testautomatisierung braucht den Aufbau einer Architektur mit Adapter-Schichten, die zur konkreten Projektsituation passt. Wenn das Projekt sehr nahe beim üblichen Standard ist, wird es leichter sein, die Architektur aus fertigen Komponenten und mit erfahrenen Automatisierern aufzubauen. Je individueller das Umfeld, desto höher werden die Investitions- und Wartungskosten sein. Konkrete Abwägungen müssen im Einzelfall und in Abhängigkeit von den Projektgegebenheiten getroffen werden. Während bei kurzläufigen Projekten die Nachteile der Investitionen überwiegen könnten und meist nur Testautomatisierung auf Ebene der Testdurchführung sinnvoll machen, erfahren lang laufende, inkrementell entwickelte Projekte meist einen deutlich höheren Gewinn aus den Vorteilen der frühen Qualitätssicherung und der Automatisierung über mehrere Testaktivitäten hinweg.
Fazit
Die Automatisierung der Durchführung hat in letzter Zeit wesentliche technische Fortschritte gemacht.
Mit fortschreitender Technologie mehren sich die Erfolgsberichte über Testautomatisierung. Die meisten Konzepte waren schon länger da; wir sehen „alten Wein in neuen Schläuchen“ [Win09]. Aber auch diese Technik überwindet eine akzidentelle Schwierigkeit beim Testen (die sich wiederholende Arbeit) [Bro87]. Die essenziellen Schwierigkeiten verschieben sich vielleicht zur frühen Modellbildung beim Verifizieren und werden klarer deutlich, bleiben aber da und müssen beachtet werden. Wer sie nicht beachtet, wird Fehlschläge mit der besten Automatisierung erleben. Schließlich ist auch Automatisierung kein Patentrezept [Ozk19].
Unsere Antwort an die Befürworter der vollständigen Testautomatisierung ist deshalb: Wir müssen Kosten- und Nutzenfaktoren der Automatisierung der einzelnen Testaktivitäten erkennen können. Unter passenden Rahmenbedingungen kann automatisches dynamisches Testen der effektive und effiziente Kern der Qualitätssicherung sein. Zu den günstigen Rahmenbedingungen gehören idealerweise eine verbreitete Standardtechnologie mit umfangreichen verfügbaren Testbibliotheken für eine vollumfängliche Testschnittstelle des Systems unter Test, eine langlebige Anwendung mit häufigen und schnellen Änderungszyklen, gegebenenfalls ein Variantenreichtum, und nicht zuletzt ein hochqualifiziertes Testteam, mit Testanalysten, die in abstrakten Modellen denken können, und Automatisierungsingenieuren, die die komplexe Automatisierungsarchitektur entwickeln und pflegen.
Andererseits lautet unsere Antwort an die Skeptiker: Softwaretester müssen klar zwischen Verifizierung und Validierung unterscheiden können. Das lernt man bei ISTQB schon beim Foundation Level. Beide sind wichtig. Das Verifizieren kann man bei günstigen Umständen sehr weitgehend automatisieren. Das wesentlich informellere Validieren hingegen nicht, hier ist Kreativität gefordert. Deswegen ist aber nicht das eine das „wahre Testen“ und das andere „etwas für Roboter“. Beide sind sehr wichtig und müssen sich sinnvoll ergänzen.
Weitere Informationen
[Bro87]
F. Brooks, No Silver Bullet – Essence and Accident in Software Engineering, in: IEEE Computer, 1987/4, pp. 10–19
[FTM13]
D. Faragó, A.-M. Törsel, M. Mlynarski, St. Weißleder, B. Güldali, Ch. Brandes, Wirtschaftlichkeitsberechnung für MBT: Wann sich modellbasiertes Testen lohnt, in: OBJEKTspektrum, 04/2013
[Ham19]
M. Hamburg, Ein Domänenmodell des Testens, in: German Testing Magazin, 1/2019
[ISO29119-2]
ISO/IEC/IEEE 29119-2, Software and systems engineering – Software testing – Part 2: Test processes
[ISTQB-CTFL]
ISTQB®/GTB Lehrplan Certified Tester Foundation Level, Version 2018 v3.1, siehe:
https://www.german-testing-board.info/wp-content/uploads/2020/01/CTFL-DE_Syllabus_2018_V3.1.pdf
[ISTQB-Glossar]
ISTQB®/GTB Standardglossar der Testbegriffe, siehe:
https://glossary.istqb.org/de/
[ISTQB-MBT]
ISTQB® Lehrplan Certified Tester Specialist Model-Based Tester, Version 2015, siehe:
https://www.german-testing-board.info/wp-content/uploads/2016/07/istqb_ctfl-mbt_-_syllabus_-_2015_-_final.pdf
[ISTQB-TAE]
ISTQB®/GTB Lehrplan Certified Tester Specialist Testautomatisierungsentwickler, Version 2019, siehe:
https://www.german-testing-board.info/wp-content/uploads/2019/12/Advanced-Testautomatisierungsentwickler-Syllabus_DE_2019-12-16_Version_H.pdf
[Ozk19]
I. Ozkaya, Are DevOps and Automation Our Next Silver Bullet?, in: IEEE Software, 2019/4, pp. 3–5
[Win09]
M. Winter, Modellbasiertes Testen – Alter Wein in neuen Schläuchen?, in: Proc. 10. SQC-Kongress, Düsseldorf, 28.5.2009
