If you are using some older version of UFT or QTP in your projects, then it would be good to have a look through this article so that you get to know the new features that are available with UFT 12.53. There is a good chance that you might find some features which are useful in your project, thereby helping you decide if you want to switch to the newer version of the tool.

Let’s now have a look at the new features in UFT 12.53 –

Enhanced Mobile testing

This version of UFT supports enhanced functionality for both native and hybrid mobile apps. Now, you can:

• a) Configure devices and applications for your tests directly from the new Mobile Center wizard
• b) Test non-packaged apps. This means you no longer need to package apps to upload them to Mobile Center
• c) Test mobile web apps using the device’s native browser – Safari for iOS devices, and Chrome for Android devices

New Docker activities for API tests

UFT now provides new Docker activities which enable you to perform remote actions on your containerized Docker applications.Use these new activities to:

• a) Download an image of the Docker container that contains your application
• b) Run an image containing the application
• c) Stop the container currently running the test

You can also test the application from the Docker container using standard UFT activities

OData protocol support for API tests

Now you can use UFT to test your OData REST services:

• a) Import the OData service as a REST service. You can import a service from a file or from a URL
• b) Construct a test using the service’s resources and methods

UFT runs the test just the same as any other REST service test

Configure Chrome Emulator devices

You can now configure and add devices for your Chrome Emulator by manually editing the Chrome emulator configuration XML

Run UFT tests from Amazon Web Services Marketplace

Now you can use AWS to access a system that contains the latest version of UFT pre-installed on multiple combinations of operation systems and browsers. Doing this also enables you to pay per use of UFT as needed

Support for Chromium Embedded Framework controls

You can now use UFT to test applications containing Chrome embedded controls, including Java CEF and Adobe CEP

Synthetic data generation for BPT tests

Now you can use the BPT Test Combinations Generator to create synthetic data for your test runs instead of creating all possible parameter values manually. In the Test Combinations Generator, select a parameter to automatically generate its values. Then select the parameter type and format. UFT uses built-in dictionaries to automatically populate the list of possible values with the generated data

UI Automation updates

UFT’s UI Automation support enables UFT to recognize objects in any application that has implemented the Microsoft Windows UI Automation Framework. This is especially helpful when UFT’s current technology support is not sufficient for your testing needs. In UFT 12.53, support has been added for:

• a) Switching between regular Spy and Learn modes while spying and learning objects instead of selecting a mode beforehand
• b) Setting the default Spy and Learn mode to UI Automation
• c) Enhancing your tests using new UI Automation test object methods, native methods, and object identification properties

Web Accessibility toolkit updates

UFT supports the Web Accessibility toolkit to recognize objects that use the HTML role property. The Web Accessibility toolkit is used to create digital content that is accessible to people with disabilities. In UFT 12.53, Web Accessibility toolkit support has been added for:

• a) All Web 2.0 toolkits
• b) Web-based add-ins
• c) Testing Mobile browsers
• d) Testing the Chrome emulator

Additionally, new test object methods and properties have been added so you can give greater depth to your tests.

New technology and framework support

This version of UFT includes the following new supported technologies and frameworks:

• a) Updated support for the latest versions of Firefox and Chrome
• b) Angular JS 1.2/1.4
• c) Autopass License Server version 9.1
• d) DevExpress WPF (via the UI Automation Add-in)
• e) Hummingbird 14 Terminal Emulator
• f) Infragistics WPF and WinForms (via the UI Automation Add-in)
• g) Microfocus WebToHost 6.70 Terminal Emulator
• h) Microfocus WebToHost 6.80 Terminal Emulator
• i) MS Dynamix AX 2012 (via the UI Automation Add-in)
• j) NWBC 5.0/6.0
• k) QT5 QTQuick (via the UI Automation Add-in)
• l) QT 5.3 widgets compiled by Visual Studio
• m) SAP Ariba
• n) SAP Concur
• o) SAP FieldGlass
• p) SAP GUI 7.40
• q) TCPLink 3.50-01

This was all about the new features that you will find in UFT 12.53. Did you find anything useful which will make you switch to the latest version of UFT?

If you want to download the latest version of UFT, then please check out this link – Download UFT 12.53

The post UFT 12.53 – New Features appeared first on XX.

1. Use VBScript SendKeys to simulate keypress at regular intervals

Copy the below code in a text file and save it with a .vbs extension

Dim durationInMins
Set obj = CreateObject("WScript.Shell")

'Capture the input from user
durationInMins = InputBox ("Enter time (in minutes) for which machine needs to remain unlocked" & vbCrLf & vbCrLf & "Enter 0 for indefinite time","Enter Duration")

If durationInMins > 0 Then
	'Run For loop for the duration specified by the user
	For i=1 to durationInMins
		WScript.Sleep (60*1000)
		obj.SendKeys ("{CAPSLOCK 2}")
	Next
ElseIf durationInMins = 0 Then
	'Run indefinite Do loop
	Do
		WScript.Sleep (60*1000)
		obj.SendKeys ("{CAPSLOCK 2}")
	Loop
End If

When you open this VBScript file in your machine, it will display a popup where you will need to specify the time (in minutes) for which Windows needs to remain unlocked. Enter 0 if you want this utility to run indefinitely. Entering a specific time limit rather than 0 is useful in scenarios where you don’t want the machine to keep running unnecessarily.

For example, consider a scenario where you want to execute a nightly batch run. And you know, by previous experience, that the UFT would take around 2-3 hours to complete the batch execution. In such a case, it will be good to specify the time in the alert box as 180 or 200, so that the machine comes to normal mode after this time duration and gets locked or shutdown.

How this code works

This code simply uses VBScript SendKeys method to simulate keyboard key press every one minute; thereby preventing windows from getting locked. Here we are using CAPS LOCK key to simulate the key press, using the code – SendKeys (“{CAPSLOCK 2}”).

You would have noticed the number 2 next to CAPSLOCK. This means that the CAPSLOCK key is pressed twice in very quick succession. This makes sure that CAPSLOCK remains in the same state and doesn’t interfere in your work in any way.

There are many other flavors of this code, in which people use different keys such as SCROLLLOCK, NUMLOCK, F15 etc. All these work fine without any issues and you can use any of these if you would want to modify the code.

2. Using 3rd party software

There are many 3rd party software (many with source code), which simulate keypress or mouse movements to keep your machine unlocked. Couple of them which I have used in the past are –

Mouse Jiggler – This software works by jiggling the mouse pointer back and forth

Caffeine – Another useful utility which simulates F15 keypress to prevent windows getting locked

3. Plug and Use USB devices

While searching on the internet, I came across these USB devices which create constant mouse activity so your computer won’t go idle. You can search on Amazon if you want to have a look at these USB devices.

These were all the different methods that I have heard of and tried (except Pt 3 – Plug and Use USB devices) on my own. You can even integrate these utilities with your UFT/QTP frameworks to provide more power to your automation frameworks.

Have you used any other piece of code or utility, which is not covered here? Let us know about it in the comments section.

The post UFT Batch Run – Prevent Windows from getting locked during Script Execution appeared first on XX.

UFT 12.52 Installation Packages

HP provides the following 2 installation packages for UFT 12.52 –

a) Full Installation Package (Size 2.3 GB) which contains –
– UFT Add-in for ALM
– Run Results Viewer
– License Server Setup
– Setup programs for Extensibility Accelerator, the Extensibility SDKs, and the Web 2.0 add-ins

b) Compressed UFT Installation Package (Size 916 MB) which installs the same features as the UFT installation setup program but does not include options to perform independent installations of the Unified Functional Testing Add-in for the ALM, the Run Results Viewer, Extensibility SDKs, or the License Server.

Steps to Download UFT 12.52 from HP website

1) Open UFT 12.52 download link. You will see a page as shown in the below screenshot.

2) Scroll down a bit where you will see the ‘Download Now’ button.

3) Click on ‘Download Now’ button. You will be taken to the sign-up page.

4) Fill up the form and click on ‘Sign Up’ button. You will see the below message.

5) Open your email account and search for the email from HP. Click on ‘Confirm Email’ link. Your email will be confirmed and you will be navigated to HP Enterprise login page

6) Login with your account details. You will see that UFT has been added to your product lists.

7) Click on ‘Download’ button. You will now be taken to a new page which gives you two different UFT packages – a) Full package & b) Compressed package

8) Click on any of the above links to start the download process on your machine.

In case you face any issues while downloading UFT 12.52, please feel free to contact us using email or using the comments section.

For more QTP Tutorials, you can visit our QTP Tutorials page. You can also visit our Download Page to view all the downloadable content.

The post Download UFT Latest Version (v12.53) from HP appeared first on XX.

A bit of background

Before getting into the details with this article, we will first have a brief look at the topics that we had covered in the previous article of the hybrid framework series. This will help set up a background which we will then follow up with this article. If you would have read the last article on the hybrid framework (Designing Hybrid Framework in QTP – Part 3), you might recollect that we had started that article with a framework which contained only 1 test case and had QTP modular framework features implemented in it.


We took the framework from that stage and added the capability of fetching data from excel sheets. Then we created the batch excel sheet and implemented the VBScript logic that will actually execute the test case in batch mode. When we finished that article, we had taken the hybrid framework to a point where we had implemented data handling and batch execution features to it.


In this article also, we will do the same thing. We will pick up the framework from where we had left it and will add some more features to it. The end result will be a full fledged working hybrid framework which you would be able to download and use as a base for creating much more better frameworks in your projects. Let us now start with the list of topics that we will cover in this article.

What’s in store for this article

Following are the topics that you will read about in this article –

1) Adding the remaining 2 test cases to the framework

2) Implementing the 3-tier reporting structure

3) Adding auto-email functionality to the framework

4) Sample downloadable framework code

5) Further suggestions for improving the framework

Adding the remaining test cases to the framework

Till now, the framework that we have created contains only one test case. When we covered the basic approach for creating a hybrid framework, we had mentioned that you start with a single test case and then add various framework features around it. Once most of the important features have been incorporated, then you should start adding the further test cases to the framework.


Currently you have the hybrid framework at a stage where most of the important features (such as code modularity, data handling capability, batch execution) have been added to it. The features that you still have to add are 3-tier reporting and auto-email capabilities. Now both these features can be considered as good to have. They can’t be classified as core must have features. Even if you don’t implement these features, you will still have a basic hybrid framework to work with.


So, going by the above logic, now is the time when you can add the remaining test cases to the framework. The below image shows the test cases that are to be added to the framework.

Approach to add the test cases to the framework

When we started creating the hybrid framework from scratch, the first step that we performed as to add a test case to the framework. And the approach we had followed at that time was this –

The reason we followed this approach in the beginning was, because at that time, the hybrid framework was nothing but a collection of folders (as defined by our folder structure). We didn’t have reusable functions or any other code at that time with us. Hence, we had to create the first test case in linear fashion.


But now, at this point, you have the reusable function libraries (both application independent and application specific functions) and various other capabilities built into the framework. So this time, you should not try to write the test case in linear fashion first and then convert it by adding functions to it. Now, while writing the test script, you should directly use the reusable functions wherever applicable.


Once you added both of the remaining test cases, you would have 2 additional test scripts in your framework. As with the structure of the first test case, these additional test cases would look something like this –

Test Case – TC02_CreateAndUpdateOrder

fnLogin()
fnCreateOrder()
fnUpdateOrder()
fnCloseApplication()

Test Case – TC03_CreateAndDeleteOrder

fnLogin()
fnCreateOrder()
fnDeleteOrder()
fnCloseApplication()

As you had done in case of the first test script, the code for these new functions (like fnUpdateOrder, fnDeleteOrder) should also be stored in the application specific function library.

Executing the newly added test scripts

Once you have added the new test scripts, the next step would be to see that these test scripts are working fine. First you should run both these newly added test scripts individually through QTP. Bu you shouldn’t stop here. There is another important point that needs to be checked. Since you have implemented the batch execution functionality, its only logical that you execute all these test cases in batch mode to verify that the code you have written for batch execution works fine for multiple test cases also.


In order to check this, open your batch excel sheet. You would have noted that we have already added all the test cases in the batch excel sheet. But only the first test case is marked as ‘Yes’. Since you want to execute all the 3 test cases, set the value in ‘Execute’ column to Yes for all the 3 rows. Save the excel sheet and click on Execute button. Check that the framework executes all the 3 test cases one after the other without any issues.

Important Note: Till now in this article, what we have done is – we took the framework with whatever features it had and then we added all the remaining test cases to it. And our plan is to add the remaining features (reporting, auto-email) in the framework after adding all the test cases. This approach works fine in this scenario because we have very few test cases. However, in real life circumstances you would have a lot of test cases that have to be automated.


In such a situation, you shouldn’t just add all the test cases in one go and then later add more features to the framework (like the way we are doing it here). The ideal way to work then would be to add few test cases, then implement couple of features, then again add few more test cases followed by more features. This is a proper, balanced way which you should follow to improve the framework together with adding more test cases to it.

Test Script Reporting – 2 Basic Rules

When it comes to implementing the reporting features in your automation framework, there are 2 basic rules that you should always try to follow. These rules are –


1) Never overwrite the test results: When you normally execute a test case multiple times, what QTP would do is that it would overwrite the previous results with the new ones. This should be fine when you are running a one-off test script randomly, but its a strict no when you actually execute your test scripts as a part of an automation framework.


This becomes much more important when you execute lot of test scripts on a daily basis. There might be times when your client would want to see some sort of report or projections about the number of test cases getting executed or defects being reported on a daily basic. This information would not be available with you if you keep overwriting your test case results.


One of the easiest ways you can use to “not overwrite your test results” is to append the test result file name with a unique random string. Having a unique random file name will ensure that your test results are never overwritten. And what would be a better way than using a date-time stamp as the unique, random string? Apart from providing a unique file name every time, date-time stamp provides you another advantage wherein you would find it easier to sort of the test results and number of test runs based upon dates.


2) Provide test result reporting at different levels: This is another important feature that you should always try to incorporate in your framework. Consider a scenario where you have hundreds of test cases in your automated regression suite and you have only implemented QTP’s standard reporting format in your automation framework.


Now, imagine that you test lead or project manager asks you the status of test run (with some basic information about which all scenarios have passed or failed). In such a situation, you cant just show the QTP result of each and every test case to your manager. He may not have time to go through all the details or may not be technically that good with QTP to understand the test results. A good solution in this situation would be to have all the test cases listed in an excel sheet with a “Passed” or “Failed” against each of the tests. This excel would act as a summarized report which would be easier for your manager to understand.


Extend the above scenario further to assume that your program manager or client needs a report on the test runs. In most of the cases, these people work on a lot of different projects and hence they mostly don’t track the execution to the test case level. For them, its just the basic information (like total number of test cases executed/passed/failed and some general data around the number of defects) that matters.


Hence, its important that your automation framework itself prepares all this data at different levels rather than you having to figure it out manually. So keeping in mind the importance of this reporting structure, we have decided to incorporate this 3-tier reporting mechanism in this automation framework. This 3-tier reporting architecture would contain reporting at the following levels –

Implementing the 3-tier Reporting Structure

In the previous section, you saw why its important to create a reporting structure that caters to different sets of audience. In this section, we will show how you can actually implement this reporting mechanism in your framework.


1) QTP based Detailed Reports: ‘QTP based Reports’ is the default report where you have separate QTP result file for each test script run. QTP based detailed reports are the easiest to implement as they are automatically generated by QTP when you execute a test script. So in most of the cases, there’s nothing additional that you would need to do from your end to implement this. A normal QTP based result would look something like this –

So, when you use the batch excel sheet to execute the test scripts in batch mode, QTP will automatically generate the test results for you. The only thing that you have to do from your end is to provide the location where these results would be stored. Also, as discussed in the previous section, you would need to append the result file name with date-time stamp so that the file name is unique and the results never get overwritten. The logic that we will use to come up with the unique result location for a test case is this –

Since the code for batch execution is added in DriverScript.vbs file, you would need to make the following code changes in the file so that the QTP result for each test case gets stored in its appropriate location.

'Create the Run Results Options object
Set qtpResult = CreateObject("QuickTest.RunResultsOptions")
'Set the results location
sQTPResultsPath = sQTPResultsLocation & sTestCaseName  & "_" & sDateTimeStamp
qtpResult.ResultsLocation = sQTPResultsPath
'Run the test
qtpTest.Run qtpResult

The above code would first set the result path to the folder location you specified. And then when the test script is executed, QTP would store the test run result directly to that folder location. This is all that you have to do to implement the “QTP based Detailed Reports” in your framework.


2.1) Excel based Summarized Reports (Design Part): The most basic Excel based Summarized Report is one where you have an excel sheet with just 3 columns – first column would store the test case name, the second one would contain the status of the test script run, and the third column will have a link that will point towards the detailed QTP based result for that test case. This basic excel based report will look like this –

However, its a good practice to extend this excel based report to add some more columns to it. Some other frequently used columns that you can add here are – test case execution date, execution start time, end time and the total duration of execution. Other than these, there might be some other fields that you would need to add depending upon your project requirements. The format of the excel based summarized reports that we will use in this framework is shown below.




2.2) Excel based Summarized Reports (Coding Part): You would need to follow the below mentioned steps to implement the excel based summarized reports in your framework.

Step a) The first step is the actual creation of this excel sheet. This is how it would work. Whenever you execute some test cases in batch mode, the automation framework would first create a blank result excel sheet. This blank excel sheet would just contain the headers and different columns (as mentioned in the above image). The framework would append a date-time stamp with this result sheet and save it in its intended location. Only after this excel file is created would the automation framework start executing the test cases. The code to create this blank excel result file is given below –

Set objExcel = CreateObject("Excel.Application")
objExcel.DisplayAlerts = False
Set objWorkbook = objExcel.Workbooks.Add()
'Set Header
objExcel.Cells(1, 1).Value = "TestCase_Name"
objExcel.Cells(1, 2).Value = "Status"
objExcel.Cells(1, 3).Value = "Test Results Path"
objExcel.Cells(1, 4).Value = "Execution Date"
objExcel.Cells(1, 5).Value = "Start Time"
objExcel.Cells(1, 6).Value = "End Time"
objExcel.Cells(1, 7).Value = "Duration"
'Save and close excel
objWorkbook.SaveAs(sBatchRunPath & sTimeStamp & ".xls")
objExcel.Quit
Set objWorkbook = Nothing
Set objExcel = Nothing

Step b) Once the blank result sheet has been created, the next step would be to update this excel sheet as and when a test script is executed. For this, what the automation framework would do is that, every time it executes a test script, it will first capture all the necessary details about the test run. After this, the framework will open the result sheet and will update the result. Thereafter, it will close the result excel sheet. The code for this is given below.

'Open Result Sheet and update the result
Set objExcel = CreateObject("Excel.Application")
Set objWorkbook = objExcel.WorkBooks.Open(sBatchRunPath & sTimeStamp & ".xls")
objExcel.DisplayAlerts = False
'Set the results
objExcel.Cells(iResultSheetRowCounter, 1).Value = TCName
objExcel.Cells(iResultSheetRowCounter, 2).Font.Bold = TRUE
objExcel.Cells(iResultSheetRowCounter, 2).Value = Status
'Color status
Select Case Status
	Case "NA"
		objExcel.Cells(iResultSheetRowCounter, 2).Font.Color = RGB(139, 137, 137)
	Case "Passed"
		objExcel.Cells(iResultSheetRowCounter, 2).Font.Color = RGB(0, 100, 0)
	Case "Failed"
		objExcel.Cells(iResultSheetRowCounter, 2).Font.Color = RGB(245, 0, 0)
	Case Else
		objExcel.Cells(iResultSheetRowCounter, 2).Font.Color = RGB(255, 255, 0)
End Select
objExcel.Cells(iResultSheetRowCounter, 3).Value = TestResultPath
objExcel.Cells(iResultSheetRowCounter, 4).Value = ExecutionDate
objExcel.Cells(iResultSheetRowCounter, 5).Value = StartTime
objExcel.Cells(iResultSheetRowCounter, 6).Value = EndTime
objExcel.Cells(iResultSheetRowCounter, 7).Value = Duration
'Save and close excel
objWorkbook.SaveAs(sBatchRunPath & sTimeStamp & ".xls")
objExcel.Quit
Set objWorkbook = Nothing
Set objExcel = Nothing

Step c) The automation framework would perform the above step (step b) for all the test cases that are executed as a part of that batch. Once all the test cases are executed, QTP will stop the execution and you will be left with the summarized excel report that will contain the results for all the test cases executed as part of that batch.


3) Email/SMS based Concise Reports: The concise report that you would create will contain a very high level information about the test run result. It would just provide a quick summary about the number of test cases executed together with the passed/failed numbers. This concise report when sent as an email would look something like this –

This concise report would mostly be used while sending emails and SMSes. Since, we will only be dealing with sending emails in this framework, the coding part of the concise reports would be covered in the Email section.

Adding auto-email functionality to the framework

Whenever you execute a set of test cases in batch mode, the hybrid framework would provide you an option to send an email automatically to a set of recipients. This email would notify the recipients that the batch run has been completed. This email would also provide them, the information about the status of the batch run.


Whenever you execute a set of test cases in batch mode, the automation framework will keep a track of the number of test cases executed/passed/failed by using some global level variables. These variables would be updated by the following code. You should be adding in the DriverScript.vbs file.

'Number of test cases executed till now
iTestCaseExecuting = iTestCaseExecuting + 1
'Find Run Status
sRunStatus = qtpTest.LastRunResults.Status
Select Case sRunStatus
	Case "Passed"    iTotalPassed = iTotalPassed + 1
	Case "Failed"	 iTotalFailed = iTotalFailed + 1
	Case Else	 iTotalOthers = iTotalOthers + 1
End Select

Once you have all the numbers ready, you can then use them in the email to send the concise report to the intended recipients. The code for sending the email is given below.

'Create an object of type Outlook
Set objOutlook = CreateObject("Outlook.Application")
Set myMail = objOutlook.CreateItem(0)
'Set the email properties
myMail.To = sEmailTo
myMail.CC = sEmailCc
myMail.BCC = sEmailBcc
myMail.Subject = sEmailSubject & " - " & Date
If sEmailBody = "" Then
  sMessage = "Total Test Cases Executed - " & iTestCaseExecuting - 1
  sMessage = sMessage & VbCrLf & "Passed - " & iTotalPassed
  sMessage = sMessage & VbCrLf & "Failed - " & iTotalFailed
  sMessage = sMessage & VbCrLf & "Others - " & iTotalOthers
  myMail.Body = sMessage
ElseIf sEmailBody <> "" Then
  myMail.Body = sEmailBody
End If
'Send the mail
myMail.Send
WScript.Sleep 2000
'Clear object reference
Set myMail = Nothing
Set objOutlook = Nothing

The above code assumes that you have Microsoft Office installed and configured on the machine from where you are executing the test scripts. In case you want to use GMail or Yahoo to send the emails, you can refer to this link which would provide you with the appropriate code for sending the emails (How to send emails using QTP from GMail and Yahoo).


Once you have implemented the email functionality in the framework, run all the test cases in batch mode once again. Check that all the test cases are executed and you receive an email thereafter which correctly mentions the status of the test execution.

With this, we come to the end of the coding part for the hybrid automation framework. Most of the important components that we had set out for in the beginning have been incorporated in the framework. You can download the entire framework code from the below link. The next section in this article will focus on some ideas that you can incorporate in this framework to make it even better.

Further suggestions for improvements/changes in the framework

Whatever we have created till now in this and the last couple of articles, is a framework at a very basic level. The components that we have used in this framework – such as object level functions, data handling capabilities, batch execution features, email, reporting etc – are very common and you would find these in almost all good hybrid frameworks.


As mentioned earlier also, the basic reason why we have used only the common components in the framework, is because we want to keep this framework as simple as possible, so that its easier for the beginners to understand all the concepts. However, this shouldn’t stop you from playing around with the code and improving it further by adding more features to it. In order to help you with this task, we have provided a list of suggestions that you can try to incorporate in this framework to make it more robust and better suited for your needs. This list of suggestions is given below –


1) Why just Outlook for Email? Well, Microsoft Outlook is one of the most widely used email clients in corporate world, more so in the case of bigger companies. More often that not, you would find yourself using Outlook for sending emails. But there are many other companies that use GMail or some other email clients within their organizations. So, one suggestion to make your framework more robust, is to implement the logic for sending emails through other email clients also.


The best way to do this would be to provide an option to your automation team to select the email client of their choice (the team should select the email client that’s configured on their machines). And based upon their selection, your automation framework should use that email client to send the emails.

2) Option to configure email externally without touching the code. Assume that you have created the hybrid framework that’s currently being used in your project. Since its you who has created it, you would be knowing all the details and all the code in the framework. But it would not be right to assume that every team member using the framework would have the same level of understanding and comfort with the code.


Hence, one of the objectives of any automation framework is to provide a mechanism to make certain changes without actually touching the code. If such a feature is provided, users would be able to easily modify certain things without having to touch the code, thereby reducing the chances of accidentally breaking something in the framework.


Configuring the email settings is a good example that can (or ideally should) be kept separate from the code. For example, rather that modifying the code to make changes in To, Cc or Body of the email, you can keep these things in an excel file and let the users directly modify the excel file. Your automation framework would simply read the excel file and send the emails based upon the data provided there. The below image would give you an idea about how this excel sheet would look like.

3) Intermediate status messages. This is something that many of you would have actually faced while working on automation projects. Imagine a situation where you are executing an automated regression suite that contains a lot of test cases (say more than 100). Once you click on execute button, there is nothing much to do other than just stare at the screen to see how the test execution is progressing. We all know how boring this can get. :–)


In such situations, you might go away from your desk for some time. For a coffee break or something else. When you return back, you see that the test cases are still getting executed, but now you might not have an idea about the number of test cases that are still remaining and hence the approximate amount of time the execution would go on for.


In such a case, having an intermediate status message is very useful. This ‘intermediate status message’  might simply be an auto closing pop-up message box that gets displayed after every test case run. You can configure this pop-up message to display the basic information, such as the total number of test cases executed till now, total test cases passed/failed till now. This information would help you get an idea about how well the execution is proceeding and approximately how much more time would the execution proceed for. An example of such a pop-up message box and its code is given below.

'Prepare the message to be displayed
sMsg = "Executing " & iTestCaseExecuting & " of " & iTotalTestCasesToBeExecuted & " Test Cases..." & VbCrLf
sMsg = sMsg & "Passed - " & iTotalPassed & VbCrLf  & "Failed - " & iTotalFailed
sMsg = sMsg &  VbCrLf  & VbCrLf  & "(This message will close automatically in 5 seconds)"
'Display the message for certain number of seconds
Set WshShell = CreateObject("Wscript.Shell")
WshShell.Popup sMsg, 5, "Intermediate Test Run Status"
Set WshShell = Nothing

4) Using VBA instead of VBScript for batch execution code. As part of this hybrid framework creation process, we have used VBScript to write the logic for batch execution. The only reason we did that was because we were more comfortable with VBScript than with VBA. But if you try to switch to VBA, it wouldn’t make any difference from framework’s functioning point of view. However, the plus point here would be that you would get to work on and learn something new, i.e. coding in VBA.


5) Framework configuration through external means. This is an extension of the feature that we had covered above in point #2. Configuring the email options is not the only thing you can do without touching the code. There would be a lot of other things in the framework that you may want to configure by external means. The below image shows some more things that you can configure by using excel sheets as an external mechanism.

6) Keeping all the folder locations at a single place. If you would have observed, this automation framework works with a lot of different folders (like folders for test cases, data sheets, results etc). And all these folder locations have to be specified somewhere within the code so that the framework can access it as and when required. Currently, all these folder locations are scattered at multiple places within the framework. One good idea would be to keep all these locations in a single place, preferably in an XML file.


The main advantage of this approach is that it would be easier for everyone to update the locations, as all of them would be available at a single place. If you want to follow this approach, you would have to include additional code in your framework that would read the XML file and extract all the folder locations from it. The below image shows you the sample structure of such an XML file.

With this, we conclude the ‘Hybrid Framework in QTP’ series. Hope you would have enjoyed reading these articles and would have got something useful to learn. Download the code and let us know if you face any issues while running it. You can pour in your thoughts about this article/series by using the comments section.

Visit QTP Frameworks Main Page for more articles on QTP Frameworks. You can also visit our QTP Tutorials page for detailed QTP Tutorials.

The post Designing Hybrid Framework in QTP – Part 4 [Final Part] appeared first on XX.

Topics covered in this article

Following are the topics that we will cover in this article –

a) Approach used to fetch data from excel sheets

b) Structure of the excel sheet and the actual code to fetch the data

c) Different ways to achieve batch execution with QTP

d) Preparing the batch excel sheet

e) Implementing the VBScript code to execute the test scripts from the batch sheet

How would data be fetched from excel sheets

Right now, the hybrid framework that you have with you doesn’t have the capability to fetch data from excel sheets. You have created custom functions (application independent functions) for all the QTP operations. And many of these custom functions have a parameter where you directly pass the data which you want to enter in the application. For example, the function fnSetValueInTextField takes whatever value you provide as an argument and then enters that value in the application. This is how it currently works –

But we don’t want our framework to work this way. What we want is that our data should be stored in excel sheets and the custom function should fetch the data from the excel sheet itself. So, our approach to fetch the data would be like this –

1) The data will be stored in the excel sheet(s).

2) Instead of passing the actual data in the custom function, we will pass the excel column header.

3) The custom function will open the excel sheet and find out the test data with the help of the column header.

4) The function will then set this data (obtained from the excel sheet) in the application.

The below image shows how this new concept would work –

Now, there are various ways in which you can fetch data from excel sheets. And the method that we would use in this framework is this- we will not fetch the data directly from excel sheet. Our custom function will first import the data from excel sheet into QTP data table and then will fetch the actual test data from the data table. This is how it will look like –

For more details on the different ways to fetch data from the excel sheets, you can refer the articles on QTP data driven framework.

Structure of the excel data sheets

The structure of your data sheet plays a very important part in the overall flow of your framework. And this data sheet structure becomes much more important when you are dealing with a lot of test cases (say more than 50 test cases). Also, there would be many other situations (like test cases being data intensive) that decide the structure of your data sheets.

You would have to factor in all these criteria and select the data sheet format that best suites your project and your requirements. We have provided ample examples of different data sheet formats and how they are integrated with the code in data driven and keyword driven frameworks. You can refer those articles to get a better understanding of all those concepts in detail.

However, in this article, we will try to keep things as simple as possible. And since we are working with only 3 test cases in this framework, we will create the most basic data sheet format. So, the data sheet format/structure that we will be using is as follows –

a) The framework will have 1 excel workbook as the data sheet.

b) Each test case will have its own separate excel sheet within that workbook.

c) So, this framework will use one excel workbook having three excel sheets (one sheet for each test case)

d) The name of each sheet will be same as the test case name. Doing this is important because if you keep the same names for the test case and the data sheet, it will become easier for the automation framework to identify the correct data sheet based upon the test case name.

The below image shows how the data sheet would actually look like.

It is now time start working on the actual code that will fetch the data from the excel workbook.

Actual code to fetch the data from the excel sheets

Let us first see the approach that will be used to fetch the data from the excel sheet.

1) You will create a separate function called fnFetchDataFromExcelSheet(). This is the function that will actually fetch the test data.

2) This function will take an argument which will be the column header of the excel sheet.

3) This function will be added inside other functions that actually set some value in the application. For example, you use fnSetValueInTextField() to enter some value in the application. So our function to fetch the data will be added inside fnSetValueInTextField() function.

4) When you execute your test case, this function will get called. This function will first open the excel workbook and identify the sheet from which the data is to be fetched (the sheet will be identified from the test case name).

5) It will then copy the entire data from the sheet and will load it into QTP data table.

6) Once all the data is loaded into the QTP data table, this function will fetch the actual value by using the column header.

7) Once the value is fetched, it will pass this data to the calling function (like fnSetValueInTextField) which will actually set the data in the application.


To implement this code you have to follow the steps given below –

1) Add the function that will fetch the data from the excel sheet in your function library. If you would have observed, this function is not application specific. It just fetches the data from the excel sheet. And hence, it has got nothing to do with your application. So, you have to save this function in the Generic_FunctionLibrary folder. The code for the function is given below –

'================================================================================
'Function name - fnFetchDataFromExcelSheet
'Description - This function retrieves the data from the excel sheet based upon the column name
'================================================================================
Function fnFetchDataFromExcelSheet(strColumnName)

	Dim sColValue

	'Initialize the return the value to "empty" string
	fnFetchDataFromExcelSheet = "empty"

	'Add a new blank sheet into the QTP data table
	'Excel data will be copied into this blank sheet
	DataTable.AddSheet("dtDataSheet")

	'Import the data from the excel sheet into the QTP data table
	DataTable.ImportSheet sExcelWorkbookPath, sSheetName, "dtDataSheet"

	'Find the value from the data table
	sColValue = DataTable.Value(strColumnName, "dtDataSheet")

	'Return the value back to the calling function
	fnFetchDataFromExcelSheet = sColValue

	'Remove Reference
	DataTable.DeleteSheet("dtDataSheet")

End Function
'================================== End Function ==================================

2) This function uses 2 variables. sExcelWorkbookPath and sSheetName. These variables have to be defined somewhere. To do that, add the following code at the beginning generic function library (the same function library where you added the above function).

Dim sExcelWorkbookPath, sSheetName
sExcelWorkbookPath = "C:\QTP-Hybrid-Framework\DataSheet\TestData.xls"

3) For the above function to work, the test case name should be passed to the function. The code to retrieve the test case name should be added in the main test case. And after adding the code to the main test case, the modified test case will look like this –

'Get the test case name into a variable
sSheetName = Environment.Value("TestName")

fnLogin()
fnCreateOrder()
fnCloseApplication()

4) Now, your function to fetch the data has been implemented. So, the next step would be to add this function call in those functions that actually enter the data in the application. As an example, we have shown how function fnSetValueInTextField() will look like after you have added the code to it.

'================================
'Function name - fnSetValue
'Description - Set value in a text field
'================================
Function fnSetValue(objControl, strColumnName)

On Error Resume Next
Dim sReqdValue

'Get vale from Excel Sheet
sReqdValue = fnFetchValueFromExcelSheet(strColumnName)

'Perform Action
If sReqdValue <> "empty" Then
objControl.Set sReqdValue
Else
Reporter.ReportEvent micFail, "Column - '" & strColumnName & "' Not Found in Data Sheet", "Failed"
End If

'Report out the result
If Err.Number = 0 Then
Reporter.ReportEvent micPass, "Value - '" & sReqdValue & "' entered in Field - '" & objControl.ToString() & "'", "Passed"
End If

End Function
'================================

5) The function call for fetching the data from excel sheets has to be added in all the function that set value in the application. In the framework that we have created till now, there are couple of functions more that perform the set operation on the application. These functions are – fnTypeValueInActiveXField() and fnSelectDropDownValue(). So, you would have to modify these 2 functions in the same way you did for fnSetValueInTextField().

6) Once you have modified all the functions, run the test case once again to verify that it works fine. Try changing the data in the excel sheet and see that the function enters the changed data in the application when you execute the test case.


Important Note: Till now, we have covered how you can implement excel data sheets in your hybrid framework. And to keep things simple, we have taken the simplest structure of excel data sheets – one excel workbook with multiple sheets. But in most of the hybrid frameworks that you will work on, the number of test cases will be quite big (say minimum 50 test cases). And in such a scenario, it is not advisable that you follow the data sheet structure that we have illustrated in this framework.

The best option would be to go through the data driven and keyword driven framework tutorials. From there, you would need to select the format of data sheet that best suites your application and your requirement. The approach on how you fetch the data will remain the same (from excel sheet to QTP data table to application), but the actual code would change a bit.

Adding batch execution features to your framework

Batch execution is a very important feature and is a part of most of the good hybrid frameworks. In fact, if you have an automated test suite with a large number of test cases (be it any type of framework), having an efficient batch execution mechanism becomes a must. Before diving deeper into the details about how you can implement batch execution, let us first start with the basics and see what batch execution actually is.


What is batch execution? Normally when you want to run a test script, you use the “Run” option provided by QTP. What it does is that, it will run the test script that is currently open in QTP. This “Run” option can execute only 1 test case at a time.

But what if you want to run a large number of test cases? Well, one option is that you open each test case one by one and click the Run option for all these test cases. This option can be tried if you have very few test cases with you. But if you have a large number of test cases, then this method is not at all a good option.

While dealing with a large number of test cases, you need a mechanism that can run your test cases effectively with minimum effort. And this is exactly what batch execution does for you. Batch execution is a mechanism that allows you to execute multiple number of test cases (a batch or set of test case) in one go. That is, with one click of a button, you can execute multiple test cases. And this is the reason why batch execution is sometimes referred to as one-click execution.

Different ways to achieve batch execution with QTP

One good thing about QTP is that it provides multiple ways for you to implement the batch execution features in your framework. Depending upon how complex your framework is or whether you use HP Quality Center to maintain your automation framework, you can use any of the batch execution implementations that suites your requirements.


Furthermore, in all the batch execution methods that QTP supports, the basic premise (or approach) remains the same –

a) You have to somehow create a list of test cases. This test case list is called the batch or the test set.

b) From this list of test cases, you should be able to select the test cases that you want to execute. This selection can either be all the test cases or a subset of the test cases.

c) There should be some execute button which, if you click, will run all the test cases that you have selected from the list.


Below, we have listed down the different batch execution methods supported by QTP together with a brief description about each one of them.


1) Using QTP’s Test Batch Runner tool: This is a feature/tool provided by QTP and can be found at Start >> All Programs >> HP Quick Test Professional >> Tools menu. Here you can add all the test cases to the batch and then click on the run button to execute the batch.

2) Using QC’s test set feature: If you are using Quality Center to store your hybrid framework, then you can create a test set in QC’s test lab. QC provides a run button, which when clicked will execute all the test cases added to that particular test set. This method of batch execution is also very helpful when you use QTP’s BPT framework.


3) Using QTP’s AOM capabilities: This is the most important method using which you can implement batch execution in your QTP framework. QTP AOM, also known as automation object model, is a feature using which QTP exposes its capabilities to the “outside world” in the form of properties and functions. Here, “outside world” refers to different programming/scripting languages like C#, VBA, VBScript etc.


For example, in QTP you have different menu options or shortcuts for doing different tasks, such as opening a test case, running a test case, associating function libraries etc. And normally you would use QTP’s GUI to perform all these actions. But what AOM will do is that it will provide you with different functions that can perform all these tasks programatically. For example, AOM provides a function called “Run” that you can use to execute a given test case. So you can write a program or code that will use this Run function to execute a test case in QTP.


Another good part about AOM is that it can be used with a variety of programming languages. If you are using excel sheets, then you can use AOM in VBA. If you wish to create your own little web portal to drive QTP, you can use C# with AOM.


As part of this hybrid framework, we will be using the QTP AOM method to implement batch execution. The list of test cases to be executed will be maintained in an excel sheet and we will use excel macro (with VBScript + AOM) to execute the test cases in QTP.

Preparing the batch excel sheet

Implementing the batch execution in QTP using AOM is a two-step process. The first step is to create the list of test cases and the second step is to write code that will execute these test cases. In this section, we will focus on the first part, that is, creating the list of test cases in excel sheet. Follow the steps given below to create this test case list –


1) Open a new excel workbook.


2) Make sure that the developed tab is visible in the workbook.

If the developer tab is not visible, then follow the below steps to enable the developer tab. The screenshots given below are from Microsoft Excel 2010. Based upon your version of MS Excel, you would need to figure out the steps accordingly.

2.1) Select File >> Options.

2.2) Click on Customize Ribbon from the left hand side pane.

2.3) Select the Developer check box from the right-most pane.

2.4) Click OK. Developer tab should now be available in your excel sheet.


3) In the excel sheet, leave the first row blank. We will add the Execute button in the first row.


4) Starting with the second row, set the column headers and data as shown in the below image.

5) Since you currently have only 1 test case in your framework, set Execute as ‘Yes’ for the first test case. For second and third test cases, set the value as ‘No’.


6) Save this file as ‘Batch.xls’ in the Batch folder.


7) Select Developer tab.


8) Click on Insert option in Developer tab and then select the button icon under ‘Form Controls’ section.

9) Drag the mouse to create a button in the first column of the excel sheet.

10) In the dialog box that opens up, give a proper name to the macro and click on OK button.

11) The button would now be displayed in the first row. Right click on the button and change its text to ‘Execute’. Change other properties as required.

12) Again right click on the button and select ‘Assign Macro’ option.

13) Assign Macro dialog box should be displayed as shown below.

14) Click on ‘New’ button. Upon clicking the New button, a new window will be displayed as given below.

15) Enter the following command inside the Sub function.

Shell "WScript " & """D:\QTP-Hybrid-Framework\Batch\DriverScript.vbs"""

The code in the sub function should now look like this –

What this means is that when you click on the ‘Execute’ button in the excel sheet, it will pass the control to this sub function. This sub function will in turn execute all the code that is there in DriverScript.vbs file. This DriverScript.vbs file would be the file where you will write the code to execute the test scripts. This coding part is described in the next section.

Adding the code for batch execution

When you use Microsoft Excel as your batch sheet, then you have two ways in which you can implement the coding part. These two ways are –


a.) Writing the code in the macro itself: With this method, you write the code in the excel macro itself. And this code will be written in VBA. Also, since the macro code is a part of MS Excel, you don’t need to create a separate file to write the code.


b.) Writing the code in VBS file: Here, you will create a separate .vbs file and write all the code in it. The excel macro will just be used to call this .vbs file. In this case, coding will be done using VBScript.


Towards the end of the last section (point #15), you would have seen that we have created a separate DriverScript.vbs file. Also in the macro function, we have included a single line of code that just calls this vbs file. What this means is that we are using method b.) to write the AOM code.


Important Note: Even though we have used method b. (using .vbs file) to write the code, you are free to use any of the method that suites you. The only reason we used it this way is that using .vbs file allows us to work with VBScript. And since QTP uses VBScript, we feel more comfortable with VBScript rather than with VBA.


Steps to add the batch execution code: Follow the steps mentioned below to add the batch execution code to your framework.


1) Open a new text file using notepad or any other text editor of your choice


2) Add the following code in this text file. The explanation about the code is added with the code itself in the form of comments

'========== Declare and initialize the variables ==========
Dim sTestCaseFolder, strScriptPath, sQTPResultsPath, sQTPResultsPathOrig

sBatchSheetPath = "D:\QTP-Hybrid-Framework\Batch\Batch.xls"
sTestCaseFolder = "D:\QTP-Hybrid-Framework\TestCases\"
sQTPResultsPathOrig = "D:\QTP-Hybrid-Framework\Results\DetailedQTPResults\"

'========== Create an object to access QTP's objects, methods and properties ==========
Set qtpApp = CreateObject("QuickTest.Application")

'Open QTP if it is already not open
If qtpApp.launched <> True Then
 qtpApp.Launch
End If

qtpApp.Visible = True

'========== Set the run options for QTP ==========
qtpApp.Options.Run.ImageCaptureForTestResults = "OnError"
qtpApp.Options.Run.RunMode = "Fast"

'Set ViewResults property to false. This is because if you run many test cases in batch, you would not want QTP to open a separate result window for each of them
qtpApp.Options.Run.ViewResults = False

' ========== Read test cases from batch excel sheet ==========
Set xl_Batch = CreateObject("Excel.Application")
Set wb_Batch = xl_Batch.WorkBooks.Open(sBatchSheetPath)

'Loop through all the Rows
'1st row contains Execute button, 2nd row is header and the test case list starts from 3rd row. So, For loop is started from 3rd row
For iR = 3 to 1000

 'Get the value from the Execute column
 If xl_Batch.Cells(iR, 1).Value = "Yes" Then

 'Get Test Case Name
 sTestCaseName = xl_Batch.Cells(iR, 2).Value

 'Get the location where the test case is stored
 strScriptPath = sTestCaseFolder & sTestCaseName

 'Open the Test Case in Read-Only mode
 qtpApp.Open strScriptPath, True
 WScript.Sleep 2000

 'Create an object of type QTP Test
 Set qtpTest = qtpApp.Test

 'Instruct QTP to perform next step when error occurs
 qtpTest.Settings.Run.OnError = "NextStep"

 'Create the Run Results Options object
 Set qtpResult = CreateObject("QuickTest.RunResultsOptions")

 'Set the results location. This result refers to the QTP result
 sQTPResultsPath = sQTPResultsPathOrig
 sQTPResultsPath = sQTPResultsPath & sTestCaseName
 qtpResult.ResultsLocation = sQTPResultsPath

 'Run the test. The result will automatically be stored in the location set by you
 WScript.Sleep 2000
 qtpTest.Run qtpResult

 ElseIf xl_Batch.Cells(iR, 1).Value = "No" Then
 'Do nothing. You don't have to execute the test cases marked as No

 ElseIf xl_Batch.Cells(iR, 1).Value = "" Then
 'Blank value means that the list of test cases has finished
 'So you can exit the for loop
 Exit For

 End If

Next

3) Save this text file as DriverScript.vbs. Make sure that the file is saved with .vbs extension only and not as DriverScript.vbs.txt. Also make sure that the path mentioned in the excel macro function (point #15 in the previous section) is the same place where you save this vbs file.


4) Open the batch excel sheet. Make sure that the first test case is selected as ‘Yes’. And the remaining two test cases are marked as ‘No’. Also, go to Developer tab and check that the ‘Design Mode’ option is unselected.


5) Now, its time to verify if batch execution feature has been properly implemented or not. To do this, click on the Execute button. If everything is working fine, the driver script will load the first test case in QTP and will execute the test case.


Now, you will have a hybrid framework that can execute a single test case in batch mode. Also, your hybrid framework has the features of modular and data driven frameworks implemented in it. So, at this stage, you can say that you have set up a hybrid framework with most of the important features in it. :–)

Final article on QTP Hybrid Framework

The next article would be the final one on QTP hybrid framework series. That article would cover the remaining topics about implementing the reporting and auto-email features. Moreover, we will publish the entire framework code (with all the 3 test cases) in the next article.


Till then, if you have any comments about this article, you can let us know about it using the comments section.

Visit QTP Frameworks Main Page for more articles on QTP Frameworks. You can also visit our QTP Tutorials page for detailed QTP Tutorials.

The post Designing Hybrid Framework in QTP – Part 3 appeared first on XX.

Topics that will be covered in this article

In this article, we will cover the following aspects of the hybrid framework –

a) Identifying the test cases that will be automated as part of this framework

b) The plan or approach as to how the framework will be created

c) Folder structure and writing the first test case

d) Applying the modular framework features in this hybrid framework

Test Cases that will be automated

As a part of this hybrid automation framework, we will automate the following test cases. The application that we will use would be mercury flight reservation system (windows version) and the version of QTP would be QTP 10. Even though we are using QTP 10, you would be able to execute the same test cases in the later versions without any issues.


1) TC01_CreateOrder: The flow of this test case would be to login to the application, create an order and then logout


2) TC02_CreateAndUpdateOrder: For this test case, the flow would be: login >> create order >> search order >> logout


3) TC03_CreateAndDeleteOrder: Here, the flow of the test case would be like this: login >> create order >> search order >> delete order >> logout

Basic approach to create the hybrid framework

As mentioned earlier, the hybrid framework that you will create here will consist of a lot of components and features that will be interlinked with each other. So, in order to create the framework from scratch, you will need to have a plan or an approach. You simply can’t go on doing random stuff and assume that the components and features would somehow get linked together at the end.


The most basic approach (and also the safest one) is to start with a small and easy chunk. This small chunk should be something that can be executed, for example a test case. You should then execute this test case and make sure that it works fine. After this is done, you should then start adding other components and features around it. After the addition of each component, you should execute your code to make sure that things work fine.


By following this approach you would be able to add all the components together to come up with your hybrid framework. And since you added all these components over a single test case only, you will have a basic framework with you, which has only 1 test case in it. Also, it’s not necessary that you have to add all the components/features onto a single test case. The thumb rule is to create one test case and add the important components and features to it. So, once this basic framework is ready (with the important components), you can start adding other test cases to your framework.


What you saw above was the generic approach that you can follow to create a framework from scratch. Now you would see the exact steps or approach that we will follow here to create our hybrid framework.

1) The first step would be to define a generic folder structure that you would use for your framework. Please note that its not necessary that whatever folder structure you create in the beginning is 100% correct. This is because there might be some scenarios that might have skipped your mind in the beginning. And to accommodate that scenario you might need to alter the folder structure a bit. But most of the times, 80-90% of your folder structure would remain the same way as you had thought of it initially.


2) The next step that you would need to follow is to write the first test case. This should be a plain and simple test case, like the way its written in QTP linear framework.


Note: Many a times, people start with the second step first. That is, they first write the test case and think about the folder structure at some later stage. This approach also works fine. But we suggest you work on folder structure first because when you start thinking about the folder structure in the beginning, you sort of think about how your overall framework would look like. And thinking about that sort of details since the initial stages sometimes help you avoid costly (in terms of time and effort) reworks.


3) After you verify that your test case (written in linear manner) works fine, the next step would be to analyze the code and identify reusable functions. At this step, you would need to introduce the function library and move the reusable functions into it.


4) Next step would be to remove all the hard-coded data from the test case and put it in an excel sheet. You should then write the code to fetch your data from the excel sheets.


5) At this step, you would need to create a batch excel sheet and add a macro or driver script to it. This macro when executed would run your test case (that is added in the batch excel sheet).


6) Now you would need to work on the test results part. You would have to modify your code so that you can store your test results in two different ways – both as summarized results as well as detailed results. You would also need to add a time-stamp mechanism to your result files so that it doesn’t get overwritten.


7) The next step would be to add the auto-email functionality to your framework. At this point, you would have your basic hybrid framework ready that has most of the important features added in.


8) Now, the next step would be to add the remaining test cases in your framework. At this stage, it would not be required to first write the test cases in linear fashion. Since most of the common functions are already in place, you can directly start using those functions when you write the test scripts.


9) The ninth and final step would be to modify some of the code as deemed necessary. This step is important because the initial framework that you created worked well on 1 test case. But when you try to add multiple test cases, you might need to make some additional changes in your code so that all the test cases can run one after the other without any issues.


At this stage, you will have your full fledged hybrid framework up and running. With this, let us now start with our first step.

Folder structure

The folder structure that would be used for this hybrid framework is given below.

Most of the stuff in the folder structure is self explanatory. Let’s quickly go through each one of them.

a) QTP-Hyrbid-Framework folder: This is the parent folder. All the framework code and other artifacts will be stored inside this folder.

b) Batch folder: This is the folder that takes care of the batch execution. The batch excel sheet (which will have the list of all the test cases) and the excel macro will be stored in this folder.

c) DataSheet folder: All your excel data sheets will be stored in this folder.

d) Resources folder: This is just a top-level folder that has many sub-folders inside it.

e) AppSpecific_FunctionLibrary, Generic_FunctionLibrary and Object Repository: These folders will be used to store function libraries and object repositories.

f) ConfigurationFiles folder: This folder will contain the items that would be used to configure the overall framework settings. For example, the settings such as whether to send email or not, or what should be the default wait time etc will be stored in this folder.

g) GenericFiles folder: This folder will be used to store the generic files. For example, if your test cases upload or download some files to/from the application, then those files will be stored in this folder.

h) Results folder: Results folder contains many sub-folders that will be used to store the test results and the error screenshots.

i) TestCases folder: This is the folder where all your QTP test cases will be stored.

Writing the first test script

You have already defined the folder structure and now its time to write your first test script. You would be writing this test script in linear fashion, that is, in the way its done in case of QTP linear framework. This means that all the code will be in a linear, sequential manner. Also at this stage, you would not create any reusable functions. All your test data will also be hard-coded with the test script itself.


While writing the test script, please make sure that you don’t record the script. Use object repository to first add the objects and then write the code in the QTP test case. The test case that you would create first is TC01_CreateOrder. The flow of the test case would be like this –

Once your test case is created, store it in the “TestCases” folder. Also save the object repository in its corresponding location. Below we have given the complete code for create order. The code that you create would look somewhat similar to this.

'Open the flight reservation application
SystemUtil.Run "C:\Program Files\HP\QuickTest Professional\samples\flight\app\flight4a.exe"

'Login to the application
Dialog("Login").WinEdit("AgentName").Set "anish"
Dialog("Login").WinEdit("Password").Set "mercury"
Dialog("Login").WinButton("OK").Click

'Verify that login is successful
If (Window("FlightReservation").Exist(10)) Then
	Reporter.ReportEvent micPass, "Login Successful", "Login Successful"
Else
	Reporter.ReportEvent micFail, "Login Unsuccessful", "Login Unsuccessful"
End If

'Create a new order - i.e. book a flight ticket
Window("FlightReservation").ActiveX("DateOfFlight").Type "010135"
Window("FlightReservation").WinComboBox("FlyFrom").Select "Denver"
Window("FlightReservation").WinComboBox("FlyTo").Select "Frankfurt"
Window("FlightReservation").WinButton("Flights...").Click

'Select the first flight in the list and click OK
Window("FlightReservation").Dialog("FlightsTable").WinButton("OK").Click

'Provide name, class and Insert the order (using descriptive programming approach)
Window("FlightReservation").WinEdit("attached text:=Name:","nativeclass:=Edit").Set "anish"
Window("FlightReservation").WinRadioButton("text:=First").Click
Window("FlightReservation").WinButton("text:=&Insert Order").Click
wait(8)

'Verify if order is created
strOrderNumber = Window("FlightReservation").WinEdit("attached text:=Order No:").GetROProperty("text")
If (strOrderNumber <> "") Then
	Reporter.ReportEvent micPass, "Flight booked successfully", "Order number - " & strOrderNumber
Else
	Reporter.ReportEvent micFail, "Flight not booked", "Flight not booked"
End If

'Close the application
Window("FlightReservation").Close

Before you move over to the next stage, you have to make sure that whatever you have done till now works fine. So, run the test script that you have created and verify that it executes completely without any issues.


Important note: Please note that, as part of this framework creation process, the basic steps such as adding objects to the object repository, associating function library to the scripts etc would not be explained. We are assuming that you have gone through all the previous articles on the other QTP frameworks and hence you have a good understanding on how these basic things are done. Even if you have directly started with this article, we will assume that you have a basic understanding on how different QTP frameworks work.

Function Library – Adding application independent functions

In the previous article on QTP hybrid framework, we had mentioned that a hybrid framework is created by taking out features from other framework types and implementing them in your framework. This is exactly what you would do next. You would select the features from the other framework types and add them to your framework one by one.


The first feature that you would include in your framework is to add reusable functions, and that too the application independent functions. Now, the first question that you would come to your mind is – what are application dependent functions? Well, as the name suggests, an application independent function is a reusable function that doesn’t depend on your application.


Take QTP click operation as an example. In the above code, you can see that the click operation is used at many places to click on different types of buttons. Now, this click function is not bound to the flight reservation application in any way. So if you replace the flight reservation application with some other application, like the windows calculator, the click button will still function in the same way. As long as you pass the correct object, the click operation will click on the button, be it in the flight reservation application or in the windows calculator.


So, similar to the click operation, there are various other operations like set, type, select etc that do not depend on your application under test. So the first thing that you would do it to replace these QTP operations with your own custom functions. The whole idea here is to replace all (or most of) the QTP operations with your own custom functions.

Why application independent functions are important?

Well, this is another important question that might have come into your minds. When QTP already provides its own functions like click, set, type etc then why do we need to replace them with our custom functions. Well, there are a few reasons as to why we do so –


1) By creating your own functions, you can extend the capability of the operation by adding more features to it. For example, you can write a function called fnButtonClick() where you can first verify if the button exists. Then you add the code to actually click on the button. And finally you can add your custom message which tells that the button has been clicked. In this way, you are extending the normal click operation by adding more operations to it.


2) Another important thing that you can accomplish is custom error handling. If the button that you try to click is not found, QTP will handle the error in the way that you specified. This way, you will have more control on how your framework behaves in error scenarios.


3) You can provide more meaningful names to your custom functions. For example, rather than using an operation called set, you can create your own function that you can name as setValueInTextField(). These sort of function names make more sense than some QTP defined operation names.


4) These custom functions can be used to achieve method overriding. Refer the article on method overriding using RegisterUserFunc for more information about this concept.

Let us now see how to replace the QTP operations with your custom functions.

Replacing QTP operations with application independent functions

Follow the steps given below to replace the QTP operations with your own custom functions.

1) Create a new function library and save it in the Generic_FunctionLibrary folder.

2) Associate the function library with the test script.

3) To replace the set operation with your custom function, add the following code in the function library.

'Registering the user defined functions
'================================
'
RegisterUserFunc "WinEdit", "fnSetValueInTextField", "fnSetValue"
'
'
'
'================================
'Function name - fnSetValue
'Description - Set value in a text field
'================================
Function fnSetValue(objControl, strValue)

On Error Resume Next

'Set the value
objControl.Set strValue

'Report out the result
If Err.Number = 0 Then
Reporter.ReportEvent micPass, "Value - '" & strValue & "' entered in Field - '" & objControl.ToString() & "'", "Passed"
End If

End Function
'================================

4) Come back to the test script and replace the operation set with the custom function name. Please note that if each of the above steps is done correctly, the custom function will be displayed as an option in the intellisense menu.

Dialog("Login").WinEdit("AgentName").fnSetValueInTextField "anish"

5) Run the code to see that the test script works perfectly fine with the custom function.

6) Replace all the set operations with the same custom function name.

7) Write custom functions for all other operations and add them in your test script.

8) Once this is done, all the QTP operations in the test script will be replaced by your own custom functions. The test script code should look something like this.

'Open the flight reservation application
SystemUtil.Run "C:\Program Files\HP\QuickTest Professional\samples\flight\app\flight4a.exe"

'Login to the application
Dialog("Login").WinEdit("AgentName").fnSetValueInTextField "anish"
Dialog("Login").WinEdit("Password").fnSetValueInTextField "mercury"
Dialog("Login").WinButton("OK").fnWinButtonClick

'Verify that login is successful
If (Window("FlightReservation").Exist(10)) Then
Reporter.ReportEvent micPass, "Login Successful", "Login Successful"
Else
Reporter.ReportEvent micFail, "Login Unsuccessful", "Login Unsuccessful"
End If

'Create a new order - i.e. book a flight ticket
Window("FlightReservation").ActiveX("DateOfFlight").fnTypeValueInActiveXField "010135"
Window("FlightReservation").WinComboBox("FlyFrom").fnSelectDropDownValue "Denver"
Window("FlightReservation").WinComboBox("FlyTo").fnSelectDropDownValue "Frankfurt"
Window("FlightReservation").WinButton("Flights...").fnWinButtonClick

'Select the first flight in the list and click OK
Window("FlightReservation").Dialog("FlightsTable").WinButton("OK").fnWinButtonClick

'Provide name, class and insert the order (using descriptive programming approach)
Window("FlightReservation").WinEdit("attached text:=Name:","nativeclass:=Edit").fnSetValueInTextField "anish"
Window("FlightReservation").WinRadioButton("text:=First").fnRadioButtonClick
Window("FlightReservation").WinButton("text:=&Insert Order").fnWinButtonClick
wait(8)

'Verify if order is created
strOrderNumber = Window("FlightReservation").WinEdit("attached text:=Order No:").GetROProperty("text")
If (strOrderNumber <> "") Then
Reporter.ReportEvent micPass, "Flight booked successfully", "Order number - " & strOrderNumber
Else
Reporter.ReportEvent micFail, "Flight not booked", "Flight not booked"
End If

'Close the application
Window("FlightReservation").fnWindowClose

9) After all the QTP operations are replaced with custom functions, run your test script once again to make sure that everything is OK.

Looking at the test results

At this stage, you have replaced all the QTP operations with your own custom functions. Also, the reporting steps have been added inside the custom functions. So let us now have a look at how the test results would look when you run your customized code.


The below image compares the test results before and after you have implemented your custom functions. Here, you can note that the readability of the test results has increased a lot after the addition of custom functions. Now you should be able to quickly glance at the results and get an idea about what is happening with the script.

One issue with the customized result shown above is that even when you customize the result, its look and feel remains the same. You can try to tweak the CSS a bit, but there is not much that you can do there. Another solution would be to extend this logic by writing the results in an HTML file. You can further add style sheets and CSS to make your result HTML files look more beautiful. You can also add your company logo to get more professionally looking test results. That’s the level of control you get when you use custom functions. And that’s one of the main reasons why the custom functions are important.

Function Library – Adding application specific functions

This section is fairly straightforward and is something that you would have done a lot in QTP modular frameworks. The objective of this section is to analyze your code and see if you can identify some reusable components. Once you have done so, you should then replace the linear code with these reusable functions.


By looking at our code, you can easily figure out that the entire test case can be divided into 3 reusable functions. These are – a) open application and login, b) create order, and c) close application. Create these 3 reusable functions and add them in a separate function library. Since these functions are application specific functions, so you have to save this function library in AppSpecific_FunctionLibray folder. Finally, don’t forget to associate this function library to your test case.


After you have replaced your code with the reusable functions, your test script would look something like this.

fnLogin()
fnCreateOrder()
fnCloseApplication()

Execute the test case to make sure that the addition of these features didn’t result in any issues. Now you have a hybrid framework in which you have incorporated the features of QTP modular framework.


It is now time to stop this article at this point. This post is already very lengthy, adding more content to it will only complicate the matters. So we will stop it here and take up the other components in the next article. The next article will focus on adding data sheets to the framework. Also, we will have a close look at how you can add the batch execution capability to your framework.


This was all from our end and its time to know what you think about it. Use the comments section and pour in your thoughts on this article.

Visit QTP Frameworks Main Page for more articles on QTP Frameworks. You can also visit our QTP Tutorials page for detailed QTP Tutorials.

The post Designing Hybrid Framework in QTP – Part 2 appeared first on XX.

Starting with this article, we will explain the step by step process that will guide you to create your own hybrid framework from scratch. The framework will incorporate some of the features that we had mentioned in the previous article. This step by step process will be detailed and will span across 2 to 3 articles. Let’s start with whats in store for this article.

Topics that will be covered in this article

In this article, we will cover the following topics on Hybrid Framework –

• 1) Components that would be used to create this framework
• 2) Features that would be a part of this hybrid framework
• 3) The flow diagram of the hybrid framework

All the above topics would serve as the basic building blocks that would help you understand and relate to the bigger picture with ease.

Components used to create this framework

Below is the list of all the components that will be used to create the hybrid framework. A short description accompanies each component.

1) VB Excel Macro: The VB excel macro will act as the starting point for running the test scripts. How it would work is like this – There will be an excel sheet which will contain the list of all the test cases. There will also be an ‘execute’ button in the excel sheet.

If you want to run the test scripts, you will need to click on the ‘execute’ button. This execute button will have a macro attached to it. So when you click on the button, the macro will open QTP and load the first test case to it. It will then instruct QTP to execute the test script.

The same procedure will be followed for all the test cases that are available in the excel sheet. The excel macro will use QTP AOM (automation object model) concepts to interact with QTP.

2) Excel Sheets: Excel sheets will be used extensively by the hybrid framework that we would create. Excel sheets will be primarily used to store the following information –

• a) Test Case List: As mentioned above in point 1, a list of all the test scripts will be maintained in excel sheet. This will be used for batch execution.
• b) Test Data: All the test data would come from excel sheets. No test data will be hard-coded anywhere in the test scripts.
• c) Test Results: Excel sheets will be used to provide a summarized result of batch execution. Here, the excel sheet will simply contain the list of test cases that were executed together with the information about whether the test scripts passed or failed.

3) Test Scripts: These are the actual QTP test scripts. For each scenario that you would automate, you would need to create a separate QTP test script.

4) Function Library: This hybrid automation framework will use two separate function libraries. The first function library will store all the generic functions (application independent functions). Some examples for this can be functions to click on a link, to enter value in a text field etc.

The second function library will contain application specific functions. Functions such as login, logout etc will be a part of this second function library.

5) Object Repository: All the object definitions will be stored in the object repository. There will be minimal use of descriptive programming concepts. Having said that, we will try to incorporate descriptive programming at some places so that you can get a feel of how you can use both object repository and descriptive programming together in the same place.

Salient features of the hybrid framework

Following are some of the important features that you will see in this hybrid framework.

1) This framework will be optimized for batch execution. This is what most good frameworks are all about. With this framework, you will be able to easily select the test cases that you want to execute in batch run.

2) To execute your test scripts, you would not be required to open QTP. This would be taken care of entirely by the driver script (excel macro).

3) As mentioned in the previous article, this framework will provide the test execution results at two different levels – summarized results and detailed results.

4) The test execution results from multiple runs would not be overwritten. Each test execution result will be appended by date-time stamp so that it can be referenced whenever required.

5) The hybrid framework will have the provision to automatically send emails (with the test results) after completion of a batch run.

6) The framework will contain an external configuration sheet which will help you to configure many of the features of the framework without having to touch any of the code.

Flow diagram of the framework

The below image describes the flow diagram for test script execution in the hybrid framework that we will create.

1) Execution of the test scripts start from the VB excel macro. Once you click on execute button in the excel sheet, the macro iterates through the excel sheet to find out the test case that needs to be executed.

2) Once the macro finds the test case, it loads the test case into QTP and “asks” QTP to execute that test case.

3) QTP (with the help of function libraries, object repository and data sheets) executes the test case.

4) After the test case is executed, QTP sends the control back to the driver script. Driver script then loads the next test case into QTP.

5) Once all the intended test cases have been executed, driver script creates the test results and stores it into its corresponding folders.

6) The driver script then sends an email to all the intended recipients.

This was all about the features, components and flow diagram of the hybrid framework that we will create. The next article will focus on the most important part of the process – the actual creation of the framework. That’s all from our side. Do let us know your thoughts on this using the comments section.

Visit QTP Frameworks Main Page for more articles on QTP Frameworks. You can also visit our QTP Tutorials page for detailed QTP Tutorials.

The post Designing Hybrid Framework in QTP – Part 1 appeared first on XX.

“Hybrid framework is the most commonly used framework in test automation projects.”

So, if you learn this and get it right, then you would be in a position to work on automation projects in your organization. With this, let us now start with the basics of the QTP hybrid framework.

What is Hybrid Framework in QTP?

Each and every framework type in QTP has its own positives and negatives. You can take the positive points from each of these frameworks and create a customized framework that suites your requirements. This customized framework is called a hybrid framework.

So, in very simple terms – “A hybrid framework is a framework that is created by combining together the features of the different types of QTP frameworks.” This is depicted in the image shown below.

Is there any specific predefined structure of a Hybrid Framework?

Well, a straightforward answer for this question would be – No. Let try to understand why it is this way? In the previous section, you had read about what a hybrid framework actually is. There are two key takeaway points in that explanation –

• 1) A hybrid framework is a collection of features from the other framework types.
• 2) A hybrid framework is one that suites your requirements.

Now, the second point mentioned above is very important. The hybrid framework that you create should suite your requirements or your stakeholder’s requirements. And there can be a lot of factors that influence your decisions. For example –

• – you might want to use a particular feature in your hybrid framework but it might not be useful or necessary for the application you are testing. Example – you might want to use excel sheets to store test data. But in case your application takes the same data every time, it makes more sense to hard-code the data in your code itself or maybe taking it as environment variables
• – you might have a disliking for certain features and hence you always tend to use the features that you like. For example, I’m more biased towards functions and hence I tend to use them more than say, using action calls
• – your client may have a preference towards certain type of framework as they would have seen a similar sort of framework being used previously. So if you can convince the client, then its well and good, else you would have to stick around with what they have suggested (this is something that I have had to deal with in few of my automation projects)

Taking all the above points into consideration, you can safely say that the features that you select to create your hybrid framework may vary vastly from someone else’s framework. And hence, there is no predefined structure of this type of framework. To sum it up, different hybrid frameworks should be like –

But there are certain components (or features) that frequently appear in different hybrid frameworks. These components would be the ones that we would use to create the sample hybrid framework.

Is it easy to identify Hybrid Frameworks?

Well, its easy but not that straightforward to identify a hybrid framework. An important reason for this is that the implementation of hybrid framework varies from person to person and from project to project. But you had also seen in the beginning of this article that most of the frameworks implemented in live projects are in fact hybrid frameworks.

Hence, any good framework worth its salt should be a hybrid framework. And to identify it properly, you need to have a close look at its architecture and its components. You should try to find out if its using keywords extensively, or if its taking its data from excel sheets, or if the code is written in modular format. This way, you would be able to identify the framework types from which the hybrid framework borrows its features.

Useful Tip: Whenever you create or use a hybrid framework, don’t just call it a hybrid framework. Always try to include the names of the other frameworks from which your hybrid framework has derived its features. For example, you can call your framework as –

• – a hybrid framework based on functional and data driven approach
• – a keyword based hybrid framework
• – a hybrid framework implemented with functional and keyword driven components
• – or any other fancy terms that come to your mind

Its always considered a good practice to call your framework this way.

A word about BPT Framework: A good BPT framework will also not just be a BPT framework alone. It would also incorporate the features of a keyword driven, data driven or modular framework in it. And if that’s the case, then it becomes a hybrid framework. But still people tend to call it a BPT framework. So in your case, you can choose to simply call it a BPT framework, or a BPT based hybrid framework or something on similar lines.

Features of a Hybrid Framework

In this section, you would see some of the features that you can be implemented as part of your hybrid framework. Some of these features are pretty common and you would see them being used in many different hybrid frameworks. There would be other features also that are not so important and can be termed as nice to have (but not mandatory). Let us see some of these important features.

1.) The most basic set of features come first. The hybrid framework should be designed in such a way that it is re-usable and easily scalable. Also, the code should be easy to understand and maintain. As a matter of fact, please don’t consider this point as a feature. It is a must-have and you should consider it a rule. Doing this would save you a lot of troubles afterwards.

2.) All the components in the framework can be grouped separately. You can employ a basic folder structure to keep the test cases, function libraries, data sheets and test results grouped together in an efficient manner.

3.) One click execution. This is a good feature that you can implement in your automation framework. With just a single click of a button, the framework should execute all the test cases. In most of the cases, this feature is implement using MS excel + macros. This is because the excel sheets provide you with more control on how you can select your test cases.

4.) Another important point is how you display your test results. You should aim to display the test results at minimum 2 different levels of abstraction. These are – summarized report and detailed report. A summarized report can simply be an excel sheet that provides the list of the test cases that were executed, whether they passed or failed, and a link pointing towards the detailed report for each of  the test cases. You can also add more parameters to this report if required. An example of a summarized report is shown in the below image.

A detailed report would be the actual QTP result which you would have saved in appropriate result folders. The detailed report will mostly be used for investigative purpose. For example, in case a test script fails, or it takes more than expected time for completion, you can open the detailed result and try to find out the exact cause for the issue.

5.) Automated Email Notification. This is another important feature that you can incorporate in your automation framework. This is especially useful when you execute your test scripts in batch execution mode. You can write some logic in your framework that will automatically send emails to intended recipients after the completion of the batch run. You can also include the summarized excel report as an attachment in the email.

6.) Automated SMS Notification. This can be considered as an extension of the above point. Here, you can have your framework send an SMS to a select list of people with the test execution status.

If you intend to use this feature, then please keep in mind that the messages that you send should be short and crisp. For example, you could send something like this as an SMS – “TCs executed-100. Passed-85. Failed-15.”

Also, please note that this feature is used very rarely. So from the usability point of view, its very difficult justify the use or need of sending SMSes. Also you would need to factor in the cost of sending SMSes.

A scenario where sending SMS can be useful: You can configure your framework to send an SMS to certain people when, say 5 or 10 consecutive test cases fail one after the other. Such a scenario normally indicates that there is some big issue going on. Maybe the environment went down, or some other problem. Having an SMS sent in such a situation can help the teams identify the issue in a more timely manner.

7.) Framework should be externally configurable to a certain extent. This is a nice feature that I have started using recently. The idea behind this feature is – there should be certain functionalities in your framework that you should be able to configure without having to touch the code. Consider the following scenarios as examples –

• a) Consider a case that on a particular day, the test environment is pretty slow. This requires you to increase the default load time of the pages. Your framework should provide a provision to do this easily for all the test cases.
• b) Consider another situation where you need to modify the details of the people to whom the email should be sent. Or maybe you don’t want to send email for a particular batch run. You framework should provide you a means with which you should be able to do these tasks without touching the code.

The best way to create an externally configurable sheet is to use an excel sheet. The below image shows an example of such a sheet.

8.) Intermediate Status Reports. This is another nice to have feature that you can incorporate in your automation framework. Consider a scenario where you have set up a batch execution of 100 test cases. Its obvious that you wouldn’t be sitting in front of your system all the time to monitor the execution. Suppose you move away from your desk and come back to see the execution after say, 1 hour.

At this point the test cases might still be executing but you would not know how much more time your scripts will take to execute or maybe how many test cases are still pending. In such situations, intermediate status reports come in handy.

Intermediate status report can be as simple as a auto-closing popup that appears after the execution of each test case, gives you the updates and closes automatically (in 3 to 5 seconds). A simple message like the one shown below will be more than enough.

These were some of the features that you can incorporate in your automation framework. It’s not necessary that you add all the features at once. A good approach would be create the framework with the minimum necessary features. And then you can add these nice-to-have features to your framework as enhancements.

In the upcoming articles in this series, we will create a hybrid framework from scratch where we will be incorporating some of these features. Please note that we will not be adding all the features to the sample framework as it leads to code complexity. The goal of the upcoming articles would be to keep the framework creation process as simple as possible, so that it is easily understood by everyone.

Over to you

This was all about the basics of hybrid framework and some cool features that can be implemented as part of this framework. We are waiting to hear your thoughts on these. Did you find this article helpful? Did you find the features interesting? Was there any feature that you were not aware about? Or something that you have seen or used but is not mentioned here? You can let us know your thoughts using the comments section.

Visit QTP Frameworks Main Page for more articles on QTP Frameworks. You can also visit our QTP Tutorials page for more QTP Tutorials.

The post Hybrid Framework in QTP – The Basics appeared first on XX.