What is Keyword-Driven Testing?

Anushree Chatterjee

When it comes to automated testing, it’s a constant struggle to keep the focus on testing rather than the testing framework. Quite often, testers complain about the challenges associated with writing and maintaining lines of code for test automation. As we move into a fast, Agile-driven world where quality is everyone’s prerogative, having code for test scripts just slows down and hampers the QA process.

Many methodologies aim to make the process easier. One such approach is keyword-driven testing. Let’s understand this approach in detail.

Definition of keyword-driven testing

Keyword-driven testing is a testing methodology that separates the test design from the test execution. This allows testers to focus on what the tests are meant to do rather than how they are implemented. In this approach, test cases are written using a set of keywords that represent specific actions or operations, which are then interpreted by a test execution engine.

You can view keyword-driven testing, like using a recipe book to cook a dish. Just like a recipe outlines the steps to make a dish, a test case outlines the steps to perform a specific test. The ingredients needed for the dish correspond to the data required for the test. Each cooking technique (like “mix,” “bake,” or “chill”) acts like a keyword in the test case.

For instance:

• “Preheat Oven” = Open Browser
• “Mix Ingredients” = Input Username and Password
• “Bake for 30 Minutes” = Click Login
• “Check if Cake is Fluffy” = Verify Login Success

Benefits of keyword-driven testing

Keyword-driven testing offers many benefits:

Improved test case maintainability

Maintaining test cases becomes easier because of:

• Centralized repository: Keywords and their corresponding actions are stored in a centralized repository which makes it easier to manage and update.
• Reduced manual effort: When changes occur in the application, testers can simply update the keyword definitions rather than modify individual test cases.

Increased test case reusability

Just like reusability is desirable in development, it is so in automated testing. With keyword-driven testing this becomes possible because of:

• Common language: Keywords provide a common language for describing test steps. This makes it easy for them to be reused across multiple test cases.
• Reduced redundancy: By reusing keywords testers can avoid creating duplicate test steps which saves time and effort.

Enhanced communication

Keywords offer a common language for all stakeholders to communicate in, giving rise to:

• Shared understanding: Keywords provide a shared vocabulary that can be used by testers, developers and business analysts to discuss test requirements and results.
• Improved collaboration: A common understanding of test steps facilitates better collaboration and communication among team members.

Simplified test automation

If test automation is easier, then more team members can participate in the process. A simpler process will also ensure that resources are not being drained through test automation. This becomes possible due to:

• Keyword-based scripting: Test automation tools can be configured to use keywords which makes it easier to create and maintain automated test scripts.
• Reduced scripting effort: By using keywords, testers can avoid writing complex scripts. This reduces the time and effort required for automation.

Improved test case quality

The quality of test cases generated is better with the keyword-driven approach due to:

• Standardization: Keyword-driven testing promotes standardization in test case design which leads to more consistent and reliable test results.
• Enhanced traceability: Keywords can be linked to requirements which makes it easier to trace test cases back to their original specifications.

Accelerated time-to-market

By adopting this approach of testing, you can ensure quicker deliveries since keyword-driven testing promotes:

• Faster test case creation: Keyword-driven testing can speed up the process of creating and executing test cases.
• Reduced testing cycle time: By improving test case efficiency and reusability, keyword-driven testing can help reduce the overall testing cycle time.

Components of keyword-driven testing

Based on the tools you use, the components may vary. However, the major components that comprise keyword-driven testing are:

Keyword library

• It is a collection of functions or methods that implement the actions represented by the keywords. Keywords are high-level commands that represent specific actions or operations in the test. Common keywords include “Open Browser,” “Click,” “Input,” “Verify,” and “Navigate To URL.”

Test data

• This data is required for executing test cases, often stored in external files (e.g., spreadsheets, databases). It is stored separately and is passed to keywords during execution to drive the test scenarios.

Driver script/Test execution engine

• It reads the test scripts, interprets the keywords and invokes the corresponding functions from the keyword library.

Object repository

• It refers to the file that stores locators for web elements. This repository is used by the automation tool.

Test scripts

• Test cases are constructed using keywords and their associated parameters. They are typically tabular, with each row representing a keyword and its parameters.

Testing framework

• The overall structure that supports keyword-driven testing and includes standards for organizing test scripts, managing test data and integrating with automation tools. It may include utilities for logging, reporting and maintaining test environments.

Here’s a sample test script:

Limitations of keyword-driven testing

Though keyword-driven testing might seem like an upgrade from coding test scripts, it is riddled with limitations.

• Time-consuming: Setting up the framework, defining keywords and creating the keyword library can require significant upfront effort and time.
• Maintenance overhead: As applications evolve, the keyword library and test cases may need frequent updates which can become cumbersome. Outdated keywords or test cases may lead to miscommunication and errors if not regularly reviewed. There is also a risk of creating duplicate or similar keywords, leading to confusion and a bloated keyword library.
• Learning curve for non-technical users: While keywords are intended to make testing accessible some non-technical users may still struggle to grasp the underlying concepts and structures.
• Performance overhead: In some cases the overhead of interpreting and executing keywords can impact the overall performance of the test execution.
• Limited data-driven capabilities: While keyword-driven testing can incorporate data-driven elements it might not provide the same level of flexibility and power as dedicated data-driven frameworks.
• Complexity for complex scenarios: Keyword-driven testing can become cumbersome for complex scenarios with intricate logic or decision-making. It might be challenging to represent complex operations using simple keywords.
• Limited flexibility: The flexibility of keyword-driven testing can be limited if the keywords are not defined comprehensively or if the test cases require actions that are not covered by the existing keywords.

Moving beyond keyword-driven testing

While keyword-driven testing offers a structured approach, it might not be sufficient for complex scenarios or teams seeking more advanced testing capabilities. Moreover, if you’re looking to make test automation easy for everyone, then there are better approaches out there that will help you achieve this.

• Data-driven testing: This approach emphasizes on separating test data from the test logic. Here test cases are designed to run with multiple data sets.
• BDD testing: BDD focuses on collaboration between developers, testers and non-technical stakeholders. Tests are defined in a natural language format like the Gherkin syntax (Given-When-Then) using scenarios.
• Scriptless automation: These tools allow users to create automated tests without writing code by often using drag-and-drop interfaces.
• AI-based testing: AI is used to come up with test cases based on certain user inputs. These types of tools also promote low test maintenance due to their AI-induced self-healing capabilities.

You needn’t worry about which of these approaches to go for. testRigor is one such tool that supports all the above approaches, giving you a holistic solution for automated testing.

Complete testing with testRigor

testRigor allows you to leverage the power of AI in test creation, execution and maintenance. If you’re someone who prefers testing through BDD, then testRigor will let you mention specifications in plain English with absolutely no coding. This is great for team members with or without programming experience. You can parametrize these English test cases and do data-driven testing as testRigor has built-in support for the same.

Along with simple English test creation, you can rely on testRigor’s generative AI feature to create test cases for you based on a comprehensive scenario description. Besides this, you can make use of the record-and-playback extension that will record the test steps in plain English while you execute the test case.

Over here, you need not worry about object repositories or driver scripts. Just write the test steps as you’d do for manual testing. In fact, testRigor’s smart engine looks at web elements like how a human would. So if you want the tool to click on the ‘login’ button, then just write the command click on "login".

With testRigor, you can write end-to-end, functional, API, UI, regression, and acceptance test cases across different platforms and browsers. You can even grow your testing ecosystem by integrating with various platforms and tools for CI/CD services, databases, infrastructure, and more.

Conclusion

Keyword-driven testing is a good way to abstract the code complexity involved in scripted automation testing. Transitioning beyond keyword-driven testing may provide the flexibility and depth needed to address modern testing challenges effectively. The choice of approach will depend on factors such as project requirements, team expertise and the complexity of the system under test. In many cases, a combination of these approaches can provide the most effective testing strategy.

“We spent so much time on maintenance when using Selenium, and we spend nearly zero time with maintenance using testRigor.”

Keith Powe VP Of Engineering - IDT