Keyword-Driven Testing has been an ISO standard since 2024 — what that means for test-case frameworks

TL;DR: ISO/IEC/IEEE 29119-5:2024 (second edition, 19 December 2024) is the first international standard for keyword-driven testing. It mandates hierarchical keyword levels, a clean separation between test data, keywords and implementation, and a common data exchange format. Robot Framework’s architecture aligns structurally with this model — a de-facto implementation, without the Foundation asserting any formal conformance claim. Competitors in the test-case space (Cucumber, Gauge, FitNesse) follow different paradigms.

Reading time approx. 5 min · As of: 2026-04

On 19 December 2024, ISO formalised keyword-driven testing as an international standard with ISO/IEC/IEEE 29119-5:2024. The standard defines architecture, interfaces and a layer model for frameworks that build test cases from reusable keywords. The second edition supersedes the 2016 predecessor and is aimed at anyone building KDT frameworks, writing KDT specifications or setting up keyword-based test automation.

For the test-case layer this has a concrete consequence: there is now an official reference frame against which frameworks must measure themselves. And there is one framework whose architecture has de facto matched this frame for over 15 years: Robot Framework.

What the standard requires

ISO/IEC/IEEE 29119-5:2024 is owned by the Joint Technical Committee ISO/IEC JTC 1/SC 7, the same working group that maintains the other parts of the 29119 series. Among other things, the standard mandates:

Hierarchical keyword levels — technical low-level keywords combined into business-level keywords
Separation of test data, keywords and implementation, so artefacts remain interchangeable across tools
Requirements for frameworks that support KDT — applies to test-automation, test-design and test-management tools
A common data exchange format for test cases, test data and test results across tool boundaries

This is not a small tidy-up. The standard explicitly addresses the entire tool space, not a single product. It is the first international reference point for a paradigm that until now lived scattered across books by Fewster, Graham and Buwalda and the ISTQB glossary.

Robot Framework aligns with the model

Robot Framework’s architecture is documented in the official User Guide as modular and keyword-driven. It follows four layers:

Test data — .robot files with tabular syntax, separate sections for tests, keywords, variables, settings
Robot Framework Core — parser, runner, reporter; agnostic of the system under test
Test libraries — standard and external libraries (SeleniumLibrary, Browser/Playwright, RequestsLibrary, AppiumLibrary, DatabaseLibrary)
System under test — the application itself

User keywords from resource files abstract library keywords into business-level steps. Exactly this hierarchy is what the ISO standard requires. Sogeti Labs mapped this against the ISTQB Generic Test Automation Architecture (gTAA) back in 2018 and concluded: the layers align.

One caveat for honest framing: there is no official conformance declaration from the Robot Framework Foundation. No one has audited the framework against 29119-5:2024 — neither the Foundation itself nor any third party. What can be substantiated is the structural alignment of the architecture with the standard’s requirements. That is not the same as a certificate. But it is more than a marketing claim.

The competition plays in a different discipline

Anyone looking for alternatives at the test-case layer quickly arrives at Cucumber, SpecFlow/Reqnroll, Gauge or FitNesse. Three of them are primarily BDD tools, one is fixture-based. None of these approaches matches the keyword-hierarchy model of 29119-5:2024.

Framework	Paradigm	Relationship to 29119-5
Robot Framework	Keyword-driven (hierarchical)	Architecture aligns with the standard
Cucumber	BDD (Gherkin)	Behaviour-driven; steps are not hierarchical keywords
SpecFlow / Reqnroll	BDD (.NET)	Like Cucumber; SpecFlow has been deprecated since 2024
Gauge	Specification-driven (Markdown)	Between BDD and KDT, no keyword hierarchy
FitNesse	Fixture-based (wiki)	Older than the standard; tabular, but no keyword model
TestComplete / Katalon	Hybrid (commercial)	Advertise keyword-driven modes, no standard reference

The differentiation matters because BDD and KDT are routinely conflated in marketing copy. BDD optimises for conversation between business and engineering. KDT optimises for reusable step building blocks across test suites. Both approaches have merit. But only one is addressed by the ISO standard.

Where Robot Framework hits its limits

Robot Framework is not the right choice for every test type. Three scenarios where other tools are more efficient:

Pure unit tests — Pytest, JUnit or NUnit run with less overhead
Performance and load tests — JMeter, Gatling or k6 are the primary tools here
High-frequency, purely technical developer tests — when every stakeholder reads code, Pytest or Playwright Test iterates faster

For functional tests at acceptance, integration and E2E level, Robot Framework remains the obvious choice in most scenarios — particularly where business stakeholders are expected to read, comment on or even author tests.

What this means for tool selection

For QA leads and engineering owners the standard creates a new basis for argument. Anyone setting up test automation today, or consolidating existing suites, can for the first time justify tool decisions against a formal reference frame, not against a vendor whitepaper or a single architecture blog.

UTAA, the framework-agnostic methodology for test automation by QualityScope GmbH (Lucerne), recommends Robot Framework on the test-case layer in most cases. The reasoning: the architecture aligns with the ISO standard, the library ecosystem is broad, and the keyword approach measurably reduces maintenance overhead as suites grow. Pipeline, test-data and CI/CD layers remain separate. That’s where UTAA acts as the methodology.

Three questions before the tool decision:

Should tests remain readable by people who don’t write code?
Will suites grow to the point that reusing step building blocks across suites becomes necessary?
Does international standards conformance matter for tool choice — for audits, procurement or regulated industries?

Two or three “yes” answers make Robot Framework worth a look. As does the standard behind it.

Sources

Evaluating KDT frameworks or consolidating existing test suites? In a UTAA workshop we map tool decisions against the 29119-5 reference frame and your stack. More about the method or get in touch directly.