Testautomatisierung ist

  • aufwändig und teuer,
  • wartungsintensiv,
  • unzuverlässig und instabil,
  • dauerhaft nur von Spezialist:innen beherrschbar.

Ist das Ihre feste Überzeugung? Dann können Sie jetzt aufhören zu lesen!
Sie könnten aber auch erfahren, wie einfach, schnell und beherrschbar das alles sein kann …

In der modernen Qualitätssicherung von Software ist Testautomatisierung ein wesentlicher Bestandteil des Entwicklungsprozesses. Mit der zunehmenden Komplexität der Softwareanwendungen wird auch die Notwendigkeit für effiziente Testmethoden immer dringlicher. Testautomatisierung hat sich gerade im Regressionstest als eine effektive Lösung herausgestellt, um Testprozesse zu beschleunigen und die Qualität der Software zu gewährleisten. Testautomatisierungist also eigentlich unverzichtbar.

Spricht man über Testautomatisierung, ist man nahezu sofort mit deren Technik konfrontiert:

  • Welche Technologie verwendet ein zu testendes System?
  • Wie kann man die Objekte, Events oder Signale erkennen, manipulieren und auslesen?
  • Welche Probleme gibt es bei der einen oder anderen Schnittstelle zu meistern?
  • Welche Werkzeuge und welche Programmiersprachen werden verwendet?

Grundlegende Methoden und sinnvolle Vorgehensweisen beim Aufbau einer Testautomatisierung und bei der Erstellung der Testspezifikation für zu automatisierende Tests kommen nur untergeordnet zur Sprache und interessieren die meisten Spezialist:innen nicht. Sie sind jedoch der entscheidende Schlüssel, der hilft, die oben aufgeführten Probleme zu überwinden. Richtig eingesetzt ist eine Low-Code- oder sogar No-Code-Testautomatisierung erreichbar, die es ermöglicht Tests unabhängig von der dafür notwendigen Technik zu spezifizieren und die oben gestellten Fragen quasi nebenbei zu beantworten.

Was ist Low-Code Testautomatisierung?

Low-Code Testautomatisierung bezieht sich auf die Erstellung und Verwaltung von automatisierten Tests mit minimalem Programmieraufwand. Dies wird durch den Einsatz von vorkonfigurierten Modulen erreicht, die es ermöglichen, Tests z.B. durch Drag-and-Drop und einfache Konfiguration zu erstellen. Dies ermöglicht es auch Personen ohne Programmierkenntnisse, Tests zu erstellen und zu pflegen, die automatisiert ausführbar sind. Die Zusammenarbeit zwischen allen Beteiligten in Entwicklung, Test und Fachbereichen verbessert sich gleichzeitig erheblich, da alle in ihrer jeweiligen Domäne bleiben können.

Keyword-Driven Testing (KDT) ist die Methode, die die dafür notwendigen Bausteine erzeugt und verwendet.

Dabei werden Tests aus vordefinierten „Schlüsselwörtern“ oder eben den „Keywords“ erstellt. Jedes Keyword repräsentiert eine bestimmte Aktion oder eine Gruppe von Aktionen, die in einem Testfall ausgeführt werden sollen.

Ein Keyword wird zentral in einer Keyword-Bibliothek abgelegt und kann daraus in vielen Testfällen aufgerufen werden. Analog zur Programmierung ist ein Keyword einer Funktion oder Methode sehr ähnlich, da es auch eine gekapselte Funktionalität abbildet. Bei einer Änderung eines Keywords werden somit alle Stellen, an denen dieses Keyword genutzt wird, automatisch mit geändert.

Diese Methode bietet gleich mehrere Vorteile:

Wiederverwendbarkeit: Keywords können in mehreren Tests wiederverwendet werden, was die Testentwicklung effizienter macht.

Lesbarkeit: Tests werden durch die Verwendung von Keywords lesbarer und verständlicher, auch für Personen ohne tiefgehende Programmierkenntnisse.

Wartbarkeit: Änderungen an einem Keyword müssen nur einmal vorgenommen werden, was die Wartung der Tests erleichtert.

Diese Vorteile werden noch verstärkt, wenn Keywords andere Keywords aufrufen und damit komplexere Abläufe oder technische Notwendigkeiten abstrahiert werden können.

KDT dient also dazu, verständliche Testfälle klar und strukturiert zu definieren. Dies umfasst die Spezifikation der Testbedingungen, der notwendigen Testdaten, der erwarteten Ergebnisse und die Beschreibung der Testschritte. Diese rein fachlichen Spezifikationen sind technologie- und plattformunabhängig.

Woher kommt die Implementierung, wenn nicht programmiert werden muss?

An die fachliche Ebene muss die Testautomatisierung angebunden sein, damit eine automatisierte Ausführung der Testfälle möglich wird. Voraussetzung ist, dass für jedes nicht mehr zusammengesetzte Keyword ein Stück Code existiert, das exakt die Funktionalität des Keywords in der gewünschten Technologie implementiert. Wie kann jetzt vermieden werden, dass an dieser Stelle dann doch intensiv programmiert werden muss, obwohl das Ziel eine Low-Code- oder sogar No-Code-Automatisierung ist? Wenn wir uns eine Schnittstelle ansehen, wie z.B. eine Web-GUI, dann lässt sich diese mit einer endlichen Anzahl von kleinen Aktionen bedienen. Solche Aktionen sind z.B. das Klicken auf einen Button oder das Aufklappen eines Menüs. Definiert man für jede dieser Aktionen ein Keyword, erhält man eine Keyword-Bibliothek mit allen Low Level Keywords zur Bedienung einer Web-GUI. Werden diese Low Level Keywords in der richtigen Reihenfolge aufgerufen, lassen sich auch die komplexesten Abläufe als Testfälle abbilden. Existiert für jedes dieser Low Level Keywords der passende Code und wird der Code der einzelnen Keywords in der in den Testfällen festgelegten Reihenfolge aufgerufen, sind die Testfälle automatisiert ausführbar.

An dieser Stelle kommt das Testautomatisierungsframework Robot Framework ins Spiel, in dem mittels KDT spezifiziert wird. Die Community des Robot Frameworks stellt für viele Technologien fertige Bibliotheken der zugehörigen Low Level Keywords zur Verfügung. So existiert z.B. für die Web-GUI die „BrowserLibrary“ die auf Basis von PlayWright eine solche fertige Implementierung bereit stellt. Über das Robot Framework werden diese Low Level Keywords nutzbar und ausführbar. Würde man jetzt aber nur mithilfe der Low Level Keywords Testfälle spezifizieren, würde das zwar funktionieren, es wären aber lange, unverständliche und schwer änderbare Testsequenzen die Folge. Aus diesem Grund müssen Low Level Keywords zu komplexeren, fachlicheren und damit verständlicheren Keywords kombiniert werden. Diese Keywords repräsentieren größere Teile eines Workflows, zum Beispiel das Einloggen in eine Anwendung oder das Anlegen eines Auftrags. Mit diesen zusammengesetzten Keywords werden die oben beschriebenen fachlichen Spezifikationen erstellt, die damit sehr viel lesbarer und verständlicher werden. Am Ende existieren zwei bis drei Ebenen von Keywords, die auf ihrer obersten Ebene sehr verständliche und leicht anpassbare Testfälle abbilden.

Ein Beispiel zur Verdeutlichung: Ein neuer Kunde soll im System angelegt werden.

Es stehen drei Low Level Keywords in der BrowserLibrary des Robot Framework zur Verfügung:
Öffnen einer URL im Browser, Anklicken eines Elements, Eingeben eines Texts, deren Robot Framework Code wie folgt aussieht:

*** Keywords ***

Open Browser

    New Page  ${URL}

Click Element

    Click  ${locator}

Input Text

    Fill Text  ${locator}  ${text}

Daraus können jetzt zwei neue Keywords „Login“ und „Lege Neuen Kunden An“ zusammengesetzt werden, denen die notwendigen Argumente für die Nutzung mit den Low Level Keywords übergeben werden:

*** Keywords ***

Login

    [Arguments]  ${username}  ${password}

    New Page  ${LOGIN_URL}

    Fill Text  id=username  ${username}

    Fill Text  id=password  ${password}

    Click  id=login-button

Lege Neuen Kunden An

    [Arguments]  ${customer_name}  ${contact_info}

    Click  id=new-customer-button

    Fill Text  id=customer-name  ${customer_name}

    Fill Text  id=contact-info  ${contact_info}

    Click  id=save-button

Aus diesen beiden Keywords lässt sich das Anlegen eines neuen Kunden spezifizieren:

*** Test Cases ***

Test Kunden Anlegen

    Login  admin  admin_password

    Lege Neuen Kunden An  John Doe  john@example.com

Jetzt ist eine verständliche und gut lesbare Ablaufsequenz über mehrere Ebenen hinweg entstanden:

Diese Reihenfolge kann von beiden Seiten gleichzeitig begonnen werden. In der Regel „treffen“ sich die Testsequenzen zwischen dem zweiten und dritten Schritt.

Im Prinzip werden hier drei Schichten der Testspezifikation abgebildet:

  1. Fachliche Schicht: Abbilden der Geschäftsprozesse mit fachlichen Keywords, oben im Bild die Ebenen 1 und 2.
  2. Technische Schicht: Abbilden der Einzelaktionen eines zu testenden Systems aus technischen Keywords in Ebene 3.
  3. Technologische Schicht: Abbilden der Technologie eines zu testenden Systems als Keyword-Bibliothek in Ebene 4.

Wie im Beispiel gezeigt, können die Testfälle der fachlichen Schicht ebenfalls im Robot Framework spezifiziert werden. Das funktioniert gut, hat aber Grenzen ab einer bestimmten Menge von Testfällen und deren Daten, oder wenn Anforderungen oder Fehler mit Testfällen verknüpft werden sollen. Außerdem bedingt es, dass auch bei der Spezifikation der Testfälle in einer Entwicklungsumgebung gearbeitet werden muss, was Personen ohne Programmierkenntnisse meist schwerfällt.

Es hat sich bewährt auf der fachlichen Schicht in eine Testmanagementumgebung zu wechseln, die ebenfalls die Methode des Keyword-Driven Tests zur Spezifikation von Testfällen zur Verfügung stellt und gleichzeitig die wichtigsten Möglichkeiten einer Entwicklungsumgebung bietet. Das hat zusätzlich große Vorteile bei der Auswahl und Planung der Testfälle und ermöglicht, dass Anforderungen und Fehler mit Testfällen verlinkt werden und so eine Traceability von Anforderungen über Testspezifikation und Testergebnissen bis zu Fehlern hergestellt wird, ohne dass solche Informationen innerhalb einer Entwicklungsumgebung manuell in die Definition der Testfälle eingetragen werden muss.

Voraussetzung dafür ist, dass die Definition der fachlichen Keywords in die Spezifikationsumgebung des Testmanagements importiert und immer wieder abgeglichen werden. Ebenso müssen Grundprinzipien einer Entwicklungsumgebung erfüllt sein, wie z.B., dass jederzeit ersichtlich ist, wie ein Keyword definiert ist oder wo es überall aufgerufen wird und eine Unterstützung beim Refactoring zur Verfügung steht.

Für das im Testmanagement- und Testdesignsystem TestBench ist das der Fall. Die Testsequenz unseres Beispiels sieht dann wie folgt aus:

Für die Parameter wurden die Argumente der Keywords aus dem Robot Framework als Datentypen importiert, in denen dann die notwendigen Werte abgelegt werden. Statt der festen Werte für die Parameter können auch diese Datentypen eingefügt werden, die dann wie Variablen fungieren:

Diese Variablen werden über eine Datentabelle mit Werten versorgt:

Das Ergebnis ist ein datengetriebener Test, der mit mehreren Datenkombinationen versorgt werden kann, für die in der Testausführung jeweils ein Durchlauf der Testsequenz erfolgt. Vor der eigentlichen Ausführung der Tests aus TestBench wird der gleiche Robot Framework Code generiert, wie er am Ende unseres Beispiels im Robot Framework spezifiziert wurde.

Die bis jetzt beschriebene Architektur der Lösung lässt sich schematisch als zwei Komponenten darstellen:

Die drei Schichten unserer Testspezifikation sind hier gut zu erkennen.

Die Durchführung der Tests

Für die Durchführung der Tests müssen anhand der auf der fachlichen Ebene festgelegten Reihenfolge die Low Level Keywords ausgeführt werden, was durch die on-the-fly Generierung des Robot Framework Codes sichergestellt ist. Zusätzlich müssen während der Testdurchführung die Testergebnisse auf allen Ebenen protokolliert, die Fehlerfälle behandelt und zusätzliche Informationen, wie Logdateien oder Screenshots erzeugt und angehängt werden.

Es wird also eine dritte Komponente benötigt, die diese Aufgaben übernimmt:

Diese drei Komponenten bilden die generische Testautomatisierungsarchitektur[1] (gTAA) ab, die sich als Best Practice sehr bewährt hat:

  1. Spezifikationsebene: Hier entsteht die oben beschriebene Testspezifikation unter Nutzung der Keywords.
  2. Testdurchführungsebene: Die Keywords werden in der Reihenfolge und mit den Daten aus der Spezifikationsebene ausgeführt. Testergebnisse werden ermittelt und protokolliert.
  3. Technische Adaption: Für jedes nicht mehr zusammengesetzte Keyword existiert eine Implementierung passend für die notwendige Technik, wie z.B. eine Web-GUI.

Über diese drei Ebenen wird sichergestellt, dass jedes Keyword in seinem richtigen fachlichen Kontext in der Testspezifikation und in seinem richtigen technischen Kontext in der Testdurchführung verwendet wird.

Damit liegt auch die eindeutige Aufgaben- und Rollen-Verteilung bei der Erstellung und Nutzung einer Testautomatisierung vor:

  • Testspezifizierende kümmern sich ausschließlich um den fachlichen Inhalt der Tests, der Testschritte und der Testdaten, benötigen aber keine Kenntnis über den Code der Implementierung.
  • Testautomatisierende sind für die Implementierung der einzelnen Keywords zuständig, müssen aber keine Kenntnis über die fachlichen Zusammenhänge besitzen, sondern können sich ganz auf die Lösung der technischen Probleme konzentrieren.

So ergeben sich für beide Rollen eindeutige Stellen, an denen geändert werden muss, ohne dass zwangsläufig die andere Rolle davon betroffen ist und wenn doch, dann eine eindeutige Schnittstelle gegeben ist. Die Testdurchführungsebene verbindet die beiden anderen Ebenen zur Laufzeit der Testdurchführung und reicht die erzielten Testergebnisse nach oben weiter.

Dabei wird für jedes nicht mehr zusammengesetzte Keyword ein Ergebnis ermittelt. Diese Ergebnisse werden über die zusammengesetzten Keywords zum Gesamtergebnis eines Testfalls oder auch einer ganzen Testsuite kumuliert.

Als sehr gute Umsetzung der gTAA hat sich die Kombination aus TestBench und Robot Framework erwiesen. Dabei teilen sich die drei Ebenen wie folgt auf:

Sowohl TestBench als auch Robot Framework beherrschen Keyword-Driven und Data-Driven Test, so dass es keinen Methodenbruch zwischen den Systemen gibt. Beide teilen sich die Ebenen der generischen Testautomationsarchitektur ideal auf, so dass es auch nur sehr wenige funktionale Überschneidungen gibt. Gerade die mehreren Hundert Low Level Bibliotheken des Robot Frameworks stellen sicher, dass neue Technologien schnell eingesetzt werden können. Z.B. die Erweiterung der Web-GUI-Tests um Tests für eine Mobile App sind kein großes Problem, da auch mehrere Low Level Keyword Bibliotheken gleichzeitig eingesetzt werden können. So sind übergreifende End-to-End Tests z.B. von SAP über Browser und Apps zu REST-APIs und Datenbankinhalten kein Problem mehr.

Die skizzierte Lösung ist zusätzlich in der Lage, nicht automatisierte, manuelle Tests nur auf der Ebene der fachlichen Spezifikation abzubilden und erst später zu entscheiden, ob sie automatisiert werden.

Fazit

Low-Code Testautomatisierung mit Keyword-Driven Testing und einer generischen Testautomatisierungsarchitektur bietet zahlreiche Vorteile für die Softwarequalitätssicherung. Durch die Reduzierung des Programmieraufwands, die Verbesserung der Wartbarkeit und die Förderung der Zusammenarbeit kann die Effizienz und Qualität des Testprozesses erheblich gesteigert werden. Tools wie TestBench in Kombination mit dem Robot Framework unterstützen diese Methoden und bieten umfassende Funktionen für die Planung, Implementierung, Ausführung und Analyse von Tests. Die leichte Einbindung der Testautomatisierung in Entwicklungslandschaften mit Anforderungs- und Fehlermanagement und oft notwendigem Berichtswesen zur Erfüllung diverser Nachweispflichten ist eine weiterer wichtiger Vorteil dieser Kombination.

Durch die Nutzung dieser modernen Testmethoden und Werkzeuge können Softwareteams sicherstellen, dass ihre Produkte den höchsten Qualitätsstandards entsprechen, sie schnell auf Veränderungen reagieren können und gleichzeitig die Testkosten und der Aufwand minimiert wird.

 

[1] Certified Tester Advanced Level Syllabus – Test Automation Engineer: The Generic Test Automation Architecture und ISO/IEC/IEEE 29119-5, Figure 8 — Components of a Keyword-Driven Testing framework for automated test execution