Keyword-driven testing

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Keyword-driven testing, also known as table-driven testing or action word based testing, is a software testing methodology suitable for both manual and automated testing. This method separates the documentation of test cases -including the data to use- from the prescription of the way the test cases are executed. As a result it separates the test creation process into two distinct stages: a design and development stage, and an execution stage.


This methodology uses keywords (or action words) to symbolize a functionality to be tested, such as Enter Client. The keyword Enter Client is defined as the set of actions that must be executed to enter a new client in the database. Its keyword documentation would contain:

  • the starting state of the system under test (SUT)
  • the window or menu to start from
  • the keys or mouse clicks to get to the correct data entry window
  • the names of the fields to find and which arguments to enter
  • the actions to perform in case additional dialogs pop up (like confirmations)
  • the button to click to submit
  • an assertion about what the state of the SUT should be after completion of the actions

Keyword-driven testing syntax lists test cases using a table format (see example below). The first column (column A) holds the keyword, Enter Client, which is the functionality being tested. Then the remaining columns, B-E, contain the data needed to execute the keyword: Name, Address, Postcode and City.

. Name Address Postcode City
Enter Client Jane Smith 6 High Street SE25 6EP London

To enter another client, the tester would create another row in the table with Enter Client as the keyword and the new client's data in the following columns. There is no need to relist all the actions included.


Keyword-driven testing reduces the sensitivity to maintenance caused by changes in the SUT. If screen layouts change or the system is migrated to another OS hardly any changes have to be made to the test cases: the changes will be made to the keyword documentation, one document for every keyword, no matter how many times the keyword is used in test cases. Also, due to the very detailed description of the way of executing the keyword (in the keyword documentation) the test can be performed by almost anyone. Thus keyword-driven testing can be used for both manual testing and automated testing.[1]


The keyword-driven testing methodology divides test process execution into several stages:

  1. Test preparation: intake test basis etc.
  2. Test design: analysis of test basis, test case design, test data design.
  3. Manual test execution: manual execution of the test cases using keyword documentation as execution guideline.
  4. Automation of test execution: creation of automated script that perform actions according to the keyword documentation.
  5. Automated test execution.


A Keyword or Action Word is a defined combination of actions on a test object which describes how test lines must be executed. An action word contains arguments and is defined by a test analyst.

Automation of the test execution[edit]

The implementation stage differs depending on the tool or framework. Often, automation engineers implement a framework that provides keywords like “check” and “enter”.[1] Testers or test designers (who do not need to know how to program) write test cases based on the keywords defined in the planning stage that have been implemented by the engineers. The test is executed using a driver that reads the keywords and executes the corresponding code.

Other methodologies use an all-in-one implementation stage. Instead of separating the tasks of test design and test engineering, the test design is the test automation. Keywords, such as “edit” or “check” are created using tools in which the necessary code has already been written. This removes the necessity for extra engineers in the test process, because the implementation for the keywords is already a part of the tool. Examples include GUIdancer and QTP.


  • Maintenance is low in the long run:
    • Test cases are concise
    • Test cases are readable for the stake holders
    • Test cases easy to modify
    • New test cases can reuse existing keywords more easily
  • Keyword re-use across multiple test cases
  • Not dependent on a specific tool or programming language
  • Division of Labor
    • Test case construction needs stronger domain expertise - lesser tool / programming skills
    • Keyword implementation requires stronger tool/programming skill - with relatively lower domain skill
  • Abstraction of Layers


  • Longer Time to Market (as compared to manual testing or record and replay technique)
  • Moderately high learning curve initially

See also[edit]


  1. ^ a b Faught, Danny R. (November 2004). "Keyword-Driven Testing". Sticky Minds. Software Quality Engineering. Retrieved September 12, 2012. 

External links[edit]