Keyword Driven Testing Framework with Example
⚡ Smart Summary
Keyword Driven Testing separates test logic from automation code by mapping plain-language keywords to reusable functions, so testers design, maintain, and scale automated suites through spreadsheets instead of writing scripts for every individual test case.

What is Keyword Driven Testing?
Keyword Driven Testing is a scripting technique that uses data files to contain the keywords related to the application being tested. These keywords describe the set of actions that is required to perform a specific step.
A keyword-driven test consists of high and low-level keywords, including the keyword arguments, which is composed to describe the action of a test case. It is also called table-driven testing or action word based testing.
The Keyword Driven Framework is the functional automation testing framework built around that technique. It divides test cases into four different parts in order to separate coding from test cases and test steps for better automation: the test steps themselves, the objects those steps act on, the actions performed on those objects, and the data supplied to them.
In Keyword Driven Testing, you first identify a set of keywords and then associate an action (or function) related to these keywords. Here, every testing action like opening or closing of browser, mouse click, keystrokes, etc. is described by a keyword such as openbrowser, click, Typtext and so on.
The diagram below shows two ordinary business actions turning into reusable keywords. For Example:
- login to “guru99” website – Keyword “login” will be used in our automation framework, to the test the login function or action associated with it.
- logout to “guru99” website— Keyword “logout” will be used in our automation framework, to test the logout function or action associated with it.
You will see more examples further in the article. The pattern never changes: one business action, one keyword, one function.
Example of Keywords
The glossary below lists typical keywords for a banking application and the business action each one triggers.
| Keywords | Description |
|---|---|
| Login | Login to guru99 bank demo site |
| Emails | Send Email |
| logouts | Log out from guru99 bank demo site |
| Notifications | Find unread notifications |
💡 Tip: Name keywords after the business action, not the technical step. “Login” survives a page redesign; “ClickBlueButton” does not.
Components of a Keyword Driven Framework
Knowing what a keyword is only takes you halfway. To create a Keyword driven framework you assemble a small set of files, each owning one concern.
- Excel Sheet – Identify the keywords and store them in an Excel sheet, one row per test step.
- Function Library – Consists of the functions for the business flows (the login button for any website). When a test is executed, it reads the keyword from the Excel sheet and calls the functions accordingly.
- Data Sheets – Store the test data used in the application, so one keyword runs against many inputs.
- Object Repository – Holds the locators for every element the keywords touch, so a changed locator is edited in one place.
- Test Scripts – You can have test scripts for each manual Test Case or a single driver script.
- Driver Script – Walks the Excel sheet row by row, resolves each keyword against the function library, and records the outcome.
- Automation Tool – Executes the resolved commands against the application and supplies the reporting layer.
Together these seven pieces form a complete test automation framework. Why choose this design?
Why do Keyword Driven Testing
In Software Engineering, Keyword Driven Testing is done due to following reason
- Common components handled by standard library
- Using this approach tests can be written in a more abstract manner
- High degree of reusability
- The detail of the script is hidden from the users
- Users don’t have to use the scripting languages
- The test is concise, maintainable and flexible
Because the keyword layer absorbs application changes, a large regression testing suite stays green by editing a handful of functions instead of hundreds of scripts. That reasoning shapes how the approach is applied.
How to perform Keyword Driven Testing
Keyword Driven Testing can be done in both ways, manually as well as automated. But usually, it is used with automated testing.
The objective behind automating Keyword Driven Testing is
- It helps to reduce maintenance cost
- Avoids duplicated specifications
- Greater reuse of function scripting
- Better testing support and portability
- Achieve more testing with less or same effort
With Keyword Driven Testing, you can create simple functional tests in the earlier stages of development, testing the application piece-by-piece. The simplest way to compose a keyword driven test is to record it. After recording, the test can be modified and customized as per the requirement.
Each keyword needs to be linked with at least one command, test script or function, which implements the actions related to that keyword.
When test cases are executed, keywords are interpreted by a test library, which is called by a test automation framework.
The major activities involved in Keyword Driven Testing are
- Step 1) Identifying low level as well as high-level keywords
- Step 2) Implementing the keywords as executable
- Step 3) Creating test cases
- Step 4) Creating the driver scripts
- Step 5) Executing the automation test scripts
Steps 1 and 2 are one-time design work; steps 3 to 5 repeat every sprint, as the samples below show.
Sample test cases
These three scenarios reuse the same keywords defined earlier.
- TC_01: Login to guru99 demo site, find out how many transactions is carried out today
- TC_02: Login to guru99 demo site, send an email to one of your customer and then logout
- TC_03: Login to guru99 demo site and check for any notification received
Written as a keyword table, TC_02 becomes six rows any tester can read or reorder without opening the code:
| Step | Keyword | Argument | Expected result |
|---|---|---|---|
| 1 | openbrowser | Chrome | Browser session starts |
| 2 | Login | mngr123 / demopass | Manager home page shown |
| 3 | Emails | customer@example.com | Compose window opens |
| 4 | click | Send | “Mail sent” appears |
| 5 | logouts | – | Session closed |
| 6 | closebrowser | – | Browser released |
Swapping the argument in step 3 turns the same six rows into a different test, which is where test data management pays off.
Advantages of Keyword Driven Testing
- It allows functional testers to plan test automation before the application is ready
- Tests can be developed without programming knowledge
- It is not dependent on a specific programming language or tool
- Compatible with any automation tools available in the market
These benefits explain why Keyword Driven Testing suits long-lived automated testing suites. The costs matter too.
Limitations of Keyword Driven Testing
The abstraction that makes keyword driven tests readable also makes them expensive to build. Before the first test runs, somebody must identify the keywords, implement each as a function, wire up the object repository, and write the driver script. On a small project that setup costs more than scripting the tests directly.
Maintenance is the second cost. The library is shared by every test, so one careless edit breaks the whole suite. Libraries also sprawl: teams add near-duplicates such as “Login”, “SignIn” and “DoLogin”.
- High initial investment – framework design and keyword implementation precede any test run.
- Reduced flexibility – testers express only what existing keywords allow, so unusual scenarios need development.
- Awkward for complex logic – branching and loops resist flat table rows.
- Skills are still required – the keyword layer is code-free, the function library is not.
⚠️ Warning: Review the keyword library every release and delete unused entries. An uncontrolled vocabulary is the single most common reason keyword driven frameworks are abandoned.
These trade-offs shape the comparison below.
Keyword Driven vs Data Driven vs Hybrid Framework
Keyword driven and data driven testing solve different problems. A data driven framework varies the inputs of a fixed script; a keyword driven framework varies the steps. The table adds the hybrid model most enterprise teams adopt.
| Aspect | Keyword Driven Framework | Data Driven Framework | Hybrid Framework |
|---|---|---|---|
| What is externalised | Test steps and actions | Test data only | Both steps and data |
| Planning effort | Extensive and precise | Limited to data and scripts | Highest |
| Maintenance | Easier, more abstraction layers | Harder, abstraction is thinner | Easiest at scale |
| Coding skill needed | Only for the function library | Required for every script | Required for the core layer |
| Can start before the build | Yes | No | Yes |
In practice the styles combine. A hybrid framework stores steps as keywords and inputs in data sheets, often over a Page Object Model. Choose keyword driven when many testers write tests, data driven when one flow needs many inputs, and hybrid when both apply.
Tools used for Keyword Driven Testing
Several tools are extensively used for Keyword Driven Testing, each interpreting the keyword table differently.
- HP QTP – ships with a built-in keyword view, so the sheet and the executable test are one artefact.
- Selenium – has no native keyword layer, so teams build the function library and driver script themselves.
- Robot Framework – an open-source engine designed around keywords, with tabular syntax and many ready-made keywords.
- TestNG – commonly used alongside Selenium to sequence keyword-mapped methods and generate reports.
Our list of automated testing tools covers licensing and platform support for each option.

