Keyword Driven Framework

Keyword-driven testing, also known as table-driven testing or action-word testing, is

a software testing methodology for automated testing that separates the test creation process
into two distinct stages: a Planning Stage, and an Implementation Stage.

The keyword-driven testing methodology divides test creation into two stages:-

 Planning Stage
 Implementation Stage
Planning Stage
Examples of keywords*

 A simple keyword (one action on one object), e.g. entering a username into a textfield.

Object Action Data

Textfield (username) Enter text <username>

 A more complex keyword (a combination of other keywords in a meaningful unit), e.g.

logging in.

Object Action Data

Textfield (domain) Enter text <domain>

Textfield (username) Enter text <username>

Textfield (password) Enter text <password>

Button (login) Click One left click

Implementation Stage
The implementation stage differs depending on the tool or framework used. Often, automation
engineers implement a framework that provides keywords like “check” and “enter” [1]. Testers or
test designers (who don’t have 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. Tools such as GUIdancer and Worksoft Certify use
this approach.

Suggested Approach1:
1) Identify the list of objects of the Application and most frequently used set of
operations performed on them
2) Spy those objects to identify the native class of the tool and also find out native methods of
the tool for those objects
3) List out most frequently used operations/methods performed on different classes of the
objects
4) Classify the methods listed in step3 to the keywords
5) Maintain 3 excel sheets as below
   i) Testdriver-> an excel sheet which contains list of test cases to execute between start and
end keywords 
  ii) Testcase-> an excel sheet which contains keywords/actions as well as object name(the
alias defined in step iii) 
iii) Objects-> an excel sheet which has list of objects and properties which can be arrived by
spying on the application, for each row of an object given an alias, so that it can be referenced
by the test case excel sheet
6)  Write a main function which iterates through the Testdriver excel sheet, which has reference
to testcase excel sheet and objects excel sheet .For each test case it places calls to functions
as below
func1: iterates through Objects excel sheet and builds a hashmap/dictonary of the object and its
properties.Basically buids a keyvalue pair
func2: iterates through which TestCase excel sheet which has switch case on keywords, each
case statements intern calls a method defined for the keyword
7) Each method of keywords should have a detailed switch case on the object types, which in
turn has a code to perform operations on AUT

Advantages of Suggested Approach1:

1) No need to  have advanced knowledge in Automation tool
2) Consistency of the script development is achieved across the project
3) Easier to maintain scripts
4) Easier to maintain test data
5) Faster development of scripts
6)  Easier to schedule  the scripts with out any test management tool
7) Can be used across all applications,with little modifications to keywords. Provided the
automation tool supports record and play back on the Applications

DisAdvantages:
1) It restricts individual learning on tool
2) Little bit tough to debug as there is no code except keywords in it
3) Need to remind keywords and there usage
4) Little bit tough to handle conditional execution of scripts,alternative is write code in a
functions and call the function in test case  excel sheet using predefined keyword

Data Driven Framework

Data-driven testing is a term used in the testing of computer software for the creation of re-
usable test logic to reduce maintenance and improve test coverage. It is a methodology used
in test automation where test scripts are executed and verified based on the data values stored
in one or more central data sources or databases. Anything that has a potential to change (also
called "Variability" and includes such as environment, end points, test data and locations, etc),
is separated out from the test logic (scripts) and moved into an 'external asset'. This can be a
configuration or test dataset. More data can later be added or the configuration changed to
reuse the same test logic and execute multiple data scenarios.

Overview 

Data-driven testing is the creation of interacting test scripts together with their related data
results in a framework used for the methodology. In this framework, variables are used for both
input values and output verification values: navigation through the program, reading of the data
sources, and logging of test status and information are all coded in the test script. The logic
executed in the script is dictated by the data values.

When to use?
If an application has too many screens which needs lot of input from user go for data driven
framework.

Suggested Approach :
Step 1) Maintain test data for each screen of the ui in separate excel sheet, maintain a separate
row of data for each test case and data for each test case should refer to the same row of all the
sheets.
Step 2) Write a separate function for each screen which retrieves values from excel sheet and
inputs data in to Application
Step3) In Main script, insert a calls to all the functions written in step2, initializing the rownumber
of the excel sheet so that all functions gets  data from the same row of different sheets
Demonstration of Suggested Approach with example:
If there is a manual test case which has validation on ui or calculation at the screen 7 for
example
1) Write a new main script, initialize row number to the row in excel sheet which maintains data
needed for execution of test case.
2) Assuming that you have written individual function for each screen which gets data from
different sheets, put the function calls as below

call func_screen1 
call func_screen2
call func_screen3
call func_screen4
call func_screen5
call func_screen6 

Write code for the screen 7 to perform verification on screen 7.

 Note:Don't put any validations in the functions apart from getting data from excel and inputting
in to screens.

Advantages of using the Approach:

1)   Automation team need not know the functionality of complete application

2)  Even a starter in the team who has experience in tool, can quickly start working on the
scripts
3)  Faster development of scripts