Introduction to QTP

Here is a compile of some learning I had on working with QTP on one of the projects, believe me, I have used a lot of tools within very small amount of time. I always had a challenge to master the tool to make the project - "test automation" project a success (at least for me). So every time, I learnt a new tool, I used to prepare such key notes that one should know to start working on the tool. Here is one for QTP, this was built on QTP 6.5 version which might be outdated now, but the core simple concepts that you need to know are still the same, so take a look,

This article covers,

QTP Architecture
ActiveX and Web addins
Basic Scripting
Running your script
Debugging your script
Data Table
Check Points
Test Director Integration
Win Runner Integration
Enterprise-wide Environment Support
Features & Benefits
Limitations

Introduction to QTP

Functional and regression test automation tool
Good for web client/server base application automation
Fairly intuitive, easy to use
Object and action based scripting tool.

Quick Test Professional provides the industry’s best solution for functional and regression test automation for practically every software application and environment. Quick Test Professional is the only functional testing solution. Quick Test Pro is an automation tool written specifically for web client/server based application automation. It is a fairly intuitive, easy to use tool that has the capability of applying scripting from simple recorded scripts, to advanced custom VB DLL integration. Quick Test is an object and action based scripting tool that allows users to easily create reusable actions that can be used for repeatable testing within the product.

Basic Functionality

Action Based - Quick Test is by nature, an ‘action’ based automation creation tool. An action within QT can be thought of like a function within any other programming language. It is how QT breaks up steps or actions within a script, such as: Login, or Navigate to Configuration Administrator. This allows each user to easily organize their scripts. There are two different ways to view the actions: Tree View, and Expert View. Tree View allows the user to see their action organized into something closely resembling a file structure. Each page and action taken upon that page drills down to a subsequent page and another resulting item. The Expert View allows the user to see the actual code used to execute their action. This is a much easier way to edit the script and code, as well as write custom code for a script; however the organization is not as easily apparent.

Object Oriented - The entire foundation of Quick Test is based off of objects. Everything within a browser is considered an object, from; tables, to frames, to links, to radio buttons. Quick Test looks at the properties for each object, and captures enough properties to uniquely identify that particular object. It will look at: HTML name, object text, height, width, index, etc.

Object repository

Holds definition and properties of each object currently know and used by the script.

Object Spy

The Object Spy is a useful tool that displays the various properties of any particular object.The Object Spy may be accessed from two different places: From within the Object Repository by clicking on the Object Spy… button, or through Tools -> Object Spy. The Object Spy is a useful tool that displays the various properties of any particular object. It will allow the user to see which properties they would like to capture, or if they need to dynamically click on a particular link (for example) they may write a function that will capture the properties from a particular object based on a shared known state.

Function library

A function library is a collection of functions and global variable assignments that can be integrated with a QuickTest test.
The function library must be in a Visual Basic Scripting formatted file. (.vbs)

A function library is a collection of functions and global variable assignments that can be integrated with a QuickTest test. It is an easy way to define commonly repeatable actions and variables in a centralized source. Using a function library greatly increases the ease of maintenance in the essence that code and variables may be changed in one centralized location, instead of every test. (For example; the URL to the server, or the path to IE or another browser.)

The function library must be in a Visual Basic Scripting formatted file. (.vbs) The format must be written in VB, though many of the Quick Test functionality can be recognized and used in the library.

In order to connect a client Quick Test machine to a function library, please follow the below steps:

In a new or existing test, navigate to Test -> Test Settings -> Resources tab
Click the green + button, and enter the full path, including the filename to the function library.
In order to have each new test automatically use this function library in the future, click the Set as Default button
Click OK
Each new test created will now use that function library defined in the settings dialog.

To remove a function library association, simply navigate back to the Test Settings dialog, select the library you wish to disassociate, and click the red X button.

Note: You may associate multiple library files with each test.

Scripting language

Visual Basic Language Structure
Quick Test uses a supplemented version of the Visual Basic language as its scripting language

ActiveX and Web addins

Various Add-in are available like ActiveX, Multimedia, VB and Web, to test various environments

E.g. the Web Add-in is necessary so that Quick Test may insert its hooks into the various browsers that are supported by the web application. It must be selected as an add-in when Quick Test first starts up. In order for Quick Test to recognize the objects in a particular browser, the browser must be launched after the instance of Quick Test has been opened. QT cannot insert its object hooks into a pre-existing browser session

Test Case automation

Recording the script
Reading the script
Running the script
Debugging the script

Recording a script

Navigate to the QuickTest window, and click on the “Record” Button:
If this is the first time recording within a new test, the user will be prompted with the Record and Run Options dialog. Choose the option to Record and Run the test on any open web browser. (To access these settings after the initial recording, go to: Test -> Record and Run Settings)
Click OK, then click on the browser window, and log into the product.
Navigate back to the QuickTest window and click the Stop button. This will be your first action.
Give the action name start recording steps. You may also select to convert this action to a reusable action, so that you may just call this particular action each time you wish to add a login action to a script
The Expert View is available for advanced users who would like to create custom VB code to insert into their script

Every script designed and written, must have been designed and written with modularity in mind. Each script should be able to be run on its own, apart from all of the other scripts. This allows for subsets of scripts to be run much more easily, without worrying about data prerequisites.

To record: Navigate to the QuickTest window, and click on the “Record” Button: If this is the first time recording within a new test, the user will be prompted with the Record and Run Options dialog. Choose the option to Record and Run the test on any open web browser. (To access these settings after the initial recording, go to: Test -> Record and Run Settings)

Reading the script

As mentioned above, there are two different ways to read a script that has just been created. A user may view the script in the action based Tree View, or may view the code itself in the Expert View. Below is an example of a script that was freshly recorded, with no modifications shown in the Tree View. This particular script logs into Concur Expense and navigates to Configuration Administrator.

Note the way that the two actions have been drilled down according to their hierarchy: Action -> Browser -> Site/Page -> HTML Frame -> Action.

The code will be visible directly through the Expert View. Since the two execution actions have been broken up among two separate actions, the user will need to select which action to view from the action drop-down at the top of the expert view. Above is an example of a more complicated script, which was written by hand in the Expert View. This example shows how the different types of methods and calls are interpreted by the Tree View. (This code happens to be the table traversing solution notated in section G.)
Note the different icons for each action. The yellow bubble icon denotes a comment. The double quotation icon denotes a specific VB call (In these cases variable declaration and a loop break). The red to green arrow indicates an object or variable association, etc.

Running the script

Running the script Ensure that no other browser windows are open
Ensure that a call to open a browser at a specific URL is the first item executed in the test

Click the Run button at the top of the QuickTest window At the Run prompt, select either the default temporary run results folder, or a folder of your choice: When OK is clicked the test will begin executing. Follow the test execution on the client machine. The results will be reported back to test director or to the results directory specified.

Debugging the script

QuickTest allows a few variations of stepping through code, line by line. The three variants are:

Step Into: This allows a literal line by line execution of the code.
Step Over: Step Over will skip over the currently queued line of code, and will execute the subsequent line.
Step Out: Step Out will run to the end of the called action or user-defined function, then returns to the calling action and pauses the test run.

Script debugging is inevitable for every script written in QuickTest. There will be an instance in which an additional step is necessary for a recorded script, or to debug and test custom written code. QuickTest has fairly robust debugging tools, from breakpoints, to a real-time expression – variables – and command monitoring interface.

Step Into - These step commands are extremely useful in the essence that they will allow the user to step through each line of code to determine exactly where the problem is, and to verify that each line of code works on a line by line basis. This can be very useful when writing complicated nested statements.

Debugger

The debugger window is a way to monitor current variable assignments, expression progress and various command sequences. In order to use the debugger, select the icon at the top toolbar: and the user will see the portion of the debug window display in the lower right hand corner of the QuickTest application.

The debugger can be used with both the Expert View and the Tree View, when stepping through the code using one of the three Step commands. The most common use for the debug dialog is to monitor variable assignments to ensure that the variables are being assigned correctly and to monitor whether or not comparisons are functioning correctly etc. Below is a brief example of the variable assignments, halfway through the table traversing script:

The name of the variable in the code is listed in the left hand column, and its associated value in the right. A variable value of Empty denotes a NULL value.

Data table - parameterization

Stores test data

To edit the Data Table:
Open your test. Make sure the Data Table button is enabled.
Each row in the table represents the set of values that QuickTest submits for the parameterized arguments during a single iteration of the test or action. QuickTest runs the iterations of your action based on the settings selected in the Run tab of the Action Properties dialog box. The number of iterations that a test runs is equal to the number of rows in the Global sheet.
Each column in the table represents the list of values for a single parameterized argument. The column header is the parameter name.

You can insert Data Table parameters and output values into your test so that it will run several times on different sets of data. Each test run on a different set of data is called an iteration. Data table is basically used for data driven test cases. The data your test uses is stored in the design-time Data Table, which is displayed in the Data Table at the bottom of the screen while you create and edit your test. The Data Table has the characteristics of a Microsoft Excel spreadsheet, meaning that you can also execute mathematical formulas within the cells.

There are 2 types of Data table for each script

Global Data table
Local/Action Data table

There is single Global data table for each script.The Global sheet contains the data which is shared by all Actions. The Global sheet look like this:

Checkpoints

QuickTest Professional can automatically introduce checkpoints to verify specific Web page characteristics, such as links and load times. In addition, during test execution testers can insert several types of checkpoints to verify that objects, as well as database values, continue to behave as expected

Checkpoint Type	Description	Example of Use
Standard Checkpoint	Checks values of an object’s properties	Check that a radio button is selected.
Image Checkpoint	Checks the property values of an image	Check that the image source file is correct.
Table Checkpoint	Checks information in a table	Check that the value in a table cell is correct.
Page checkpoint	Checks the characteristics of a Web page	Check how long a Web page takes to load or if a Web page contains broken links.
Text / Text Area Checkpoint	Checks that a text string is displayed in the appropriate place in a Web page or application window	Check whether the expected text string is displayed in the expected location on a Web page or dialog box.
Bitmap Checkpoint	Checks an area of a Web page or application after capturing it as a bitmap	Check that a Web page (or any portion of it) is displayed as expected.
Database Checkpoint	Checks the contents of databases accessed by an application or Web site	Check that the value in a database query is correct.
Accessibility Checkpoint	Identifies areas of a Web site to check for Section 508 compliance	Check if the images on a Web page include ALT properties, required by the W3C Web Content Accessibility Guidelines.
XML Checkpoint	Checks the data content of XML documents	Note: XML file checkpoints are used to check a specified XML file; XML application checkpoints are used to check an XML document within a Web page.

Example, standard checkpoint to verify a particular screen is displayed

Test Director Integration

Test director is test management tool by Mercury. Test cases are stored along with automation script for that case. You can associate your Quick test script directly to test case present in Test Director.

Winrunner Integration

QuickTest does have the ability to integrate with Win Runner. Quick Test can call Win Runner tests and functions, as long as a licensed copy of Win Runner is installed on the client machine.

QTP environment support

QuickTest Professional supports practically any application in your Company, whether built on theoldest or the newest technology.

Core Environments

Windows applications (MFC)
Visual Basic
Java
ActiveX

Enterprise Applications

SAP
Siebel
PeopleSoft
Oracle

Web Technologies

HTML
DHTML
JavaScript

Browsers

Internet Explorer
Netscape
AOL

Emerging Technologies

.Net winforms, webforms, web services
J2EE Web services
XML, WSDL, UDDI

Server Technologies

Oracle
Microsoft
IBM
BEA
ODBC
COM / COM+

Multimedia

Flash
RealAudio/RealVideo
Windows Media Player

Key features and benefits:

Ensure an immediate return on investment through ease of use and pre-configured environment support: QuickTest Professional's integration of ActiveScreen, TreeView and the Data Table ensures that minimal time and effort are required for developing a powerful test suite and obtaining immediate results. As a result, even novice testers are productive as soon as they start using the tools.
Easily maintain scripts with using the revolutionary Keyword View and TestGuard technology: QuickTest Professional supports full flexibility of the test script to handle changes in the objects, in the tested application’s GUI and in the testing environment. Test scripts are reusable throughout an application’s lifecycle. In addition, you can painlessly update multiple test scripts using the Shared Object Repository.
Facilitate collaboration among testing groups enterprise-wide, with reusable test modules and function libraries: By using QuickTest Professional, testers can access a centralized repository and easily share actions, functions and test scripts across the network and enterprise.
Enable testing of mixed environments and applications: QuickTest Professional provides a multifunctional solution for testing dynamically changing Web, Java, ERP/CRM and multimedia content across environments.
Leverage investments in other automated testing tools: Mercury WinRunner (functional testing) and Mercury Quality Management (formerly TestDirector) our global test management product both integrate with QuickTest Professional. QuickTest Professional can launch WinRunner to execute TSL test scripts and view the results of those scripts. By doing so, companies can leverage their existing WinRunner TSL script and function libraries. Furthermore, QuickTest Professional can store its scripts and test results in Quality Management, enabling an entire QA and development team to effectively collaborate to improve application quality.

Additional key features and benefits include

Enable thorough validation of applications through a full complement of checkpoints.
Data-drive every object, method, checkpoint, and output value via the integrated data table.
Offer automation experts full control of underlying VBScript test code.
Can create and implement the Microsoft Object Model (Outlook objects, ADO objects, FileSystem objects, supports DOM, WSH, etc.)
Ease of use, Simple interface

Limitations

Currently there are fewer resources (consultants and expertise) available due to QTP being a newer product on the market
Must know VBScript in order to program at all
Must be able to program in VBScript in order to implement the real advance testing tasks and to handle very dynamic situations
The Object Repository (OR) and “testing environment” (paths, folders, function libraries, OR) can be difficult to understand and implement initially