Data Driven and Keyword Driven Test Automation managed by ISTQB Certified CTAL Experts

Posted in: ISTQB Advanced CTAL Exam Preparation

Data Driven & Keyword Driven Test Automation managed by ISTQB Certified CTAL Experts

Data-driven automation: This utilizes the skills of the Test Analyst and the Technical Test Analyst.

These automation techniques are used to reduce maintenance costs in the automation code and to allow the test analysts to create the actual test scenarios using the test scripts developed by the automator (usually a Technical Test Analyst).

Data-driven automation consists of two main parts, the data and the automation script that will use it. The data is usually maintained in tables or files that the automation script reads. The automation usually cycles through a set of preprogrammed commands and inserts the data from the table to actually conduct the test. The results of the test are then compared to another value in the table to verify correctness.

To illustrate the concept let us consider a script for Marathon that tests the ability to enter the sponsor amount for a runner. In this case, we would have a data table that contains the name of the runner, the amount of the sponsorship, and a resultant total sponsor amount. The script would pick up the name of the runner from the table and use that as input to the selection criteria. It would then verify

that the correct runner is presented on the sponsor amount input screen. If that runner is present, it would then insert the amount of the sponsorship from the table. If that runner is not present, the script would return an error that would be collected into the report for the overall test run. The script would then skip the remainder of the instructions that were dependent on finding that particular user. It would move down the table, get the next input name, and try again.When the sponsorship amount is entered, the script would check for any error messages and would check the actual against the expected outcome in the table. For example, if the amount was too large, we would expect to see an error to that effect. Once the amount is entered, the script would check the resultant screen and see if the total sponsor amount matched the value in the input table. If so, the test passes. If not, the test fails.

This is a simplistic example, but it shows how the script can be reused many times to check different conditions (runner not in the database, sponsor amount invalid, sponsor total too high, and so forth). This means that one automation script may be able to replace 100 test cases as it cycles through the table verifying different test conditions. The automator is responsible for building the flexible script that can handle the various input values (remember, input values will also include the expected results verification). The test analyst uses his domain expertise to create the data that will be used by the test script. The test analyst knows what should happen based on the various inputs. The automator doesn’t need to know the intricacies of the application, only the aspects that the script needs to know.

This provides the best use of the skill sets we have available and maximizes the automation contribution of both the Test Analyst and the Technical Test Analyst.

Let’s look at our previous example with our recorded login script. We already know that one won’t provide us with any flexibility and we won’t really know if it worked or not. How would it look if we made it data driven?

First we create a table (called Login-Data) of the data we want to feed through the script. In this case, we need the values for User Name, Password and the expected Message. By checking the message, we can verify if the script actually worked or not.

Test data for a login dialog

User Name	Password	Message
Amit	asdf55&st	Password unknown
Amit	asdf&st	Welcome!
RSunitha	Alias3	User unknown
TSunitha	Alias3	Welcome!

The script that uses this table is as under:

DataFile = Openfile(“Login-Data”)

Read DataFile.LoginRec // read the first “LoginRec” data record in the file

For each LoginRec in DataFile

Verify (MessageBox.Text = LoginRec.Message)

Read DataFile.Login // read next data record

End loop

This one script lets us cycle through as many entries as we create in the input data file. If someone changes the program so that it displays a pop-up box that welcomes the user rather than just displaying a message, we change it in one place-this script-and all the tests continue to work. In the recorded script, we would have had a separate script for each set of values we wanted to test and would have to change the message to the pop-up box handling in each script. When we get into thousands of sets of data, this becomes a significant effort!

Keyword-Driven Automation: This is sometimes called action-word-driven automation.

Keyword-driven automation takes this concept one step further. In the case of keyword-driven, in addition to supplying the data, the input table supplies the action or keyword to be used for the test. This keyword is then linked to a script that will be executed by the automation.

For example, an airline check-in system might give the user the ability to change their seat, request on upgrade, or just confirm their check-in. We might see a keyword table similar to the one shown in following example of a keyword table for a check-in application

Action/Key- word	Confirmation Number	Result	Enter Seat	Enter Credit Card	Result
Change Seat	123456	Display “Found”	18A		Display “Seat Assigned 18A”
Confirm	234567	Display “Found”			Display “Check in Complete”
Upgrade	345678	Display “Found”		1111-1111- 1111-1111	Display “Upgrade Complete”
Upgrade	123aaa	Display “Not Found”

Data-driven and keyword- driven automation are sometimes called table driven automation

When the automation code sees the action to Change Seat, it knows to call the Change Seat script(s).

Each keyword or action word event must include a way to verify if it worked. In this case, we are depending on the display of the proper message to the user. While this certainly wouldn’t be a very safe test, rest assured that it’s just being used for a simple example (and to fit on the page). As you can see though, this similar set of information is used for a variety of tests.

As with data-driven automation, our goal is to maximize our use of the automator’s programming skills and our test analyst’s domain knowledge. This level of insulation does not require the automator to have in-depth knowledge of the software under test. The resultant automation will be very flexible and easier to maintain.

For example, if we change the format of the number from a six- to a seven-digit number, only the table needs to change-the automation script is unchanged.

Full Study Material for ISTQB Test Analyst & Technical Test Analyst Exam

0 0 votes

Article Rating