How to Perform Keyword-Driven Testing in Modern Development Environments
As testing and development increasingly need to be accessible to non-technical stakeholders, keyword-driven testing offers a different way to structure your automation. It separates what the test is trying to accomplish from how the automation actually performs it, which can be incredibly valuable for modern QA teams. Keep reading to learn more about how keyword-driven testing works and what its advantages (and drawbacks) over other testing methods are.
What is Keyword-Driven Testing?
Keyword-driven testing is an approach to test automation where reusable keywords represent actions or operations within a test. Test cases are then built by arranging those keywords into a workflow (like building blocks), and sometimes providing additional parameters that tell each keyword what data or object to use. The real value of keyword-driven testing isn’t just that it makes syntax look easier and more legible — it’s in how it creates an abstraction layer between test design and automation implementation.
Take a suite with 75 tests that all need to authenticate through the same login workflow. Without reusable automation components, similar login logic may appear repeatedly throughout the suite. Using a keyword-driven structure, it enables all of those tests to simply call an action like Log In As User. This means that if the way authentication works changes later in the development process, the team can just update the underlying component instead of every single test script’s hardcoded logic.
Keyword-Driven Testing Examples
For example, instead of writing automation code directly into a login test, the test might contain:
|
Keyword |
Parameter |
|
Open Application |
Customer Portal |
|
Enter Username |
username@example.com |
|
Enter Password |
ValidPassword123 |
|
Click |
Sign In |
|
Verify Page |
Account Dashboard |
As you can see, each keyword represents an action whose technical implementation exists somewhere else in the automation framework. While this example uses relatively basic keyword actions, they can also represent higher-level business operations like Creating a New Customer.
Let’s take a look at a slightly more complex example — suppose a QA team is testing an online ordering app. One of the requirements states that a registered customer should be able to log in, add an available item to their cart, complete checkout, and see an order confirmation. With keyword-driven testing, this might look like:
|
Keyword |
Parameter 1 |
Parameter 2 |
|
Open Store |
Test Environment |
|
|
Log In |
customer_name |
valid_password |
|
Search Product |
Wireless Keyboard |
|
|
Add to Cart |
Wireless Keyboard |
|
|
Open Cart |
||
|
Checkout |
Standard Shipping |
|
|
Submit Order |
||
|
Verify Order Confirmation |
As mentioned above, this is easy to follow but can accommodate more complex actions at the same time. For example, the Add to Cart keyword might internally:
- Locate the specified product in search results
- Open its product description page
- Confirm that the product is available
- Locate the Add to Cart control
- Click it
- Verify that the cart count changed
Keyword-Driven Testing vs. Data-Driven Testing vs. Behavior-Driven Testing
Before we dive deeper into how keyword-driven testing works and why it can be beneficial to QA teams, it’s important to distinguish it from other common testing methods. Data-driven testing and behavior-driven testing (also called Behavior-Driven Development, or BDD) complement keyword-driven testing by solving for different problems:
|
Testing Type |
Description |
Advantages |
|
Keyword-Driven Testing |
Build tests from reusable actions or business operations. |
Improves test readability Promotes reuse Simplifies maintenance Makes automation more accessible |
|
Run the same test logic against multiple sets of data. |
Efficiently expands test coverage Reduces duplicate test logic Makes test data easier to manage Supports broader scenario testing |
|
|
Describe desired behavior via examples that stakeholders can understand. |
Facilitates shared understanding Improves cross-functional collaboration Makes requirements easier to understand Connects requirements and testing |
Keyword-Driven Testing Framework: How to Perform it
Although keyword-driven testing is relatively simple at the test case level, a reliable framework needs more than just creating a list of commands. As we’ve discussed, behind readable keywords like Log In, Create Customer, and Add to Cart are reusable automation logic, application objects, test data, and validation rules that enable those commands to execute (and do so consistently).
Understanding Components
Starting with the components of the framework, let’s outline each of the key pieces below:
- Keywords: Reusable actions that form the “vocabulary” of the framework.
- Test Cases/Workflows: Arrange keywords in the order needed to exercise a particular workflow.
- Objects & Object Repositories: Elements like buttons, forms, menus, and input fields that keywords interact with.
- Parameters & Test Data: Arguments that adjust the data and reduce the need for keyword variations like Search for Laptop and Search for Keyboard.
- Execution Logic: Keywords must map to execution logic that knows how to perform the requested operation.
- Assertions & Reporting: Act as checkpoints to determine whether the app behaved as expected by comparing actuals with expected results.
1. Identify Workflows to Automate
Start with the application workflows that the test suite needs to cover. Going back to our e-commerce example above, this might include customer login, product search, adding products to a cart, checkout, order cancelation, and account updates. We recommend looking for actions that occur repeatedly across multiple scenarios, because recurring operations are typically strong candidates for reusable components like keywords. The goal at this stage isn’t to automate every click – it’s to identify the most impactful operations.
2. Define Your Keywords
Next, translate those recurring operations into a consistent keyword vocabulary. This could look like Log In to authenticate a customer, Search Product to search for a specified item, Complete Checkout to complete the purchase workflow, and so on. We recommend that you align with your team on keyword names that clearly communicate intent. This will improve understanding and efficiency to scale modularity across your test suite.
3. Implement Automation Behind Each Keyword
Once your vocabulary has been defined, connect each keyword to the actions required to perform it. We used Add to Cart as an example earlier in this article, so let’s look at something like Log In. The actions tied to this keyword might:
- Navigate to the login page
- Locate the username field
- Enter the username
- Locate the password field
- Enter the password
- Click the login button
- Wait for the account dashboard
Platforms like Rapise make it easy to build these interactions and store associated objects in the object repository. Rapise also supports Modules and Page Objects that can encapsulate shared functionality.
4. Add Parameters & Test Data
We recommend you avoid hardcoding values into reusable keywords wherever different tests may require different inputs. In other words, instead of “Log In as Standard Customer,” create “Log in [Username] [Password].” Now, the same automation can support many users and scenarios simply by changing the parameters. This is also where keyword-driven testing and data-driven testing can complement each other because the keywords define reusable actions while the data changes between executions.
5. Assemble Keywords into Test Cases
Now that your reusable keywords are defined and in place, it’s time to construct tests by arranging them into complete workflows. For instance, a test might look like this: Log In > Search Product > Add to Cart > Complete Checkout > Cancel Order. The test case now communicates what it’s testing without exposing every locator, command, wait, or implementation detail underneath it.
6. Add Assertions for Expected Results
As we mentioned earlier, automation shouldn’t just perform actions — it needs checkpoints (assertions with expected outputs) to validate that those actions produce the expected result. If the test case we outlined in the previous section didn’t end with Cancel Order and instead ended with Verify Order Confirmation, that keyword might need to confirm that a confirmation message appears, an order number was generated, and the order appears in the customer’s account.
7. Execute, Review, and Maintain
Now that your tests are ready to run, execute them and review failures at both the test case and keyword level. Effective automated testing solutions like Rapise should have reporting that shows which action failed, which data was used, and what result was produced. In fact, Rapise automatically produces these execution reports so teams can troubleshoot failed tests. Ongoing maintenance of your test suite is also critical, especially as the application evolves and changes. New recurring workflows can become new keywords, existing keywords can be refined, and overly specific keywords can be consolidated into more reusable components.
Advantages of Automated Keyword-Driven Testing
Now that you know how KDT works and how you can implement it, let’s clearly detail why you would want to incorporate it in the form of concrete benefits:
- Reduces repetitive automation work: Teams can create common actions once as reusable keywords instead of rebuilding the same sequences across individual tests.
- Makes large test suites more modular: Higher-level keywords can combine multiple lower-level operations into reusable components, making it easier to organize complex automation.
- Makes tests easier to understand at a glance: Descriptive actions such as Create Customer, Submit Order, or Verify Invoice communicate test intent without exposing every underlying command.
- Reduces dependence on programming skills for test creation: Once the underlying keyword library exists, testers can assemble workflows using predefined actions rather than writing every test from scratch in a programming language.
- Can improve collaboration between technical and non-technical testers: Business-level terminology gives analysts, domain experts, and manual testers a clearer view of what automated tests are doing while automation specialists maintain the implementation underneath.
Pitfalls to Avoid
However, it’s important to keep in mind several considerations that might hamper your testing efforts:
- Creating too many highly specific keywords: Keywords such as Log In As John Smith or Search For Product 123 limit reuse. Prefer parameterized keywords such as Log In [User] or Search Product [Product] when the operation itself is reusable. Keyword arguments are specifically designed to make reusable actions adaptable to different inputs.
- Making keywords accept too many parameters: Excessive arguments make keywords difficult to understand and use correctly. The Robot Framework style guide recommends trying to limit keywords to five arguments and considering lists or dictionaries when more data is needed.
- Building only low-level UI keywords: A suite dominated by Click, Type, Wait, and Select may technically be keyword-driven but still expose most of the application's implementation details. Higher-level keywords can abstract these sequences into meaningful reusable actions.
- Allowing duplicate keywords to spread across the framework: If teams independently create similar implementations, the primary reuse advantage of KDT starts to disappear. Shared resource files, modules, libraries, and common framework components help centralize reusable behavior.
- Neglecting framework governance as the library grows: Without agreed naming, documentation, ownership, and organization, a large keyword catalog can become difficult for testers to navigate. We recommend descriptive naming and keyword documentation, particularly for larger projects.
When to Use Keyword-Driven Testing
From our experience working with partners across dozens of industries, the scenarios that reward keyword-driven testing the most include:
- When many test cases repeat the same workflows: Login, navigation, customer creation, checkout, approvals, and similar recurring processes are strong candidates for reusable keywords or modules.
- When the same workflows need to run with different test data: Parameterized keywords pair naturally with data-driven testing, allowing teams to reuse both actions and workflows across many input combinations.
- When QA teams include both technical and non-technical testers: KDT can allow automation engineers to develop reusable implementation logic while other testers assemble and understand tests through higher-level actions.
- When test suites are becoming difficult to maintain as individual scripts: Moving common actions, application objects, configuration, and shared logic into reusable framework components can reduce duplication and create clearer boundaries between test scenarios and implementation details.
How Rapise Enhances Automated Testing Across All Frameworks
Keyword-driven testing can make automation more reusable, readable, and accessible, but it shouldn’t be your only method of testing. Modern QA teams need to combine testing approaches to validate different areas and aspects of applications and systems. Rapise is designed to give teams flexibility across these approaches rather than requiring every automated test to follow the same structure.
The core of this capability is our Rapise Visual Language (RVL), which is a scriptless, table-based approach to creating automated tests. RVL was inspired by both keyword-driven and data-driven testing methodologies, enabling teams to represent test actions, objects, parameters, variables, data, assertions, loops, and other automation logic in a structured visual format.
Rapise also doesn’t force teams to choose between low-code automation and traditional scripting. Instead, testers can do both — scriptless automation with RVL and scripted tests with JavaScript for more complex logic and customization. For teams adopting keyword-driven testing (or any other modern test automation frameworks), Rapise is the ideal solution to provide advanced capabilities without limiting access to automation engineers. Get a demo of Rapise or sign up for a free 30-day trial today!
