Keyword Test Case Design

Introduction

The hallmark of keyword test design is extensive reuse of keywords to build libraries of focused test cases to test the full scope of functionality for a software package. In the special case of automated testing, more powerful, effective and efficient frameworks extensively reuse the keyword implementation code and other code at lower levels.

Keyword driven testing is a higher abstraction and typically an automation of tests designed, implemented and executed for validation of software functionality. Often the tests are first conceived, documented and run as a series of steps in manual test cases and then transformed to automation for regression testing but the very long history of this approach does not itself preclude a change to using keyword test cases for either manual or automated testing of the first releases. In a context of planned automation testing, the inefficiency of transformation from manual tests generated in one format to automated test cases in another framework can be obviated by just starting with keyword test cases. The keyword test cases can either be driven manually as planned, manually as planned before future automation implementation or manually as necessitated when automation simply has not been completed for whatever reason.

The keyword test case approach includes three major activity divisions and three roles could separately take responsibility for each based on resource skills and strengths but separation of labor is not mandatory. Keyword test case design requires Application Under Test (AUT) domain expertise and strength in test methodology. Keyword implementation may require technical strength and programming skill in the detail of the AUT interface. The skill level required will depend on the complication / atypical implementation of the AUT. And keyword test execution requires understanding of test aggregation, analysis and problem reporting, resolution and liaison.

Keyword Test Case Design

Organization of AUT Functionality and Related Tests

Success of the test design process and subsequent maintenance is at least in part dependent on organization of AUT functionality to be tested and the tests themselves. A common solution is a tree structure with nodes, here called partitions, that divide the features of the application into logical areas of focus or scope, that represents the testable features at the lowest levels of the tree, and that hold the test cases at that level. Each partition is named, described and may be prioritized.

Test Case Design

A test case is designed as a sequence of keywords including the keyword arguments to validate specific AUT functionality. The Test Designer adds keyword argument values within the test case to drive specific action. Once implemented and executed, a Keyword Test Case will navigate and input values to the AUT to create conditions of the AUT functionality (i.e. set up the validation) and then validate that the AUT produces the expected result. Often the Designer adds more keywords (and values) to return the AUT to the initial condition (i.e. tear down after the validation).

Here is an example hotel reservation entry-validation-and-cancel test case:

Keywords	Argument 1	Argument 2	Argument 3	Argument 4	Argument 5
Hotel Reservation System Start
	Country	City	Checkin Date	Checkout Date	Rate Type
Hotel Reservation Enter	USA	California	&Date("mm/dd/yy", 5)	&Date("mm/dd/yy", 7)	AAA
	Hotel Name
Hotel Select	Harbor View Palace
	Prefix	First Name	Last Name	Address1	Address2
Guest Details Enter	Mr	Aditya	Kuram	Plot #176, TMC Mhills	Secunderabad AP India
	BedType	Smoking Room	Airlines	Flight No	Credit Card Type
Special Details Enter	One King Size	Yes	Air India	AI123	Dinners Club
	Hotel Name	Reservation Id	Customer Name	Address1	City
Validate Reservation Confirmation	Harbor View Palace	&Keep(ResId)	Mr. Aditya Kuram	Plot #176, TMC Mhills	Secunderabad AP India
	CCNo	Resid
Reservation Cancel	123	&ResId
Hotel Reservation System Close

Keyword Design

Keywords are the basic, reusable building blocks for keyword test design. Keywords define actions that drive or get information from application objects. Keywords are defined with an action-descriptive keyword name (e.g. Hotel Reservation System Start, Hotel Reservation Enter, Hotel Select, Reservation Confirmation Validate, or Hotel Reservation Close) and keyword argument names (e.g. Country, City, CheckinDate, CheckoutDate). Each keyword (for GUI applications) is associated with one (or sometimes more) GUI windows. Each keyword argument may be associated with a window object, like a list-box or a button. Reuse of Keywords ensures rapid test development and easy maintenance.

Keywords are created by Test Designers in anticipation of usage within Keyword Test Cases or, more commonly, the keywords are created on-demand, as needed when the Keyword Test Case is being implemented. Keyword argument names are created with the Keyword. Keyword argument values, on the other hand, are entered into test cases, as described above, to serve the purpose of each test case. The values are text and can be used to be

• An explicit argument value
• An expression including
• Variables
• Functions
• Combinations of variables and explicit values

Also note that not only are keywords the basic, reusable building blocks for keyword test design, but they are also the basic components of test automation implementation. Run time test execution is called keyword by keyword.

Data Tables

For some tests, the tester needs to execute the test case repeatedly using different values for each iteration. This is enabled with a Data Table. The test case keyword argument values use variables. The Data Table is populated with values associated with the variables used in the test case. The test case will execute as many times as there are records in the Data Table.

Data Tables consist of Records and Columns:

• Records – Collections of values used in each iteration of the Test Case
• Columns – The columns headers are the variable names and the data below are the values associated with each variable in the test case iterations.

Keyword Implementation

Although Keyword Test Case Design, described above, and Test Set Execution, described below, can apply to either manual or automated tests, this section, Keyword Implementation, applies only to automated tests.

AUT Object Identification and Naming

Keywords and keyword arguments interact with the AUT windows and objects like list-boxes and buttons. Each of the windows and objects are uniquely identified within the operating system. Although they have a long list of attributes, generally only a few are required to differentiate one object from all others active during test execution. So, if the few attribute values of each window and each object are mapped to a unique object name, then the processing of the tests can interact with the objects, by name using a default method for the object type or some other method determined by the testers.

Association of Keyword Arguments and AUT Objects

Given a defined keyword including its keyword name and named arguments and given a map of windows and objects uniquely identified by name, the keyword can drive AUT action only if the keyword is tied to a named window and the keyword arguments are tied to named objects. The association must also include the method to be used for each of the keyword arguments. Usually the method is the default for a standard object type but on the other hand the object may be unusual or even if it is a standard object, the testers may want to interact with the object using a custom method.

Association of Keywords to Pre-Existing Execution code

The implementation of keywords may take absolutely no additional coding. With typical AUT implementations, the code, here called a template, can be common for many keywords. Templates can pre-exist, either built into the framework or created within a project to be reused for many keywords. There may be a handful of templates that each serve different purposes like value entry or value validation or some other variant needed within the project for test navigation, set up, validation or tear down. So, the keyword implementation is then simply achieved by association of the keyword to a template.

The keyword argument processing described above is called from the template. Templates typically include more than calls to keyword argument processing. Code may also include: checks to see that the AUT is ready for interaction; common navigation before and/or after keyword argument processing; error handling; or additional functions and calls. The template code can be quite modest or as extensive as needed. In any case, the template serves as common code to implement many keywords.

Facility to Address AUT Complexity

However, sometimes AUT complexity requires more code for special circumstances. Some keyword implementation may be quite unique and so require code for only that one keyword. That complex keyword might start life as a copy of a template but then be modified for the unique circumstance or it may be much more complex. The complex keyword, like a template, would typically provide checks, error handling, navigation, and keyword argument processing.

Some AUT complexity may be in objects commonly used within the AUT. Custom object code written as a method to deal with the complexity can be called from templates, usually, or from complex keywords in processing of the keyword arguments.

The framework also enables libraries of other common functions related to custom objects, complex keywords, or project templates.

Test Set Execution

Aggregate and Reuse Test Cases for Each Major Test Purpose

Keyword test cases can be reused extensively. The intent of each test case is to validate some functionality of the AUT and to always yield the same result. However, each test case may be used many times within test sets of different scope or purpose. A test set may be used for a smoke test, for example, or a much more complex functional test that may run for days, or a system test, or an acceptance test.

Run Manual Tests

As described above, test cases are built from keywords that have meaningful, action descriptive keyword names, with argument names that tie to AUT objects like list-boxes and buttons (most often defined by captions, legends, or other useful identifying text) and test case keyword argument values that are applied to the AUT or compared to AUT displayed values. The keyword test cases are based on definitions that are meaningful to people not just to machines. So, a useful framework also provides facility to capture results and provide reports from manual execution.

Execute Automated Tests

Automation is built on the Keyword Implementation, as described above, and requires another level level of code. A test case processing engine reads (otherwise people friendly) test case keywords and keyword argument values to programmatically and efficiently drive the AUT and report results.