Keyword-Driven Testing ist seit 2024 ISO-Standard — was das für Testfall-Frameworks bedeutet

TL;DR: Mit ISO/IEC/IEEE 29119-5:2024 (zweite Edition, 19. Dezember 2024) gibt es erstmals einen internationalen Standard für Keyword-Driven Testing. Er verlangt hierarchische Keyword-Ebenen, eine saubere Trennung von Testdaten, Keywords und Implementierung sowie ein gemeinsames Datenaustauschformat. Robot Frameworks Architektur deckt sich strukturell mit diesem Modell — eine de-facto-Umsetzung, ohne dass die Foundation einen formellen Konformitäts-Claim erhebt. Die Mitbewerber im Testfall-Raum (Cucumber, Gauge, FitNesse) folgen anderen Paradigmen.

Lesedauer ca. 5 Min · Stand: 2026-04

Am 19. Dezember 2024 hat die ISO mit ISO/IEC/IEEE 29119-5:2024 Keyword-Driven Testing als internationalen Standard formalisiert. Der Standard definiert Architektur, Schnittstellen und Schichten-Modell für Frameworks, die Testfälle aus wiederverwendbaren Schlüsselwörtern aufbauen. Die zweite Edition ersetzt den Vorgänger von 2016 und richtet sich an alle, die KDT-Frameworks bauen, KDT-Spezifikationen schreiben oder Testautomatisierung auf Keyword-Basis aufsetzen.

Für die Testfall-Schicht hat das eine konkrete Konsequenz: Es gibt jetzt einen offiziellen Referenzrahmen, an dem sich Frameworks messen lassen müssen. Und es gibt ein Framework, dessen Architektur diesen Rahmen seit über 15 Jahren de facto abbildet: Robot Framework.

Was der Standard verlangt

ISO/IEC/IEEE 29119-5:2024 wird vom Joint Technical Committee ISO/IEC JTC 1/SC 7 verantwortet, derselben Working Group, die auch die anderen Teile der 29119-Reihe pflegt. Der Standard schreibt unter anderem vor:

Hierarchische Keyword-Ebenen — technische Low-Level-Keywords kombiniert zu fachlichen Business-Level-Keywords
Trennung von Testdaten, Keywords und Implementierung, damit Artefakte zwischen Werkzeugen austauschbar bleiben
Anforderungen an Frameworks, die KDT unterstützen — gilt für Test-Automatisierungs-, Test-Design- und Test-Management-Tools
Ein gemeinsames Datenaustauschformat für Testfälle, Testdaten und Testergebnisse über Werkzeuggrenzen hinweg

Das ist keine kleine Aufräum-Übung. Der Standard adressiert ausdrücklich den ganzen Werkzeugraum, nicht ein einzelnes Produkt. Er ist der erste internationale Referenzpunkt für ein Paradigma, das in der Praxis bis dahin auf Bücher von Fewster, Graham und Buwalda sowie das ISTQB-Glossar verteilt war.

Robot Framework deckt sich mit dem Modell

Die Architektur von Robot Framework ist im offiziellen User Guide als modular und keyword-getrieben dokumentiert. Sie folgt vier Schichten:

Test Data — .robot-Dateien mit tabellarischer Syntax, getrennte Sektionen für Tests, Keywords, Variablen, Settings
Robot Framework Core — Parser, Runner, Reporter; kennt das System Under Test nicht
Test Libraries — Standard- und externe Libraries (SeleniumLibrary, Browser/Playwright, RequestsLibrary, AppiumLibrary, DatabaseLibrary)
System Under Test — die Anwendung selbst

User Keywords aus Resource Files abstrahieren Library Keywords zu fachlichen Schritten. Genau diese Hierarchie verlangt der ISO-Standard. Sogeti Labs hat das bereits 2018 gegen die ISTQB Generic Test Automation Architecture (gTAA) gespiegelt und festgestellt: Die Schichten decken sich.

Eine Einschränkung gehört zur ehrlichen Einordnung: Eine offizielle Konformitäts-Erklärung der Robot Framework Foundation gibt es bisher nicht. Niemand hat ein Audit gegen 29119-5:2024 durchgeführt, weder die Foundation selbst noch sonst irgendjemand. Was sich belegen lässt, ist die strukturelle Übereinstimmung der Architektur mit den Anforderungen des Standards. Das ist nicht dasselbe wie ein Zertifikat. Es ist aber mehr als ein Marketing-Claim.

Die Konkurrenz spielt in einer anderen Disziplin

Wer auf der Testfall-Ebene Alternativen sucht, landet schnell bei Cucumber, SpecFlow/Reqnroll, Gauge oder FitNesse. Drei davon sind primär BDD-Tools, eines ist Fixture-basiert. Keiner dieser Ansätze entspricht dem Keyword-Hierarchie-Modell von 29119-5:2024.

Framework	Paradigma	Verhältnis zu 29119-5
Robot Framework	Keyword-Driven (hierarchisch)	Architektur deckt sich mit dem Standard
Cucumber	BDD (Gherkin)	Behavior-driven; Steps sind keine hierarchischen Keywords
SpecFlow / Reqnroll	BDD (.NET)	wie Cucumber; SpecFlow ist seit 2024 deprecated
Gauge	Specification-driven (Markdown)	zwischen BDD und KDT, ohne Keyword-Hierarchie
FitNesse	Fixture-basiert (Wiki)	älter als der Standard; tabellarisch, aber kein Keyword-Modell
TestComplete / Katalon	Hybrid (kommerziell)	bewerben Keyword-Driven-Modi, ohne Standard-Bezug

Die Differenzierung ist wichtig, weil BDD und KDT in Marketing-Texten regelmässig vermischt werden. BDD optimiert für Konversation zwischen Fachbereich und Entwicklung. KDT optimiert für wiederverwendbare Schritt-Bausteine über Test-Suiten hinweg. Beide Ansätze haben Berechtigung. Aber nur einer wird vom ISO-Standard adressiert.

Wo Robot Framework an Grenzen stösst

Robot Framework ist nicht für jeden Test-Typ die richtige Wahl. Drei Szenarien, in denen andere Werkzeuge effizienter sind:

Reine Unit-Tests — Pytest, JUnit oder NUnit kommen mit weniger Overhead aus
Performance- und Last-Tests — JMeter, Gatling oder k6 sind hier die Primär-Werkzeuge
Hochfrequente, rein technische Entwicklertests — wenn alle Stakeholder Code lesen können, ist Pytest oder Playwright Test schneller iterierbar

Für funktionale Tests auf Acceptance-, Integration- und E2E-Ebene bleibt Robot Framework in den meisten Szenarien die naheliegende Wahl, insbesondere dort, wo fachliche Stakeholder Tests lesen, kommentieren und teilweise selbst schreiben sollen.

Was das für die Tool-Auswahl bedeutet

Für QA-Leads und Engineering-Verantwortliche schafft der Standard eine neue Argumentationsbasis. Wer heute eine Testautomatisierung aufsetzt oder bestehende Suiten konsolidiert, kann Tool-Entscheidungen erstmals gegen einen formalen Referenzrahmen begründen, nicht gegen einen Vendor-Whitepaper oder einen einzelnen Architektur-Blog.

UTAA, die framework-agnostische Methodik für Test-Automatisierung der QualityScope GmbH (Luzern), empfiehlt für die Testfall-Schicht in den meisten Fällen Robot Framework. Begründung: Die Architektur deckt sich mit dem ISO-Standard, das Library-Ökosystem ist breit, und der Keyword-Ansatz reduziert die Wartungslast bei wachsenden Suiten messbar. Pipeline-, Test-Daten- und CI/CD-Schicht bleiben getrennt. Dafür ist UTAA die Methodik.

Drei Fragen vor der Tool-Entscheidung:

Sollen Tests von Personen lesbar bleiben, die keinen Code schreiben?
Wachsen die Suiten so weit, dass Wiederverwendung von Schritt-Bausteinen über Suiten hinweg nötig wird?
Spielt internationale Standard-Konformität bei der Toolwahl eine Rolle, etwa für Audits, Beschaffung oder regulierte Branchen?

Bei zwei oder drei Mal “ja” lohnt der Blick auf Robot Framework. Und auf den Standard, der dahinter steht.

Quellen

Sie evaluieren KDT-Frameworks oder konsolidieren bestehende Test-Suiten? Im UTAA-Workshop ordnen wir Tool-Entscheidungen gegen den 29119-5-Rahmen und Ihren Stack ein. Mehr zur Methode oder direkt anfragen.