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

In our ongoing quest to pinpoint the most fitting Automation Framework for a particular test project and to categorize existing frameworks, let’s revisit an instance we discussed in the preceding QTP framework article where we generated a new Gmail account.

We initially designed a scenario to create a new account merely by recording and replaying the steps in sequence. Nevertheless, this method was discovered to be deficient in modularity, readability, and reusability. To rectify these inefficiencies, we fragmented the scenario into functions which can then be used as keywords in subsequent steps.

=> Click Here To Access The QTP Training Tutorials Series

Through this procedure, modularity, readability, and reusability were achieved, but we sought to make the program more resilient by enabling it to manage different sets of values without the need to change the script itself. At this point, the concept of data-driven testing is introduced.

Implementing the Data-Driven Automation Framework in QTP

This framework will be utilized to facilitate the creation of multiple Google user accounts.

Previously, we hardcoded the first name, last name, and user ID details into the script while creating an account. To accomplish data-driven testing, there must be a separation between the script and the data source.

Commonly, the data input could hail from several sources namely:

• MS Excel files
• Databases
• Text files
• XML files, etc.

Excel files are frequently employed as data sources in QTP due to the built-in datasheet for every action. The attached datasheet to the action or an external Excel file can be used. Essentially, a datasheet can be any applicable external file.

For instance, the following code needs to be modified for data-driven testing:

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"

Currently, all the data is hardcoded. Let’s examine how we can extract these values from a datasheet.

Access the expert view in QTP for the particular statement and click on the value column of the step.

The next window will appear:

Choose the parameter choice, designate a name for the parameter (this will correspond to the column title in the datasheet), and decide whether to use the universal or local sheet (universal sheet is accessible for all actions in a test, whilst the local sheet is tied to the current action).

QTP sets a default value for the “Name” field. The user may choose to stick with it or change it.

After clicking OK, a new column is instituted in the data table.

This is an example of a datasheet containing 3 sets of first names, last names, and account IDs:

Following the parameters setting, the code changes to this:

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)

To establish these 3 user IDs utilizing data from the datasheet, we require 3 iterations. Essentially, an iteration is a test run.

Once the data setup is complete, QTP should be directed as to how many times this script ought to run or the number of iterations required.

Here’s how one can do it: Visit File -> Settings and Run

In the above settings window, you can tailor the iteration properties as needed.

Alternatively, QTP can be instructed programmatically regarding the iterations. This method offers more control but necessitates programming prowess. The choice between these strategies depends on the comfort level of the tester.

The elements of a data-driven framework include:

1. Test script
2. Data files
3. Shared functional library (if applicable or can be a direct program)
4. Object repository (this element will be missing if descriptive programming was used to construct objects)

The test results will reflect a status of “Passed” or “Failed” for each test run.

In addition to the default data table, any standalone Excel file can serve as an input sheet.

Hybrid Framework

Previously, we utilized keywords (function names created by the user) and executed data-driven testing to generate different users concurrently. This is illustrative of a hybrid framework.

A hybrid framework is an amalgamation of two or more frameworks discussed previously. In my experience, no singular framework operates effectively for all projects, leading to a preference for hybrid frameworks.

Here are several significant points about frameworks:

• A framework should be interpreted as a solution that succeeded in a specific circumstance and not rigid rules that must be invariably maintained. It should be treated as a set of guidelines.
• There are possibly other frameworks in use that have been omitted from this conversation. We have emphasized the frameworks often employed.
• The terminology for frameworks might differ across applications, hence minor differences in names are expected.
• Generally, frameworks can be combined once a singular framework is inadequate in accomplishing all testing objectives.

Conclusion

We have rendered the concepts of frameworks to be easily understandable in this article.

If you encounter any framework-related problems that have not been covered in these articles, please bring them to our attention. We will endeavour to respond to your queries. Feel at ease to post your questions.

=> Follow This Link For The QTP Training Tutorials Series