Action and Data Driven Test Scripts

Automated tests can be classified into one of the following types:

Capture/Replay the test script does not iterate, and all actions and data values are hard-coded inside the script.
Data-driven the test script iterates once for each set of related data as extracted from an external file or spreadsheet. The actions to perform are the same for each set of data, i.e. the actions are hard-coded in the script.
Action and Data-driven both the actions that the script must perform and the data to be acted upon are stored in an external file or spreadsheet. The script has been designed to interpret each action and call the appropriate logic to process the data associated with each action.

The advantages of action and data-driven test scripts

Action codes are used to reduce the number of test scripts required to test an application and to make the addition of new test cases relatively easy. Think of the set of action codes as a special programming language created just for the application being tested. The alternative is for testers to use a low-level scripting language, such as TSL or Test Scripting Language. To use this language, you need specialized knowledge because TSL has hundreds of commands or actions, none of which look like the commands the tester enters into the screens of the application that is being tested. By creating a language that relates to the application, the tester is allowed to focus on the application testing without getting bogged down in TSL.

How do the actions and test data relate to each other?

Testing not only involves entering transaction codes and choosing actions from menus. It also involves entering data, such as the FIRM code, the ORDER_QUANTITY and so on. Automated testing is no different. For every Action Code, there is usually one or more data items required. For example, for a MARKET_QUOTE action code, the automated testing system expects that the tester will provide the BID price and the ASK price. These input data items are also called “parameters”. That is why the headings in the data tables are generalized, e.g. P1, P2, etc.

How does the tester enter actions and data?

All Action codes and data are entered into an EXCEL table. The top row of the spreadsheet contains the column headings, which are the same for every spreadsheet and every test. The data table will usually contain more than one test case. A single test case may require just one row in the data table, but often requires several for a complex sequence of actions. A sample table is shown in Appendix 1.

How can the tester enter actions and data into a table?

An Excel macro can be built to display popup messages that explain every data value required for each different action code. Every time a new action code is added, the macro should be updated.

What does a WinRunner script look like?

One approach that works well is to create tests that consist mostly of user-defined functions. One main function (I call it the DO_ALL function) reads the data table and interpret the actions and the data in the data table, calling other functions as required. It consists mostly of a large “case” statement (the “switch” function in WinRunner) that evaluates the data in the ACTION column of the data table and launches other user-defined functions as appropriate. The only “main” script in a test is the small “launching” test that passes the name of the data table to DO_ALL.

Sample Data Table
TEST_GROUP	TEST_CASE	ACTION	P1	P2	P3	P4
Quick Open Display	13	FIND_PAGE	-	R!	-	-
		LOCK_VOID	-	-	R	L
		CHECK_QOP	-	-	N	-
		ENTER_QUOTE	-	-	0	1+
		CHECK_QOP	-	-	Y	-

Quick Open Display	15	FIND_PAGE	-	R!	-	-
		ENTER_ORDER	-	-	-	M
		LOCK_VOID	-	-	R	L
		ENTER_QUOTE	-	-	0	1+
		CHECK_QOP	-	-	Y	-