Keyword tests are limited in their ability to
do certain complicated tasks. A best practice is to avoid keyword
tests when:1.
The task to be automated involves testing items that
don’t have any related GUI (e.g., database stored procedures, Web Service
API’s, etc.)2.
The task to be automated involves manipulating the
data or strings that will be used in data entry but does not itself involve
data entry (e.g., formatting an SQL statement, formatting a date for input,
concatenating strings, etc). You can
write separate Script code to perform the manipulations for use within a
keyword test but the keyword test itself should not be used for doing the
manipulation.3.
The task involves data driven testing where only a
select number of records from the data table are needed rather than the entire
table.4.
The task involves creating a function that will be
used for providing data to other tests.5.
The task involves using complex objects as parameters
rather than simple strings or integers (e.g., operating on objects within the
AUT where the object is passed in as a parameter)6.
The task involves logic that changes dependant upon
multiple variable values such as would be used in a JScript “switch” statement.7.
The task requires complex error handling for
determining multiple paths for execution.
Keyword tests are good candidates for tests
when:1.
The task involves UI manipulation for the purpose of
executing a specifically defined task (e.g., logging in to an application,
closing an application, navigating to pre determined pages, etc)2.
The task involves a repetitive loop over a set of data
for repeated entry into a web form3.
The task has a low risk of dependency on data
conditions for determining workflow.
The task consists primarily of UI interaction with
checkpoints with minimal manipulation of the data before the interaction
