The Keyword Is the Contract – Wie die richtigen Abstraktionsebenen die Zusammenarbeit, die Wartbarkeit und die technische Flexibilität verbessern

Öffnet man eine Testspezifikation, steht dort: Ein:e Kund:in gibt eine Bestellung auf. Öffnet man die Automatisierung desselben Tests, findet man vierzig Zeilen mit Selektoren, Wartebedingungen und Assertions. Beides soll denselben Test beschreiben. Drei Sprints später wurde ein Schritt im Checkout verschoben. Jemand hat den Code angepasst aber nicht die Spezifikation. Nun kann niemand mehr sagen, welche Fassung noch stimmt.

Wer schon einmal ein Jahr lang eine Testsuite gepflegt hat, kennt diese Situation. Das Problem liegt nicht in der Kommunikation. Es fehlt eine Schnittstelle.

Die Personen, die am besten entscheiden können, was getestet werden soll, sind meist nicht diejenigen, die den Test automatisieren können. Fachtester:innen kennen Prozesse, Anforderungen und die relevanten Szenarien. Automatisierungsentwickler:innen kennen Frameworks, Schnittstellen und die technischen Details des Testsystems. Bei der klassischen Automatisierung arbeiten beide Gruppen nacheinander: erst spezifizieren, dann automatisieren. Jede Änderung an der Spezifikation erfordert eine Änderung am Code. Wenn niemand die Resultate fortlaufend von Hand abgleicht, entwickeln sie sich auseinander.

Bei vierteljährlichen Releases ließ sich diese Abweichung noch verkraften. Bei wöchentlichen Releases nicht mehr. Die Zyklen werden kürzer, die Erwartungen steigen, und eine Spezifikation, der niemand vertraut, wird von einer Dokumentation zur Belastung.

Mehr Disziplin allein löst das Problem nicht. Abstraktion hilft – und zwar an mehr Stellen, als viele Teams vermuten.

Warum Abstraktion?

Für sauberen Code gibt es einen Grundsatz: eine Abstraktionsebene pro Funktion. Eine Funktion bleibt auf einer Detailebene, statt fachliche Logik mit der Verarbeitung einzelner Zeichenketten zu vermischen. Das macht Code lesbarer, verständlicher, wartbarer und wiederverwendbar. Auf Tests lässt sich dieser Grundsatz übertragen. Zwei Standards zeigen, wo die Abstraktion ansetzen kann.

Abstraktion 1: die Architektur der Testautomatisierung

Die Generische Testautomatisierungsarchitketur des ISTQB, beschrieben im CTAL-TAE-Lehrplan, überträgt denselben Gedanken auf die Automatisierungslösung und unterscheidet vier Ebenen:

• Testgenerierung – Testfälle entwerfen und entscheiden, was getestet wird
• Testdefinition – Testsuiten, Testfälle, Testdaten und die wiederverwendbare Keyword-Bibliothek
• Testausführung – die Ausführungsumgebung für Tests, Protokolle und Berichte
• Testanpassung – der Code, der mit den Schnittstellen des Testsystems kommuniziert

Nützlich ist das Modell durch die Trennung, die es vorgibt. Eine Änderung auf einer Ebene erzwingt selten Änderungen auf einer anderen. Wird ein Button umbenannt, betrifft das die Anpassungsebene – nicht zweihundert Testfälle. Und wenn derselbe fachliche Schritt statt über die Benutzeroberfläche über eine API geprüft wird, muss sich an der Testdefinition nichts ändern.

Die Ebenen zeigen, wo die Grenzen verlaufen. Sie erklären aber noch nicht, wie eine auf der obersten Ebene formulierte Absicht unten zu ausführbarem Code wird.

Abstraktion 2: die Testspezifikation

Die Antwort ist Keyword Driven Testing. ISO/IEC/IEEE 29119-5 beschreibt diesen Ansatz und in der zweiten Ausgabe von 2024 die Hierarchie ausdrücklich. Ganz unten stehen allgemeine technische Keywords wie „Click“, „Fill Text“ oder „Get Element States“. Daraus werden fachliche Keywords wie „Anmeldung mit Kundenkonto“ oder „Bestellung aufgeben“ zusammengesetzt. Ein Testfall besteht dann aus einer Folge fachlicher Keywords und den zugehörigen Testdaten. Wer den Fachbereich kennt, kann ihn lesen, ohne Code vor sich zu haben.

Die Hierarchie allein ist dabei nicht das Entscheidende. Sie schafft einen Vertrag: Der Name eines Keywords und seine Parameter bilden die Schnittstelle zwischen beiden Welten. Fachtester:innen können Schritte umstellen, eine Datenvariante ergänzen oder aus vorhandenen Keywords einen neuen Testfall zusammenstellen, ohne den Automatisierungscode anzufassen.

Abstraktion 3: die Tools

Hier kommt der Schritt, den viele Teams auslassen: Wenn die Ebenen tatsächlich getrennt sind, muss kein einzelnes Werkzeug alle abdecken. Das ist wichtig, weil die beiden Gruppen unterschiedliche Arbeitsweisen haben. Sollen Fachtester:innen Tests in VS Code spezifizieren, arbeiten sie plötzlich in einer IDE, die , wie auch Git nicht zu ihrem gewohnten Arbeitskontext gehört. Müssen Automatisierungsentwickler:innen technische Schritte durch Klicks in einer grafischen Oberfläche implementieren, fehlen ihnen die wichitgen Grundlagen ihrer Arbeit, wie Autovervollständigung, Refactoring, Versionsverwaltung und Code-Reviews.

Deshalb sollte für jede Ebene das passende Werkzeug gewählt und anschließend eine Verbindung zwischen den Ebenen geschaffen werden. In unserem Fall deckt TestBench die Testdefinition vollständig ohne Code ab: Fachtester:innen pflegen Keywords und Testdaten in einer grafischen Oberfläche und stellen daraus Testfälle zusammen. Robot Framework und VS Code übernehmen die Implementierung: Low-Code, wo die vorhandenen Robot-Framework-Bibliotheken ausreichen, und reguläres Python in benutzerdefinierten Keywords, wo sie nicht ausreichen.

testbench2robotframework erzeugt aus einem TestBench-Bericht Robot-Framework-Testsuiten und schreibt die Ergebnisse zurück. Die TestBench-Erweiterung für VS Code hält Keywords, Beschreibungen und Testdaten synchron. ISO/IEC/IEEE 29119-5 berücksichtigt genau diesen Fall. Der Standard definiert Anforderungen an ein gemeinsames Datenaustauschformat, damit Werkzeuge verschiedener Anbieter Testfälle, Keywords und Testdaten untereinander austauschen können. Der Austausch zwischen Werkzeugen ist kein Behelf, weil es kein passendes All-in-one-Produkt gäbe. Der Standard sieht ihn als Normalfall vor.

Wo der Ansatz an Grenzen stößt

Abstraktion gibt es nicht umsonst. Keyword-Bibliotheken wachsen. Ein ungepflegter Katalog mit Hunderten fast identischer Keywords kann schlimmer sein als gar keiner: Niemand findet das passende, also legen alle ein weiteres an. Zu kleinteilige Keywords wie „Click button“ oder „Enter text“ tragen technische Details direkt zurück in die Testspezifikation und machen den Vorteil zunichte. Die Ebenen funktionieren nur, wenn jemand die Keyword-Bibliothek verantwortet, Namenskonventionen vereinbart und durchsetzt und Keywords genauso gründlich geprüft werden wie Code. Standards liefern die Struktur. Die Disziplin, sie sauber zu halten, muss das Team selbst aufbringen.

Was das konkret bringt

Zwei Dinge: ein gemeinsames Ergebnis, das Fachtester:innen lesen und Automatisierungsentwickler:innen ausführen können. Und, weniger offensichtlich: eine gemeinsame Sprache. Im Domain-driven Design heißt das „Ubiquitous Language“: ein einheitlicher, klar definierter Wortschatz, den Fachleute und Entwickler:innen sowohl im Gespräch als auch im Code verwenden. Keyword-Driven Testing schafft eine solche Sprache gewissermaßen nebenbei. Wenn „Bestellung aufgeben“ im Review, im Testfall und als Robot-Framework-Keyword dasselbe bedeutet, müssen die beiden Gruppen nicht mehr zwischen ihren Welten übersetzen. Sie arbeiten am selben Satz.

Weiterführende Links

Entkomme dem Chaos: No-Code-Testautomatisierung mit Low-Code Integration via Robot Framework und TestBench

Suchen