---
title: 'Keyword-Driven Testing: Examples, Robot Framework and Limits (2026)'
description: Keyword Driven Testing and how you can use it with Selenium, using Robot
  Framework.
source_url:
  html: https://testingbot.com/software-testing-questions/what-is-keyword-driven-testing
  md: https://testingbot.com/software-testing-questions/what-is-keyword-driven-testing.md
---

# What is Keyword Driven Testing (KDT)?

Last updated August 31, 2026

- [![Share on Facebook](https://static.addtoany.com/buttons/facebook.svg) ](https://www.addtoany.com/add_to/facebook?linkurl=https%3A%2F%2Ftestingbot.com%2Fsoftware-testing-questions%2Fwhat-is-keyword-driven-testing.md&linkname= "Share on Facebook")
- [![Share on Twitter](https://static.addtoany.com/buttons/twitter.svg) ](https://www.addtoany.com/add_to/twitter?linkurl=https%3A%2F%2Ftestingbot.com%2Fsoftware-testing-questions%2Fwhat-is-keyword-driven-testing.md&linkname= "Share on Twitter")
- [![Share on LinkedIn](https://static.addtoany.com/buttons/linkedin.svg) ](https://www.addtoany.com/add_to/linkedin?linkurl=https%3A%2F%2Ftestingbot.com%2Fsoftware-testing-questions%2Fwhat-is-keyword-driven-testing.md&linkname= "Share on LinkedIn")
- [![Share on HackerNews](https://static.addtoany.com/buttons/y18.svg) ](https://www.addtoany.com/add_to/hacker_news?linkurl=https%3A%2F%2Ftestingbot.com%2Fsoftware-testing-questions%2Fwhat-is-keyword-driven-testing.md&linkname= "Share on HackerNews")

Keyword-Driven Testing (KDT) is a software testing approach that uses a table or a spreadsheet to know which actions should be performed during testing. You would typically use descriptive keywords when creating test cases, which then correspond with an action.

This type of testing is easier to understand for non-technical users, such as QA people or business/marketing colleagues, as it does not require the knowledge of computer programming.

## Implementing Keyword-Driven Testing with Selenium

Selenium is a widely used open-source framework for automating web browsers. In the example below, we'll show you how you can start using Keyword-Driven Testing with Selenium.

### Define keywords

First, let's come up with a set of keywords that represent actions or operations you want to perform on your website. This could be keywords such as `openBrowser`, `navigateTo`, `click`, `verifyText`, etc. If you're familiar with Selenium IDE, this looks a lot like the syntax Selenium IDE uses.

### Create Keyword Test Cases

You can now develop test cases using these keywords in a tabular format. Each row in the table represents a test step, with columns specifying the keyword, the target element and any optional parameters.

```
| Keyword | Target Element | Parameters |
|--------------|---------------------|---------------------|
| openBrowser | chrome | |
| navigateTo | https://testingbot.com | |
| click | loginButton | |
| verifyText | welcomeMessage | Welcome, User! |
```

### Implement Keyword Functions

Create functions or methods that correspond to each keyword. These functions encapsulate the Selenium WebDriver API calls which required to execute the specified action on the (remote) browser.

```java
public void click(String targetElement) {
    driver.findElement(By.id(targetElement)).click();
}

public void verifyText(String targetElement, String expectedText) {
    String actualText = driver.findElement(By.id(targetElement)).getText();
    Assert.assertEquals(actualText, expectedText);
}
```

Now you can execute the test with a test runner that is capable of reading and interpreting the table. A popular test framework that allows you to do this is [Robot Framework](https://testingbot.com/support/web-automate/selenium/robotframework).

### The same test in Robot Framework

Robot Framework is the most widely used keyword-driven runner, and it is worth seeing the same test expressed in it, because the keyword table stops being a diagram and becomes the actual test file:

```
***Settings***
Library SeleniumLibrary

***Test Cases***
Login shows a welcome message
    Open Browser https://testingbot.com chrome
    Click Element id:loginButton
    Element Text Should Be id:welcomeMessage Welcome, User!
    [Teardown] Close Browser
```

Every capitalised phrase is a keyword. `Open Browser` and `Click Element` come from SeleniumLibrary, and you add your own on top:

```
***Keywords***
Log In As
    [Arguments] ${username} ${password}
    Input Text id:username ${username}
    Input Text id:password ${password}
    Click Element id:loginButton
```

That second block is the whole point of the approach. `Log In As` is now a sentence a non-programmer can use in a test, and when the login form changes you fix it in one place.

## Advantages of Keyword-Driven Testing

There are several advantages in using Keyword driven testing.

- **Abstraction of Technical Details**  

Non-technical team members can contribute to test case creation without knowledge of programming or test automation frameworks.

- **Improved Maintainability**  

Changes in the application's UI or functionality can be accommodated with minimal impact on test cases, simply by updating the keyword functions.

- **Reusable Test Components**  

Keyword functions can be reused across multiple test cases. This greatly improves the efficiency during test script development and maintenance.

- **Enhanced Collaboration**  

Collaboration between technical and non-technical team members is improve. This in turn leads to a more inclusive testing process.

## When keyword-driven testing is the wrong choice

The advantages above are real, and they are not free. The costs show up later than the benefits, which is why this approach is often adopted enthusiastically and abandoned quietly.

- **Somebody still has to write the keywords.** The abstraction does not remove the programming, it moves it. You need a developer to build and maintain the keyword library, and that person becomes a bottleneck the moment the application changes.
- **Keyword libraries sprawl.** Without discipline you end up with `clickButton`, `clickElement` and `clickIfVisible` doing almost the same thing, and nobody can remember which to use.
- **Debugging is indirect.** A failure reports at the keyword level, so tracing it means reading through the implementation anyway, which is exactly what the non-technical author cannot do.
- **Poor fit for complex logic.** Conditionals, loops and computed values are awkward in a table. When a test needs real branching, the table format fights you and the workarounds are worse than code.
- **Small teams rarely benefit.** If everyone writing tests can already write code, the abstraction layer is pure overhead.

It pays off where there is a genuine split between people who know what the product should do and people who know how to automate it, and where the same actions recur across many test cases.

## What are the differences between Data Driven And Keyword Driven Frameworks?

Data-Driven Testing (DDT) and Keyword-Driven Testing (KDT) are both popular frameworks in test automation. They do however serve different purposes and emphasise on different aspects of testing. Below are some of the differences between these two types of frameworks.

 Data-Driven Testing (DDT) | Keyword-Driven Testing (KDT) || The primary focus of Data-Driven Testing is to separate test data from test scripts. It allows testers to execute the same test script with different sets of input data. This is particularly useful for validating different scenarios and variations of the same functionality. | Keyword-Driven Testing aims to abstract the test script's technical details and make the testing process more accessible to non-technical stakeholders. It involves creating tests using descriptive keywords, where each keyword corresponds to a specific action. |
| In DDT, test data is typically stored in external data sources like Excel sheets, CSV files or databases. The test script reads input data from these sources during test execution. | While data can be utilized in Keyword-Driven Testing, the emphasis is on using keywords to describe actions, rather than managing extensive sets of input data. The handling of data is not the primary focus. |
| Test scripts in DDT are designed to be generic and reusable. They are often parameterised to accept input data. The same script can be executed with multiple data sets. | Test scripts in KDT are structured around keywords, where each keyword represents a specific action. Test cases are constructed using these keywords. This makes the test script more readable. |
| DDT is generally more focused on technical aspects and might require programming skills to manage and manipulate test data effectively. | KDT is designed to involve non-technical stakeholders, such as business analysts or domain experts, in the testing process. Test cases are constructed using descriptive keywords, which makes it easier for non-programmers to help when creating and maintaining tests. |

## Is keyword-driven testing the same as BDD?

No, though they look similar because both produce readable test cases. BDD, in tools such as Cucumber, describes behaviour from the user's point of view in Given/When/Then sentences, and its purpose is a shared conversation about requirements. Keyword-driven testing describes actions, and its purpose is reuse and maintainability. A BDD step definition and a keyword implementation are close cousins in code, but a Gherkin scenario is meant to be read by a product owner, while a keyword table is meant to be assembled by a tester.

> Once the keyword library exists, the same table runs anywhere your keywords can drive a browser. TestingBot provides a grid of real browsers and devices for Selenium and Robot Framework suites, so a keyword-driven test written once runs across Chrome, Firefox, Safari and Edge in parallel. See [running Robot Framework on TestingBot](https://testingbot.com/support/web-automate/selenium/robotframework).

- [![Share on Facebook](https://static.addtoany.com/buttons/facebook.svg) ](https://www.addtoany.com/add_to/facebook?linkurl=https%3A%2F%2Ftestingbot.com%2Fsoftware-testing-questions%2Fwhat-is-keyword-driven-testing.md&linkname=)
- [![Share on Twitter](https://static.addtoany.com/buttons/twitter.svg) ](https://www.addtoany.com/add_to/twitter?linkurl=https%3A%2F%2Ftestingbot.com%2Fsoftware-testing-questions%2Fwhat-is-keyword-driven-testing.md&linkname=)
- [![Share on Linkedin](https://static.addtoany.com/buttons/linkedin.svg) ](https://www.addtoany.com/add_to/linkedin?linkurl=https%3A%2F%2Ftestingbot.com%2Fsoftware-testing-questions%2Fwhat-is-keyword-driven-testing.md&linkname=)
- [![Share on Hacker News](https://static.addtoany.com/buttons/y18.svg) ](https://www.addtoany.com/add_to/hacker_news?linkurl=https%3A%2F%2Ftestingbot.com%2Fsoftware-testing-questions%2Fwhat-is-keyword-driven-testing.md&linkname=)

 ![TestingBot Logo](https://testingbot.com/assets/logo-head-2f7f08db4ac9c4a3b1a784047410f8a4ece708e7e9f10ed16e20fdd8310f8de3.svg)

## Sign up for a Free Trial

Start testing your apps with TestingBot.

No credit card required.

[Start Free Trial](https://testingbot.com/users/sign_up)

## Other Questions

### [What is Chrome for Testing?](https://testingbot.com/software-testing-questions/what-is-chrome-for-testing "What is Chrome for Testing?")

### [Why should I use Chromium for Testing?](https://testingbot.com/software-testing-questions/what-is-chromium "Why should I use Chromium for Testing?")

### [You can run APK Android files on Windows](https://testingbot.com/software-testing-questions/how-to-run-an-apk-on-windows "You can run APK Android files on Windows")

### [15 Selenium Best Practices for Reliable Tests](https://testingbot.com/software-testing-questions/what-are-some-best-practices-for-using-selenium-in-testing "15 Selenium Best Practices for Reliable Tests")

### [Reasons why a website might look different](https://testingbot.com/software-testing-questions/why-does-my-website-look-different-on-different-browsers "Reasons why a website might look different")

### [Learn about TestNG Listeners](https://testingbot.com/software-testing-questions/what-are-testng-listeners "Learn about TestNG Listeners")
