What is Keyword-Driven Testing?

Keyword-driven testing is a test automation approach where test steps are represented as keywords (action words) in a table, abstracting the underlying automation code so that non-technical testers can design and maintain tests.

Start a Free Mock Interview

Free to start · 7-day trial on paid plans

IN DEPTH

In depth.

In a keyword-driven framework, each keyword maps to a reusable function. A test might read: Open Browser > Navigate To "https://app.com/login" > Enter Text "email_field" "user@test.com" > Click "submit_btn" > Verify Text "Welcome." The keywords are defined once in a library, and tests are composed by combining them in spreadsheets or structured files.

This approach bridges the gap between technical automation engineers and domain-expert testers who may not code. The automation team builds and maintains the keyword library, while QA analysts create test scenarios using familiar vocabulary. Tools like Robot Framework are built around this paradigm.

A keyword-driven framework typically has four layers. The bottom layer is the driver script that reads the keyword table and dispatches each action. The next layer is the keyword library, which defines what each keyword does in code (Click, Enter Text, Verify Element). Above that sits an object repository or locator file mapping logical names like "submit_btn" to actual selectors. The top layer is the test data, the spreadsheet or YAML file where testers compose scenarios from keywords and arguments.

Keyword-driven testing differs from data-driven testing in what is abstracted. Data-driven testing keeps the test logic in code and only varies the inputs across rows of a data table. Keyword-driven testing abstracts the actions themselves, so the test scenario lives entirely outside code. Hybrid frameworks combine both: keyword steps composed into scenarios, with each scenario parameterised across data rows.

The trade-off is flexibility versus abstraction. Keyword-driven tests are easy to read and maintain for standard workflows but become awkward for complex logic, conditional branching, or dynamic data. They also require investment in framework engineering up front and rely on disciplined keyword naming so the library does not balloon into hundreds of near-duplicates. Most mature automation teams use keyword-driven testing for high-level smoke and regression tests while reserving script-based testing with Playwright or Selenium for complex flows that demand programmatic control.

WHY IT MATTERS

Why interviewers ask about this.

Interviewers ask about keyword-driven testing to evaluate your understanding of framework architectures and your ability to make testing accessible to non-technical team members. Senior candidates are expected to discuss when keyword-driven testing pays off versus when it adds overhead.

EXAMPLE

Example scenario.

A QA analyst creates a keyword-driven test for order placement: Open_Browser, Login "admin" "password", Search_Product "Widget A", Add_To_Cart, Checkout, Verify_Order_Confirmation. The analyst writes no code. The SDET maintains the keyword implementations and adds new keywords as features are built.

TIP

Interview tip.

Compare keyword-driven testing with data-driven testing and explain when you would choose each. Mentioning Robot Framework as a concrete tool implementation strengthens your answer, and acknowledging the up-front engineering cost shows seniority.

FAQ

Frequently asked questions.

What is a keyword-driven framework with an example?

A keyword-driven framework is an automation framework where test cases are written as sequences of action words instead of raw code. For example, a login test might read: Open_Browser, Navigate "/login", Enter_Text "email" "user@test.com", Enter_Text "password" "secret", Click "submit", Verify_Text "Welcome". Each keyword maps to a reusable function that handles the actual browser interaction. Robot Framework is the most common implementation.

What is the difference between keyword-driven and data-driven testing?

Keyword-driven testing abstracts the actions of a test (Click, Enter_Text, Verify) so non-coders can compose test cases from a library of action words. Data-driven testing keeps the test logic in code and only varies the inputs across many rows of a data table, useful for running the same scenario with different combinations of data. Hybrid frameworks combine both: keyword scenarios parameterised across data rows.

When should you use keyword-driven testing?

Keyword-driven testing is most valuable when domain experts or manual testers need to author and maintain tests without learning a programming language, when test scenarios share a small set of repeating actions across many flows, and when stakeholders want test cases to read as living documentation. Avoid it when tests need complex branching, dynamic data manipulation, or when the team has the engineering capacity to maintain a code-based framework instead.

What are the advantages and disadvantages of keyword-driven testing?

Advantages: tests are readable by non-technical stakeholders, the keyword library forces reuse, and changes to UI flow only require updating the keyword definition once. Disadvantages: significant up-front investment to build the framework, awkward for complex logic or conditional flows, and risk of keyword sprawl where dozens of near-duplicate keywords accumulate without governance. Teams should weigh whether the readability win outweighs the engineering cost.

Which tools support keyword-driven testing?

Robot Framework is the dominant open-source implementation, with a rich ecosystem of libraries (SeleniumLibrary, RequestsLibrary, AppiumLibrary). TestComplete and Katalon Studio also offer keyword-driven test design. Selenium and Playwright are not keyword-driven by default but can be wrapped in a custom keyword layer if a team wants the abstraction without leaving their existing toolchain.