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 relabelled 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. ISO/IEC/IEEE 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 near-identical 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.

Further reading

Leave Complexity Behind: No-Code Test Automation with Low-Code integration via Robot Framework and TestBench

Search