Framework 4: Keyword-Driven Testing

This requires the development of data tables and keywords, independent of the test automation tool used to execute them and the test script code that "drives" the application-under-test and the data. Keyword-driven tests look very similar to manual test cases. In a keyword-driven test, the functionality of the application-under-test is documented in a table as well as in step-by-step instructions for each test. In this method, the entire process is data-driven, including functionality.

 

 Example

In order to open a window, the following table is devised, and it can be used for any other application, just it requires just changing the window name.

 

Test Table for Opening a Window

Window	Control	Action	Arguments
Window Name	Menu	Click	File, Open
Window Name	Menu	Click	Close
Window Name	Pushbutton	Click	Folder Name
Window Name		Verify	Results

Once creating the test tables, a driver script or a set of scripts is written that reads in each step executes the step based on the keyword contained the Action field, performs error checking, and logs any relevant information.

 Merits of keyword driven testing

The merits of the Keyword Driven Testing are as follows,

Ø      The Detail Test Plan can be written in Spreadsheet format containing all input and verification data.

Ø      If "utility" scripts can be created by someone proficient in the automated tool’s Scripting language prior to the Detail Test Plan being written, then the tester can use the Automated Test Tool immediately via the "spreadsheet-input" method, without needing to learn the Scripting language.

Ø      The tester need only learn the "Key Words" required, and the specific format to use within the Test Plan. This allows the tester to be productive with the test tool very quickly, and allows more extensive training in the test tool to be scheduled at a more convenient time.

  Demerits of keyword driven testing

The demerits of the Keyword Driven Testing are as follows,

Ø      Development of "customized" (Application-Specific) Functions and Utilities requires proficiency in the tool’s Scripting language. (Note that this is also true for any method)

Ø      If application requires more than a few "customized" Utilities, this will require the tester to learn a number of "Key Words" and special formats. This can be time-consuming, and may have an initial impact on Test Plan Development. Once the testers get used to this, however, the time required to produce a test case is greatly improved.