QTP Tutorial #18 – Data Driven and Hybrid Frameworks Explained with QTP Examples

We are working our way through figuring out how to derive at an automation framework that works best for a certain testing project and also are defining certain frameworks that already exist.
The example that we were using in the previous QTP framework article was creating a new Gmail account.
To start with, we coded the creating of a new account scenario just by recording and play back in a linear fashion. Seeing how it lacked in modularity, readability and reusability we broke it down into functions that would be referenced as keywords moving forward.
We did achieve modularity, readability and reusability through this method but we needed to make the program even more robust so that it can take different sets of values without having to modify the script itself.
That is exactly what we are going to achieve by data driving the tests.

Data Driven automation framework using QTP

Creating multiple Google user accounts is the task we will try to accomplish using this framework.
In the example earlier, we hard coded the first name, last name, user id details etc. into our code while trying to create an account. We will have to separate the code from the data if we have to achieve data driving aspect for this script.
The data should come from a source that is not the program itself.
Typically the data input can be anything:

1. MS Excel files
2. Data base
3. Text files
4. XML files….etc.

Excel files are the ones that get used most often. The very fact that each action in QTP comes integrated with a data sheet of its own explains why that’s so.
You can use one or more data sources for a single script. The excel sheet that comes with the action can be used or you can use an external excel sheet too. Basically a data sheet can be any relevant external file.
For example:
This is the code that we need to data drive:

1 2 3

Browser("Gmail: Email from Google").Page("GoogleAccounts").WebEdit("FirstName").Set "swati" Browser("Gmail: Email from Google").Page("Google Accounts").WebEdit("LastName").Set "s" Browser("Gmail: Email from Google").Page("Google Accounts").WebEdit("GmailAddress").Set "test"

All the data right now is hardcoded. Let us now see how we can take these values from the datasheet.
Go to the expert view for the statement in QTP and click on the value column for a step. The following window open up:

Select the parameter option, choose a name for the parameter (this will be the column name in the data sheet) and choose whether you are going to use the global sheet or local sheet (global sheet is available for all the actions in a test, but local sheet is specific to the current action).
For the ‘Name’ field in the screen, QTP provides a default value. The user has an option to keep it the same or change it.

On clicking OK, a new column gets created in the datatable.

This is how the data sheet that contains 3 sets of firstname, last name and account id looks like:

Once parameterized, the code looks like:

1 2 3

Browser("Gmail: Email from Google").Page("Google Accounts").WebEdit("FirstName").Set DataTable("G_First_Name", dtGlobalSheet) Browser("Gmail: Email from Google").Page("Google Accounts").WebEdit("LastName").Set DataTable("G_Last_Name", dtGlobalSheet) Browser("Gmail: Email from Google").Page("Google Accounts").WebEdit("GmailAddress").Set DataTable("gmail_address", dtGlobalSheet)

If we have to create these 3 user IDs with the data in the sheets, we need to have 3 iterations. Iteration is nothing but a test run.
Once the data is set up we will have to instruct QTP on how many times this code needs to run, or how many iterations.
This is how we do it: Go to File->Settings and Run  (click on image to enlarge)


In the above screen set the iteration properties as required.
Alternately, you can instruct QTP about the iterations programmatically. As always, this allows more control and also more programming skills. So it is really up to the comfort level of the tester to choose either of these methods.
The components in a data driven framework are:

1. Test script
2. Data files
3. Shared Functional library(if exists or could be a linear program)
4. Object repository (Again, this component will not exist if descriptive programming was used to create objects)

The test results will show a “Passed’ or ‘Failed’ status for each test run.
Apart from the data table that comes by default, we can use any external excel file as an input sheet.

Hybrid framework

In the example above you used keywords (names of the functions that the user has created) and have data driven the test to make sure that different users are created at the same time. This is nothing but a hybrid framework.
The combination of any two or more frameworks that we have discussed so far is a hybrid framework.
In my experience, no one framework works effectively for a certain project. Hybrid framework is what gets used most often.
Few important points about frameworks:

1. Framework is just a solution that worked best in a certain situation but should not be construed as a set of rules to be definitely followed. It should be seen more like guidelines.
2. There might be many other frameworks in use, we have only listed and explained the common ones
3. Nomenclature – Different people address their frameworks with different names. So if the names are slightly different from one application to another, it is normal.
4. Most of the frameworks can be used in conjunction with one another when any one of them cannot provide an all round solution to your testing goals.

Conclusion:

For the sake of easy understanding we have really simplified the concepts of framework here. If you have any framework related issues that you are facing that is not covered in these articles, do let us know. We will most definitely try to answer your questions. Please feel free to post your questions.