Tips for doing effective QTP script Development

  1. Read the Requirements completely and repeatedly till understanding it clearly without any ambiguity. It is better to create own automation testcase/requirement based on the manual test cases or business requirement document.
  2. Highlight or make note of key requirements in the requirement document. And, highlight the points that are difficult to understand.
  3. Don’t hesitate to approach the developer/customer/client if you need any clarification in the requirement and also don’t hesitate to inform if any of the requirements is unrealistic. Prepare a list of requirements or test cases which can not be automated.
  4. QTP Script development Team also should participate in the requirement analysis before starting any application development activity. QTP team can give suggestions (e.g giving unique name/id for each window so that object identification problem can be avoided when creating QTP scripts) for the application development Team for improving effectiveness of the QTP script development.
  5. Start working on coding/scripting part only after getting clear understanding of the overall Design of the system
  6. Enforce Review and Walk Through Activities.
  7. Try to setup Development Environment similar to production environment. Otherwise you will face lot of difficulties while running the QTP script against the production application once after completing your script development using development/testing application.
  1. Do unit testing immediately after developing each small functionality.
  2. Give updates of the progress to the client/customer frequently. If you are facing any difficulty/issue remember to specify in the updates.
  3. Make list of things that will vary from Development Environment and Production environment
  4. Prepare a user guide document and deliver it along with code.

 

QTP methods and script for reading object properties

In the previous Chapter, I had written about Object Spy.

For using Object Spy, we need to point the Object Spy pointer on the Object.
i-e We can read the properties manually only. And it can be done in the design time only.
In this post, I am going to write about reading the properties of any Object in the application using scripting (i-e programmatically in run-time)

QTP is having below methods.

GetTOProperty– This method returns the value of the property from the test object’s description, i.e., the value used by QTP to identify the object. In other words the list of properties stored the Object Repository. If the property is not part of the test object’s description, a warning will be issued by QTP.

GetTOProperties – This method is similar to GetTOProperty, but it will list all/collection of properties and their values.

It can be used as below to get all the Test Object properties and their values in “Submit” button of “Login” window in a vb application.

Set theTestObject = VbWindow(“Login”).VbButton(“Submit”)

Set Props = theTestObject.GetTOProperties

PropsCount = Props.Count

For i = 0 To PropsCount – 1

PropName = Props(i).Name

PropValue = Props(i).Value

MsgBox PropName & ” = ” & PropValue

Next

Set theTestObject = VbWindow(“Login”).VbButton(“Submit”)
Set Props = theTestObject.GetTOProperties
PropsCount = Props.Count
For i = 0 To PropsCount – 1
PropName = Props(i).Name
PropValue = Props(i).Value
MsgBox PropName & ” = ” & PropValue
Next

GetROProperty – It will be used to get the value of an object property during runtime, such as the current list/combo item selection, page title, or the text in a WebEdit, or the size (width & height) of an object.

SetTOProperty changes the value of a test object property. Changing the property won’t make any change in the Object Repository, but it will just affect the way QTP identifies the object during runtime. Actually, this changes the properties of the temporary copy of the object stored in RAM by QTP.

i-e QTP is having the methods GetTOProperty,GetTOProperties and SetTOProperty for handing Test Objects.

And, it is having SetTOProperty method for handing Run-time object.
Obviously it can not have method SetROproperty, because QTP script should not change the actual objects (But still we can do it using “Object”. I will write a separate post about it later)

But it can have a method something like getROproperties. As of now, QTP is not having such a method.

So, we can read all RO properties from windows registry.
For example, below piece of code can read the name of properties for “Page” object from the registry.

Const HKEY_LOCAL_MACHINE = &H80000002

Set oReg = GetObject(“winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv”)

SKeyPath = “SOFTWARE\Mercury Interactive\QuickTest Professional\MicTest\Test Objects\page\Properties”

oReg.EnumValues HKEY_LOCAL_MACHINE, sKeyPath, arrNames

sNames = “List of Properties:” & vbNewLine

For i = 0 to UBound(arrNames)

sNames = sNames & arrNames(i) & vbNewLine

Next

Const HKEY_LOCAL_MACHINE = &H80000002
Set oReg = GetObject(“winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv”)
sKeyPath = “SOFTWARE\Mercury Interactive\QuickTest Professional\MicTest\Test Objects\page\Properties”
oReg.EnumValues HKEY_LOCAL_MACHINE, sKeyPath, arrNames
sNames = “List of Properties:” & vbNewLine
For i = 0 to UBound(arrNames)
sNames = sNames & arrNames(i) & vbNewLine
Next

After reading the properties, the script can read each property name from the array “arrNames” and get the run-time object value using GetROproperty method.You can refer below piece of code.

Set TestPage = Browser(“Google”).Page(“qualitypoint”)

For i = 0 to UBound(arrNames)

sNamesRO = sNamesRO & arrNames(i) & “: ” & TestPage.GetROProperty(arrNames(i)) & vbNewLine

Next

MsgBox sNamesRO

Object Spy in QTP

QTP is having a Tool called as “Object Spy” for viewing the properties and methods of any object in an open application.

We can use the Object Spy pointer (a button with hand symbol) to point to an object in the application.

 

 

Object Spy Dialog window is having Two Tabs. One is “Properties Tab” and another is “Methods Tab“.

Each tab is having radio button to choose one of two options “Run-Time Object” and “Test Object”.

The Object Spy displays the selected object’s hierarchy tree and its properties and values in the Properties tab of the Object Spy Dialog box.

The Object Spy enables you to view both the run-time object methods and the test object methods associated with an object in the Methods tab of the Object Spy dialog box.

And, we can to view the syntax for a selected method.

We can bring the “Object Spy” by clicking the Tools->Object Spy… menu or by clicking a toolbar button (an icon showing a person with hat). This icon can be accessed from Object Repository window also.

To see the properties of an object, first click on the button showing hand symbol in the Object spy Dialog.

The mouse pointer now changes in to a hand symbol and we have to point out the object to spy the details about the object.

If the required object is not visible, or window is minimized then hold the Ctrl Key and activate the required window to bring the required window to the front.

Then release the Ctrl button to make the cursor again hands symbol so that you can point the required object.

You can watch the below Video explaining Object Spy.

Managing Object Repositories in QTP

QTP is having separate window named as “Object Repository Manager” for managing various object repositories.

You can open this window from the Menu “Resources->Object Repository Manager…

The Object Repository Manager enables you to manage all of the shared object repositories used in your organization from a single, central location.
It will be used for adding and defining objects, modifying objects and their descriptions, parameterizing repositories to make them more generic, maintaining and organizing repositories, merging repositories, and importing and exporting repositories in XML format.

The Object Repository Manager window will look like below one.

 

You can create new shared repository from this window and can store it as .tsr file.

While adding objects, you will be provided with two options. Either you can choose to add only the selected Object or you can choose to add the selected object and its descendants.

You can store the object repositories  either in file system or in Quality Center project.

The Object Repository(OR) Manager enables you to open multiple shared object repositories and modify them as needed.

This Object Repository Manager provides the options such as  “Add objects”, “Highlight in Application”,  and “Locate in Repository”  for the Shared object repository. It is similar to the local object repository. I will be explaining them in separate post.

By default this OR Manager will be in readonly mode. i-e you can not edit anything in this mode.

We need to choose File>Enable Editing for making it editable.

Update from Local Repository option in the OR Manager (Tools > Update from Local Repository) can be used for merging objects from the local object repository of one or more actions to a shared object repository.

And, it provides Object Repository Merge Tool for merging two shared object repositories.

At the end of the merge process, the Object Repository Merge Tool provides a graphic presentation of the original objects in both repositories, which remain unchanged, as well as the objects in the merged target object repository.

Objects that had conflicts are highlighted. The conflict of each object that you select in the target object repository is described in detail. The Object Repository Merge Tool provides specific options that enable you to keep the suggested resolution for each conflict, or modify each conflict resolution individually, according to your requirements.

And note that while the Object Repository Merge Tool is open, you cannot work with the Object Repository Manager.

Apart from this OR Manager, QTP is having “Associate Repositories” option for  enabling you to associate one or more shared object repositories with one or more actions in a test.

 

Descriptive Programming in QTP

Instead of using Object Repository for storing properties of Test objects, we can straight-away define the properties while writing the script itself.

It can be done in two ways.

One is, by giving the description in form of the string arguments.

For example a text box having html code as <input type=”text” name=”txtUser”> can be accessed as below.

Browser(“Browser”).Page(“Page”).WebEdit(“Name:=txtUser”,”html tag:=INPUT”).set “QualityPoint”.

The other way is using Decription.create as below.

Set objDesc = Description.Create

objDesc(“html tag”).value= “INPUT”

objDesc(“name”).value= “txtUser”

Browser(“Browser”).Page(“Page”).WebEdit(objDesc).set “QualityPoint”.

This Descriptive approach is having some short-comings.

The main disadvantage of Descriptive programming is Maintenance issue.
Since Object repository will be stored in centralized place, property definition for any Object can be easily changed at any time if the application developer changes the property of the actual object/control.

But, in descriptive programming (DP) it is difficult to change the object property as each QTP developer will be defining object property in many places using DP.

For example, assume that you and team member are developing automation test scripts for testing gmail application.
Gmail login script will be used in many test scenarios.

Assume that you are automating some scenarios and your team member is automating some other scenarios.
In case of Object Repository, you and your team member will be forced to use same object description for login page controls/Objects (e.g username, password, login button).

So in future if Google changes any property (e.g change the button name from “login” to “get into gmail”), all the scenarios can be easily updated just by updating this change in Object repository.

But in case of DP, there is a possibility of defining the login button in multiple places. One definition by you and another by your team. (Anyway proper Team Coordination will avoid this issue, but practically it is very difficult to achieve this coordination.).

So, comparatively updating DP style coding is bit difficult if the application properties got changed.

Anyway, Descriptive programming is having its own advantages as mentioned below.

1. We can start work on writing QTP scripts even before the application under Test is NOT available. It will help to increase the utilization of the Automation scripts as it will be immediately available once the application gets released.

2. We can define the properties of an object without considering the parent objects in the hierarchy. i-e Object identification will not depend on its parent object.

KeyWord Driven Testing and Framework in QTP

Keyword-driven testing is a Software testing technique that separates much of the programming work from the actual test steps so that the test steps can be developed earlier and can often be maintained with only minor updates, even when the application or testing needs change significantly.

In case of keyword driven testing, we need to do proper planning and initial huge effort. Anyway it will give benefit of easy maintenance and easily adding more test cases/scenarios.

As we see the keyword view in QTP IDE, the keyword driven testing involves specifying the test steps in below format
Object  Action  parameter
e.g
Browser(“FireFox”).Page(“QualityPointHome”).webEdit(“username”).Set “QualityPoint”

Here,

->Browser(“FireFox”).Page(“QualityPointHome”).webEdit(“username”) is the Object.
->”Set” is the Action.
->”QualityPoint” is the parameter.

Here we can change any of the three things to create test steps.
The Keyword Driven framework consists of the basic components given below

1. Control File
2. Test Case File
3. Startup Script
4. Driver Script
5. Utility Script

1. Control File

a) Consists details of all the Test scenarios to be automated.
b) User will be able to select a specific scenario to execute based on
turning on or off a flag in the Control File.
c) Control File is in the form of an excel worksheet and contains columns
for Scenario ID, Execute (Y/N), Object Repository Path, Test Case File
Path.

2. Test Case File
a) Contains the detailed steps to be carried out for the execution of a test
case
b) It is also in the form of an excel sheet and contains columns for
Keyword, Object Name, Parameter

3. Startup Script
a) The Startup script is utilised for the initialization and reads the control files.
b) It then calls the driver script to execute all the scenarios marked for execution in the control file.

4. Driver Script

a) It Reads the Test Case files. Checks the keywords and calls the appropriate utility script functions based on specific keyword
b) Error Handling is taken care of in the driver script.

5. Utility Scripts

a) Perform generic tasks that can be used across applications.

Advantage of keyword Driven Framework.

• The main advantage of this framework is the low cost for maintenance. If there is change to any test case then only the Test Case File needs to be updated and the Driver Script and Startup script will remain the same.
• No need to update the scripts in case of changes to the application.
The framework design will  be purely based on your requirements and your way of thinking. There is no Solid rule to follow.

Personally, I would like to have my own framework (hybrid framework) designed according to my own requirements.
Anyway, the best practice is, we should create below sub folders in your root folder.

ObjectRepository-> To keep your shared object repositories.
Datatables->To keep QTP data tables and external Excel sheets.
Config-> To keep environment variable xml file
RecoveryScenario ->To keep your recovery scenario files.
Tests-> You can keep your QTP Tests here. You may include Test containing Reusable Actions here. And a Test which is getting used as driver script can also be stored here.
library->you can keep your vbs file which contains vbscript functions.
Results-> You can store Result files (Either QTP result file or customized result file) here.
Actually there won’t be any solid rules/approach for creating QTP framework.

Scheduling QTP Script Execution

Once after successfully completing dry run of QTP scripts there is no need to monitor the script execution.

We can schedule the script execution during night time also.
Scheduling can be done easily using window task scheduler for starting the execution of QTP script automatically at a predefined time.

For doing scheduling, we need to create .vbs file.

The Important steps required for scheduling are,

– Create a Driver script which calls all the scripts one by one.
– Complete Dry run to make sure script will continue execution without any interruption. Add Recovery scenario for handling any unexpected pop-up window or any other inconsistent behavior of the application under test.
– Create a .vbs file which will be used for starting the QTP using Automation Object Model. Remember to add the code for keeping settings/options of the QTP so that the scheduler will open QTP with same settings.

you can refer the below sample vbscript code for creating the .vbs file to be called from the scheduler.

‘Declare the Application object variable

Dim qtApp As QuickTest.Application

 ‘Declare a Test object variable
Dim qtTest As QuickTest.Test

‘ Declare a Run Results Options object variable
Dim qtResultsOpt As QuickTest.RunResultsOptions

 ‘ Create the Application object
Set qtApp = CreateObject(“QuickTest.Application”)

‘ Start QuickTest
qtApp.Launch
qtApp.Visible = True

 ‘Open the test in read-only mode. Include your driver script here.
qtApp.Open “C:\Tests\Test1”, True

 ‘ Create the Run Results Options object
Set qtResultsOpt = CreateObject(“QuickTest.RunResultsOptions”)

‘ Set the results location

qtResultsOpt.ResultsLocation = “C:\Tests\Test1\Res1”

‘ Run the test
qtTest.Run qtResultsOpt

The complete code and details can be found in the QTP help file for Automation Object Model.The next step is we should merge the code for QTP options/settings within this code.The options/settings code can be easily generated automatically.
Click Tools->Options from QTP IDE to open the below screen.

Click “generate” in the above screen to automatically generate the code.
– Then add a task in windows scheduler for calling the .vbs file.
You can do it by using Schedule Task wizard from settings->control panel->Scheduled Tasks->Add Scheduled Task
Click “Browse” in the below screen of the wizard to set specify your .vbs file.

– Locking the system while running the script will affect the script running.So don’t lock your machine while running the script. Anyway, you can add the below code at end of your .vbs file to lock the system automatically once after completing execution of the script.

Set obj = CreateObject("WScript.Shell")
sCmnd = "%windir%\SYSTEM32\rundll32.exe user32.dll,LockWorkStation"
obj.Run sCmnd, 0, False

 

Best Practices in QTP Automation

  • Start your automation work only when AUT (Application Under Test) is stable. i-e You should have completed initial round of manual testing before starting QTP automation task.
  • Use reusable actions wherever possible. And, Functional libraries should be used to include the vbscript functions so that maintenance of vbscript functions is easy.
  • Don’t copy and paste checkpoints when you wish to check same thing in more than one places. Instead, create separate checkpoints. Because manipulating checkpoints in QTP is not feasible or it will be difficult.
  • Open browser/application after opening QTP.
  • Your vbscript functions should not have any hard coded object names, the name of the objects should be passed as function argument.
  • Use Shared Object Repository. My suggestion is, don’t use DP (Descriptive Programming) which will increase your maintenance work.
  • Before adding any object to Object Repository, set up appropriate object identification properties (in Tools->ObjectIdentification) if you feel that default identification properties are not suitable for you application. If you do it after adding some objects to the Object Repository then you may face issues related to having multiple Test objects in Object Repository for a single actual Object.
  • Open QTP using Automation object model. You can do it just by writing (even you are having ‘generate script’ option in the QTP IDE itself) simple .vbs file, and then open QTP just by double clicking this .vbs file. It is very essential if you are developing your scripts in one machine/environment and planning to run/execute it in another environment. By using Automation Object model we are making sure that all the IDE settings (e.g Object identification properties) that are changed in development environment are propagated to the execution environment also
  • Always use Reference/Relative path when calling any external reusable action instead of using absolute/full path, Otherwise the script will fail when placing it in different path.
  • Remember to take backup of Object Repositories before merging object repositories.
  • Put proper inline comments and also put summary comments (description, input & output parameters, dependency, and author) at beginning of the Test. In the comments remember to mention about execution/data flow.
  • Rename the Objects in Object Repository to have proper meaning for them. Because the default name given by adding the objects by recording or manually may not be good/meaningful.
  • Give attention to synchronization (i-e use of sync,waitproperty, exist). And also use regular expression wherever required. Otherwise consistency of script execution will be affected.
  • Use recovery scenario to handle any unexpected behaviour (e.g showing pop-up windows sometimes) of the application.

Required Steps/Processes in QTP Automation

  • Before starting actual automation task, we should do tool evaluation and feasibility study to make sure QTP is the appropriate tool for automating test cases of our application. It can be done by selecting few sample modules/screens/flow from the application/test cases and create simple QTP scripts to make sure QTP will recognize the objects in our application
  • As part of Test driven development, we can ask the application development team to give proper name or any other identification properties for the objects, if our feasibility study reveals some difficulty for QTP to recognize the objects.
  • As I mentioned earlier, we should start our actual automation work only after completing some basic manual testing to make sure the application is stable and in working condition.
  • QTP developers should review the Test cases and update it to specify which test cases can be automated and which can not be automated. Because ideally it is not possible to automate all the test cases.  Difficulty in navigation or object identification issue or difficulty in verifying the result will prevent automation. If possible, the manual test cases can be rearranged to have separate automation test cases.
  • Once after reviewing all the test cases and after getting familiar with the application we can design the automation frame work for our need.
  • Keep separate instance of application specifically for the purpose of developing automation scripts. It will avoid any unnecessary mess up with manual testing processes.
  • Set up proper QTP development environment with required Add-in and with any add-in extensibility. If many people are going to involve in the development activities then we need to clearly document the responsibility of each person and the approach for sharing the scripts. If application is installed in remote machine then QTP also should be installed in remote machine. Because QTP will not recognize the objects of application in remote session.
  • Set up proper object identification properties in QTP IDE.
  • Once after completing all the above basic steps, the first development task should be adding all the required Test Objects/properties to the Object repository. It can be done by recording or by manually adding the objects to Object repository. If you specify any object using DP (Descriptive Programming) remember to document it.
  • Once after adding all the objects, rename them to have unambiguous/meaningful name.  Doing renaming from object repository will automatically change the name of the object in the script also. But reverse is not true. I-e Renaming a object from script won’t automatically change it in Object repository.
  • Based on your design of automation framework, create reusable actions and vbscript functions using step generator or keyword view or expert view or using Active screen.
  • Using these reusable actions prepare a sample/base script for executing few test cases. And then test it to make it error free.
  • Once after completing the above mentioned sample script, do parameterization (data driven testing) for executing multiple iterations.  Parametrization can be easily done from both keyword view and expert view.
  • Add checkpoints to verify the expected results. Make sure that your checkpoints will work with different data. i-e use regular expressions if some part of expected value will change based on the input data during each iteration of test execution. And, editing checkpoint in QTP is having some issues. So, take care when editing the checkpoint. Mostly changing checkpoint in one place will affect the other checkpoints also. Or, you can create your own functions for creating checkpoints.
  • Use appropriate Regular expression to make sure the script runs in all scenarios even when some properties are getting changed dynamically in particular pattern. For example if your screen page title changes based on the username of the logged in user, the script will not work correctly for all users. (By assuming that the script uses the page title for identifying the screen). You can refer the QTP help files if you don’t know how to add Regular expression.
  • Add the Recovery scenarios to handle any unexpected behavior of the application. Recovery scenario manager and wizards.
  • Use Environment variables to avoid any hard coded values in the script.
  • Do dry run for this sample script and debug the issues in the automation script and fix them.
  • Do the above steps for all the test cases.
  • Create a Driver script which will call all the test scripts. Need to take additional care about deciding whether driver script should take data from its own datasheet or whether it should read data from datatable of the called action.
  • Complete dry run for the Driver script. It is really a challenging task. Because most of the Actions within the Driver script will depend each other and it will take very long time to complete the dry run if we start the dry run from starting point every time whenever the script fails in between the execution. I will explain with one example. Assume that your driver script calls three Tests. First Test will create a user account, second will test the Profile update feature, and third one will test the user deletion feature.  And, assume that the second Test will use the user name created by First test, and the third test deletes the account created by first Test. In this scenario, if you face any difficulty while calling second test we need not always start the dry run from beginning. Since one user account was already created by first Test successfully, we can just comment out the calling of first Test and then continue the debugging of second Test using the already created account.
  • Prepare .vbs script using Automation Object Model to run the QTP scripts in other environments also with same settings. It can be easily done by using “Generate script” option in QTP IDE.
  • Run the scripts in desired environment.
  • Analyze the test results.
  • Report the bugs/defects in the application once after completing the analysis.
  • Once after completing functional testing, select few essential scripts and store them separately for the future Regression Testing.

Handling Passwords in QTP Scripts

Most of the applications/websites will require a password for getting into them.

So, automation tools such QTP should be able to handle the passwords. But anyway, it is not a good practice to keep the password as it is in the scripts.

By default QTP will encrypt the password while recording. The recorded step will look like the below statement.
Dialog(“Login”).WinEdit(“Password:”).SetSecure “49ff257067d53a774881c348da151ccf9282c2109b60”

SetSecure method will be specifically used for handling passwords.
This recording approach will be useful only when you are going to use one or few passwords in your script.

If you want to use many number of different passwords for executing many iterations, this recording approach won’t be much useful.In this case we can use password encoder utility provided by QTP.
It can be accessed from start menu (e.g Programs->Quick Test Professional->Tools->Password Encoder)
It will look like below screenshot.

We need to enter the password text, and clicking “Generate” button will provide the encoded password string.
We can put this string in the Datatable for executing multiple iterations with different passwords.
It will be useful not only for automating the testing, but also in below scenario.
– you want to allow a person available in a remote place to get into your application/site for doing some testing or for some other purpose, and you don’t want to share the password with him. In this case you can just create a QTP script to log into the application.

Some people may not be willing to store the password in the QTP script even in the encrypted form also.In this case, we can create a simple HTML form and call it from QTP script to show as a pop-up window for getting password from user while executing the Script.

It is possible to see the encrypted password in plain text format. So, don’t store your important passwords in encrypted format also. Instead of storing the password, you can create a simple HTML form and call it from QTP script to show as a pop-up window for getting password from user while executing the Script.

Below lines of code were created while recording the login window of the sample flight application using QTP.

Dialog(“Login”).WinEdit(“Agent Name:”).Set “quality”  

Dialog(“Login”).WinEdit(“Password:”).SetSecure “4ce5631fdebb5762c2878e6f8f735a9d0511b0b7”  

Dialog(“Login”).WinEdit(“Agent Name:”).Set “quality”

Dialog(“Login”).WinEdit(“Password:”).SetSecure “4ce5631fdebb5762c2878e6f8f735a9d0511b0b7”
Here we can see the encrypted value “4ce5631fdebb5762c2878e6f8f735a9d0511b0b7” for the password “mercury”
But, when I run the QTP script after just changing the code like below, I was able to see the plain text password “mercury” in the Agent Name field.

Dialog(“Login”).WinEdit(“Agent Name:”).SetSecure “4ce5631fdebb5762c2878e6f8f735a9d0511b0b7”