Keyword-driven testing
Keyword-driven testing is a software test automation approach in which test cases are written as sequences of action keywords, such as open page, enter text and verify title, each of which a framework maps to code that performs it. The test logic lives in readable tables, so people who do not program can write test cases once the keywords exist.
The longer version
A test is a row or a list: a keyword, the element it acts on, and the data to use. The framework holds a library of keywords, each implemented once in code by an engineer, and an interpreter reads the table and calls them in order. Robot Framework is a well-known open-source example, and the same pattern appears in several commercial tools. The vocabulary is the contract between those who design tests and those who automate them.
The benefit is separation of roles. A domain expert or manual tester can assemble new cases from existing keywords without touching code, while an automation engineer builds new keywords when the application needs one. A change in the way a page works is fixed in the one keyword that drives it, and every test using that keyword is repaired at once.
Keyword-driven tests combine well with a data-driven layer: the keywords describe the steps, and a table of inputs runs the same sequence many times. The step vocabulary also doubles as documentation of what the product does, which a test report can read back in plain language when a run fails.
The layer itself needs care. The keyword library has to be designed, documented and kept coherent, and a vocabulary that grows without discipline turns into hundreds of near-duplicates that nobody can search. A failure surfaces in a table row while its cause lies in code a step removed, so debugging takes longer, and for a small suite run by developers plain scripts are often simpler.
Common questions
What is keyword-driven testing?
An automation approach where each test is a sequence of keywords describing actions, with the data they use, and a framework translates every keyword into executable code. Tests read like instructions, so people who cannot program can write them while engineers maintain the code behind the keywords.
What is the difference between keyword-driven and data-driven testing?
Keyword-driven testing abstracts the steps into reusable action keywords, and data-driven testing abstracts the inputs into a table that one script runs over. They solve different problems, and many frameworks combine them, with keywords for the steps and a data table for the values.
What are examples of keyword-driven testing tools?
Robot Framework is the best-known open-source option and ships with a library of standard keywords. Several commercial automation tools offer a similar table-based layer on top of their drivers, and teams also build their own keyword layer over Selenium or Playwright using a spreadsheet or a plain-text format.
What are the disadvantages of keyword-driven testing?
Building and governing the keyword library takes up-front effort, and an undisciplined vocabulary becomes duplicated and hard to search. Failures are harder to trace because they appear in a table while the cause sits in code underneath. Small suites often cost more to run this way than as plain scripts.
Who writes keyword-driven tests?
Manual testers and domain experts write the test tables from existing keywords, and automation engineers write the code behind each keyword. That division is the point of the approach: the people who know the business rules can express them without learning a programming language.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.