Keyword-driven design

Keyword-driven testing turns business components into a language. Instead of code, a test becomes a table of steps, each naming a keyword and the data it operates on. The ISTQB syllabus defines keyword-driven test cases as a list or table of test steps derived from keywords and the test data the keywords operate on, with keywords defined from a user's perspective, and notes the technique is often built on data-driven testing. The international standard for the approach is ISO/IEC/IEEE 29119-5, the keyword-driven testing part of the 29119 software testing series; the ISTQB syllabus also points out that keyword-driven testing can be used for manual testing independent of automation.

A keyword test for SAP

Keyword	Arguments	Expected
Log On As	role = Order-to-Cash Key User	Launchpad shows the sales page
Create Sales Order	sales area 1710/10/00; sold-to Great Lakes Fleet Services; CMC-ALT-100 × 50	Order number returned; no error
Check Sales Order	order = (from previous step)	Net value 12,000.00 USD; status Open
Create Outbound Delivery	order = (from step 2); shipping point 1710	Delivery number returned
Post Goods Issue	delivery = (from step 4)	Material document created
Create Billing Document	delivery = (from step 4)	Billing document and journal entry created
Check Journal Entry	billing document = (from step 6)	Revenue posted in company code 1710

A keyword-driven order-to-cash test. The 12,000.00 USD net value is illustrative and assumes a 240.00 USD unit price.

Behind one readable keyword row sit a business component and an adapter, and its output feeds the next rows.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-301

Anyone who knows the process can read and review that table, and a business analyst can write new variants of it without programming. Behind each keyword sits a business component (lesson 2), and behind that the adapters. The keyword layer is a thin, readable surface over the framework you already designed.

Levels of keywords

In practice, keyword frameworks distinguish levels. Business-level keywords such as Create Sales Order map to business components. Technical or interface-level keywords such as Enter Field or Press Button exist inside the framework but should not appear in business tests. Composite keywords can bundle a recurring sequence (for example Ship Order = Create Outbound Delivery + Post Goods Issue). The current edition of the standard, ISO/IEC/IEEE 29119-5:2024 (second edition, published December 2024), defines levels of hierarchical keywords and advises when to use them rather than flat keywords, lists generic low-level example keywords such as inputData and checkValue that combine into business-level keywords, and defines a common data exchange format so keyword-driven test specifications can move between tools. Consult it for the standard's own terms and structure; the design principle that matters is that tests use the highest-level keyword that still lets them express their purpose.

Test case (table)Sequence of business keywords with arguments and expected results.

Business keywordsCreate Sales Order, Post Goods Receipt, Check Journal Entry: one per business component.

Composite keywordsRecurring sequences such as Ship Order; use sparingly.

Technical keywordsEnter Field, Press Button, Call OData Entity Set: internal to the framework.

AdaptersFiori, SAP GUI, OData, SOAP, IDoc.

Keyword levels in an SAP framework. Business tests stay on the top two levels.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-301

Strengths and costs

	Keyword-driven	Data-driven only	Behavior-driven (given/when/then)
Who writes tests	Testers and analysts, from a keyword catalog	Analysts fill data files for existing scripts	Business, developers and testers together
Main strength	Readable, reusable, works for manual tests too	Cheap expansion through data rows	Shared understanding of acceptance criteria
Main cost (per ISTQB)	Implementing and maintaining keywords is complex as scope grows; heavy for small systems	Needs proper test data management	Natural-language steps are complex to maintain; often misused as just a test format

Keyword-driven testing compared with related approaches, drawing on the ISTQB CTAL-TAE syllabus.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-301

Governing the catalog

Keep one owner for the keyword catalog; new keywords are proposed, reviewed and documented, not created ad hoc.
Write each keyword's purpose, arguments, outputs and preconditions where testers can find it.
Prefer adding an argument to an existing keyword only when it keeps the meaning; otherwise create a new keyword.
Retire keywords that are no longer used, and search tests before changing a keyword's behavior.
Use the same keyword names in manual test cases, so manual and automated tests share one vocabulary.

A governed keyword has a life cycle: proposed, reviewed, documented, and retired only after tests stop using it.

The Sign-Off Table · thesignofftable.com/academy/sap-tau-301

What would you do?

Maria wants to write regression variants herself. The automation team offers either access to the framework code or a keyword table template with a documented catalog. Which serves her best?

Hands-on lab · ACCELQ

Read your ACCELQ Scenario as a keyword table

An ACCELQ Scenario's Test Cases grid works like a keyword table: each step is a business keyword, each column one of its arguments, and each row a variant someone can add without touching the logic.

Practice on SAPUI5 Shopping Cart demo app (public, no login)

If you haven't set up ACCELQ yet, do the setup lab first. This lab reuses the Scenario from the lesson 2 lab.
Open the Scenario's Test Cases tab. The columns are grouped by step, so each group reads as a keyword with its arguments.
Add three rows, each with a category and product you can see in the demo. Double-click a cell to edit it, then click Save Changes.
Check the step names. If any reads like a technical keyword, such as Click Add, rename it to a business verb and object.
Make one composite keyword: a new Action Shop For Product that calls Open Category and then Add Product To Cart. Use it in a second Scenario, and keep composites rare.
Govern the catalog: open the Navigator, filter to Actions and search for Cart. Merge any near-duplicates and write down who owns the catalog.
Run the first Scenario. It runs once per Test Case, so expect three results.
Show the Test Cases grid to someone who knows the process and ask whether they could add a row unaided.

Done when Three Test Cases pass in one run, every step name reads as a business keyword, and the Navigator shows no duplicates. Keep the Test Report link.

Learn more in ACCELQ’s docs: Working with Test Cases in ACCELQ · Calling an Action inside another · Navigator

Start the free ACCELQ trial Matt Angerer, who runs The Sign-Off Table, works at ACCELQ. Disclosure

Key points

Keyword-driven tests are tables of keywords plus data, defined from the user's perspective; ISO/IEC/IEEE 29119-5 is the standard for the approach.
Business keywords map to business components; technical keywords stay inside the framework.
Keywords make tests readable and let analysts write them; they also suit manual testing.
The cost is keyword implementation and maintenance; govern the catalog to prevent duplicates.
Share one vocabulary across manual and automated tests.

A keyword test for SAP

Levels of keywords

Strengths and costs

Governing the catalog

Lesson check