The Keyword Is the Contract

How the right layers of abstraction improve collaboration, maintainability and technical flexibility

Open a test specification and you read: the customer places an order. Open the automation for the
same test and you find forty lines of selectors, waits and assertions. Both claim to describe one test.
Three sprints later a checkout step has moved, someone patched the code but not the specification,
and nobody can say which one is still true.

Anyone who has maintained a test suite for a year knows the situation. It isn’t a communication
problem. It’s a missing interface.

The people best placed to decide what to test are usually not the people who can automate it.
Business testers understand processes, requirements and the scenarios that matter. Automation
engineers understand frameworks, interfaces and the technical details of the system under test.
Traditional automation puts the two groups in a relay race: first specify, then automate. Every
change to the specification means a change to the code, and unless someone keeps paying the
manual cost of alignment, the two artifacts drift.

That drift was survivable when releases came quarterly. At weekly, it isn’t. Cycles get shorter,
expectations keep rising, and a specification nobody trusts stops being documentation and becomes
a liability.

More discipline won’t fix it. Abstraction will, applied in more places than most teams think.

Why Abstraction

Clean code has a rule for it: single level of abstraction. A function works on one level of detail instead
of mixing business logic with string handling. What you get is readability, understandability,
maintainability and reuse. Testing can borrow the principle, and two standards tell you where to put
it.

Abstraction 1: The Test Automation Architecture

ISTQB’s Generic Test Automation Architecture, laid out in the CTAL-TAE syllabus, applies the same
idea to the automation solution and separates four layers:

Test generation — designing test cases, deciding what to test
Test definition — test suites, test cases, test data, the reusable keyword library
Test execution — the engine that runs the tests, logs and reports
Test adaptation — the code that talks to the interfaces of the system under test

What makes the model useful is the separation it enforces. A change in one layer rarely forces a
change in another. A re-labelled button hits the adaptation layer, not two hundred test cases. Swap a UI-driven check for an API call on the same business step and the test definition layer never notices. The layers tell you where the boundaries belong, not how an intent stated at the top arrives as
executable code at the bottom.

Abstraction 2: The Test Specification

Keyword-driven testing is the answer. ISO/IEC/IEEE 29119-5 describes keyword-driven testing, and
the second edition from 2024 is explicit about hierarchy. At the bottom sit generic technical
keywords such as “Click” , “ Fill Text ” or “Get Element States ” . Those get composed
into business-level keywords: “ Log in as a registered customer ” , “ Place an
order ” . A test case is then a sequence of business keywords plus test data, readable by anyone
who knows the domain, with no code in sight.

The hierarchy itself isn’t the most interesting part. What it produces is a contract. The keyword name
and its parameters are the interface between the two worlds. A business tester can reorder steps,
add a data variant or build a new test case from existing keywords without touching automation
code. An automation engineer can rewrite whatever happens behind “ Place an order ” , new
UI, new API, new library, without invalidating a single test case. Each side changes what it owns. The
artifacts stay aligned because the thing that matters exists only once: the keyword.

Abstraction 3: The Tooling

Here is the step most teams skip. If the layers really are separate, no single tool must cover all of
them. That matters, because the two groups don’t want the same tool. Ask a business tester to
specify tests in VS Code and you lose them; an IDE isn’t their workplace and Git isn’t their
vocabulary. Ask an automation engineer to implement technical steps by clicking through a GUI and
you take away autocompletion, refactoring, version control and code review, which is most of what
makes engineering possible.

So choose per layer, then connect the layers. In our case, TestBench covers test definition, entirely
no-code: business testers maintain keywords and test data in a GUI and assemble test cases from
them. Robot Framework and VS Code cover the implementation, low-code where the existing Robot
Framework libraries suffice and real Python in user keywords where they don’t.
testbench2robotframework generates Robot Framework suites from a TestBench report and writes
the results back, and the TestBench extension for VS Code keeps keywords, descriptions and test
data in sync.

29119-5 expects this. The standard defines requirements for a common data exchange format so
that tools from different vendors can hand test cases, keywords and test data to each other.
Exchanging artifacts between tools isn’t a workaround for the all-in-one product nobody sells; the
standard treats it as the normal case.

Where It Breaks

Abstraction isn’t free. Keyword libraries grow, and an unmaintained catalogue of hundreds of nearidentical keywords is worse than none: nobody finds the right one, so everybody adds another.
Keywords cut too finely (Click button, Enter text) push technical detail straight back into the test
specification and cancel out the benefit. Layers hold only if someone owns the keyword library, if
naming conventions are agreed and enforced, and if keywords get reviewed as seriously as code.
Standards hand you a structure. Nobody hands you the discipline to keep it clean.

What You Actually Gain

Two things. A shared artifact that a business tester can read and an engineer can execute. And, less
obviously, a shared vocabulary. Domain-driven design calls this a ubiquitous language: one rigorous
set of terms used by domain experts and developers alike, in conversation and in the code. Keyword driven testing produces exactly that as a by-product. When “Place an order” means the same thing in a review meeting, in a test case and in a Robot Framework keyword, the two groups have stopped translating between worlds. They are editing the same sentence.