Envision-Edge QTP Forum - The Process Guidance Description

    By Rinki Guchhait

    QuickTest automation testing can be carried out by following six main phases. Each phase is defined in brief below.

    1. Automation Test Planning & Analysis

    Automation Test planning initiates with analyzing application under test and determine testing needs. Creating a baseline for complete automation testing phase including in and out of scope, features for testing, resources needs, test data, tool feasibility, software requirements etc. The main objectives of analyzing AUT are given below.
    • A tool feasibility study is done with an analysis of application under test development environments as Java, .Net etc., and if any specific add-ins are required to load using QTP.
    • Understand clearly the customer’s business process and functionality which ensures that automation testing is directly aligned with customer’s specific objectives
    • Understand the repeatable business functionalities throughout the test application and define a methodology to implement proper code re-usability for a better outcome and consistency. This may help in defining automation testing framework to adopt whether action based approach, modular approach, functional decomposition methodology or explicit data driven approach.
    An automation testing common automation model is shown in below diagram. This demonstrates a test management tool (HPQC) in integration with an automation test tool (HPQTP).

    2. Design Test Suite/Bed

    Based on conclusions after planning and analysis, create all the required resources and infrastructure accordingly. This includes the technical aspects such as Test Scenarios, Test cases, minimal re-usable business components, functions and libraries, test object repositories, test data extraction and usage definitions etc. Also ensure that high level/common setting is explicit from the whole test bed structure, which gives more feasibility, ex. Application URLs, automation folder structures etc. A simple prototype is placed below to get an idea of automation test bed, for driver QTP.

    3. Script Recording/Designing

    Record the application as per the test scenarios defined. This also can be achieved by following scripting. QuickTest graphically displays each step you perform in the form of a collapsible icon-based test tree in keyword view and a script in expert view pane. A step is any user action that causes or makes an operation in test application, such as clicking a link or image, or entering data in a form. Test scripts are expected to follow proper naming conventions to avoid complexity in long run testing process.

    4. Test Enhancements

    Script enhancement includes modifications and updates to the recorded/initially designed scenarios. Such as adding validation check points, parameterizations, iterations, conditional statements looping, re-usable script, maintaining libraries and sub-routines and gathering reports and results etc. A checkpoint is a validation point which ensures specific values of a page / test objects are loaded, which reports application is functioning as expected.
    Note: Checkpoints can be added to a test as you record it or after the fact via the Active Screen. It is much easier and faster to add the checkpoints during the recording process.

    5. Debugging Tests

    QuickTest provides an integrated debugging utility which enables us to identify and rectify errors in the script after enhancements. Debugging ensures scripts operate smoothly without any interruptions. Once debugging of a script is done, those tests can be executed to check the application behavior for real time.

    6. Test Results & Reports

    Once all the tests are executed, engineering team needs to examine test results to pinpoint defects and variations in the application behavior. Identify the areas where in application behaved against its expectations and thus, consolidate all the results and report to corresponding stakeholders.

    Envision-Edge - How Parameterization is handled in QTP?

    By Rinki Guchhait

    QuickTest provides an integrated spreadsheet, where in one can enter test data naming column names as parameter. This spreadsheet follows full functionality of MS Excel, to manipulate data sets and create multiple test iterations, without programming, to expand test case coverage. Data can be typed in or imported from databases, external spreadsheets, or text files etc.
    Automation testing broadly focuses on complex and repeatable functionalities of Application Under Test (AUT). Very often we maintain test data in either data bases or Microsoft Excel files. QuickTest also provides an integrated spreadsheets utility, where in one can enter test data with different column as parameter. These spreadsheets follow full functionality of MS Excel, to manipulate data sets and create multiple test iterations, with and/or without programming, to expand test case coverage. These inbuilt spreadsheets are termed as DataTable feature in QuickTest Pro. Data can be typed into/ imported/exported from databases, external spreadsheets, or text files etc. This blog provides you in detail on how does parameterization functionality are carried out in using QuickTest Pro.

    Types of DataTable:

    Design Time DataTable: The data sheet that is used while designing a new script is termed as Design Time data table. This data sheet be unaltered after execution of the script, although there have been multiple operations done over the data sheet during the script run.

    Runtime DataTable:

    The data table that is used while running the tests is termed as Runtime DataTable. The data in the runtime data table is the same as that of design time data table including data changes due to script operations. The runtime data table can be seen in the Test Results window when run session is ended.
    Note: If any changes happen in run-time data table is available only in run-time data table, which can be accessible only through then test result.
    QuickTest Pro has two spread sheets by default:
    • Global sheet – Data accessible to all the scripts and actions in a test.
    • Local sheet – Data accessible specific to the action/a block of code in a test

    DataTable Parameters:

    Each column in global/local sheet of datatable is called a Parameter. We can rename the parameter just by double clicking on the column header and giving the name to it. Data can be entered in the column/parameter simply by clicking on the cell and entering the value.

    Parameterizing a Test:

    Initially when a script is recorded or scripted, it be for a single iteration of given sets of data in the script. This kind of data is termed as ‘Hard Coded Data’ which is not recommended in automation testing, and expected to use external data for multiple iteration purpose. Adding parameters to pull values from data tables and using those in the script while execution is called Parameterization. A look on how parameters are added in a sheet and used in script is shown below.


    • DataTable.Value(“username”,”Action1”) for “username” parameter
    • DataTable.Value(“password”,”Action1”) for “username” parameter

    DataTable Methods:

    Some methods that are applicable for DataTable object in QuickTest are gathered below





    Adds the specified sheet to the run time data table



    Deletes the specified sheet from the run time data table



    Exports the complete data table to the specified path



    Exports the current sheet to the specified path

    DataTable.ExportSheet “Path”,1


    Retrieves the current row number of the global data sheet



    Retrieves the number of rows in the longest column in the first sheet(global data sheet) in the run time data table

    Rowcount=DataTable.Get Sheet(“SheetName”).GetRowCount


    Retrieves the specified sheet in the run time data table



    Retrieves the total number of sheets in the run time data table



    Import the specified Microsoft Excel file to the run time data table



    Imports the specified sheet of Microsoft Excel file to the run time data table

    DataTable.ImportSheet”FilePath”, 1, ”Name”


    Sets the specified row as the current(active) row in the run time data table



    Sets the row next to the current row as the new current row in the run time data table sheet


    Please do provide your comments and inputs. Thank you.

    Envision-Edge Forum items on QuickTest Professional

    By Rinki Guchhait

    QuickTest provides multiple panes; each pane is categorized based on their logical needs and script related information storages. On the graphical perspective, every pane is very much flexible to fit into any location of the tool as per the user’s wish. To achieve the optimum utility of the tool, a test professional needs to understand clearly the purpose of each pane and how they can be used in a better way in practice. Each pane is described below in brief.

    1. Active Screen Pane

    When a scenario is recorded for a test application, the tool captures application screen shots for every operation that user performs. Using Active Screen Pane, one can view all the screen shots of each operation performed. As system cursor is moved over the test script, active screen pane displays step associated screen shot highlighting the object operated. Active Screen also enables users to parameterize object values, insert checkpoints, methods, and output values for almost every object in the page after recording session, i.e. even when no test application exists further. Active screen logically stores all objects or object information as they are loaded during record. However, if the storage of screen shots increases it affect system’s performance and hence it is not always a recommended option to capture too many screen shots unless really required. QuickTest also provides a user setting for level of screen information capture to take place.
    Navigation: View  Active Screen

    2. Data Table Pane

    Data Table is a Microsoft Excel-like sheet integrated in QuickTest with multiple rows and columns containing test data applicable to the test. By default every test has two data sheets i.e. Global and Action sheets respectively also termed as data tables. This pane allows users to parameterize, copy, paste, modify, export and import functionalities accordingly.
    Navigation: View  Data Table.

    3. Debug Viewer Pane

    The Debug Viewer pane is to rectify defects in script. It contains three tabs to assist debugging a test as Watch, Variables, and Command. Watch: The Watch tab enables users to view the current value of any variable or expression that added to the Watch tab Variables: During run session, the variables tab displays the list of current values of all variables that have been initialized till current step of the run session. Command: The Command tab allows users to execute a single statement and validate the result based on the current test bed circumstances like variables, values, application status etc. and continues execution further with all updates
    Navigation: View  Debug Viewer.

    4. Information Pane

    The Information pane provides a list of VBscript/JScript syntax errors in the test or function library scripts. QuickTest automatically checks for syntax errors in the script when switched from the Expert View to the Keyword View by the user and shows them in the Information pane. If the Information pane is not currently displayed, QuickTest automatically opens it when a syntax error is detected. User can double-click a syntax error to locate the error in the action or function library, and then correct it. Another way to view syntax error is using function key “Ctrl+F7”
    Navigation: View  Information

    5. Missing Resources Pane

    The Missing Resources pane provides a list of the resources that are specified in the test but cannot be found. Missing resources can be called actions, function libraries, recovery scenarios, environment variables XML file, shared object repositories, and parameters associated to shared object repositories. This missing resource validation check happens every time a new test is loaded and displays accordingly with the help of Missing Resources Pane.
    Navigation: View  Missing Resources

    6. Process Guidance Panes

    Process guidance pane provides procedures and descriptions on how to best perform specific processes, i.e. creating a new test in QuickTest. One can use the process guidance to learn about new processes and to learn the preferred methodology for performing processes with which users are already familiar.
    • Process Guidance Activities pane (shown on the left). Lists the activities that are part of the selected process, such as adding steps to a test.
    • Process Guidance Description pane (shown on the right). Describes the tasks that you need to perform for a selected activity.

    7. Available Keywords Pane:

    The Available Keywords pane displays the keywords available to current test or component. It enables users to view, drag and drop objects or calls to functions into the test or component. When drag and drop an object is performed into a test or action or component, QuickTest inserts a step with the default operation for that object. When a function is dragged and dropped to a test or component, QuickTest inserts a call to that function.
    Navigation: View  Available Keywords

    8. Test Flow Pane

    The Test Flow pane is comprised of a hierarchy of actions and action calls in the current test, and shows the order in which they are run. Each action is displayed as a node in a tree, and includes calls to all of a test's actions. The steps of the action that user double-click in the Test Flow pane gets displayed in the Keyword View and Expert View. The Test Flow pane is displayed by default when QuickTest Pro opened.
    Navigation: View  Test Flow.

    9. Resources Pane

    All components are associated with resources such as function libraries, recovery scenarios, and object repositories. QuickTest displays all these resources associated with a component in the Resources pane. Resources pane enables users to view and open all of the resources in the component.
    Navigation: View  Resources

    10. To Do Pane

    The To Do pane enables users to create, view, and manage TODO tasks. A TODO task is items that need to be done in a test, such as providing information relevant for handing over a testing document, or adding a reminder etc. A task can be assigned to others. TODO tasks are saved with the test. The To Do pane also enables user to view the TODO comments that exist in the action or an open function library
    Navigation: View  To Do

    Envision-Edge - Check points in QTP

    By Rinki Guchhait

    A checkpoint is a validation point, which ensures that expected objects or values are loaded in the application under test during test run. QuickTest supports following types of checkpoints for a standard web objects. Also few of them briefed with description.
    1. A page checkpoint checks the characteristics of a Application
    2. A text checkpoint checks that a text string is displayed in the appropriate place on a Application.
    3. An object checkpoint (Standard) checks the values of an object on a Application.
    4. An image checkpoint checks the values of an image on a Application.
    5. A table checkpoint checks information within a table on a Application
    6. An Accessibility checkpoint checks the web page for Section 508 compliance.
    7. An XML checkpoint checks the contents of individual XML data files or XML documents that are part of your Web application.
    8. A database checkpoint checks the contents of databases accessed by your web site

    Text/Text Area Checkpoint:

    In the Text/Text Area Checkpoint properties dialog box, you can specify the text to be checked as well as which text is displayed before and after the checked text. These configuration options are particularly helpful when the text string you want to check appears several times or when it could change in a predictable way during run sessions. In Windows-based environments, if there is more than one line of text selected, the Checkpoint Summary pane displays [complex value] instead of the selected text string. You can then click Configure to view and manipulate the actual selected text for the checkpoint. QuickTest automatically displays the Checked Text in red and the text before and after the Checked Text in blue. For text area checkpoints, only the text string captured from the defined area is displayed (Text Before and Text After are not displayed).
    Tip - We can add checkpoints while recording the application or we can add after recording is completed using Active screen (Note: To perform the second one The Active screen must be enabled while recording)

    Table and DB Checkpoints:

    By adding table checkpoints to your tests or components, you can check that a specified value is displayed in a cell in a table on your application. By adding database checkpoints to your tests or components, you can check the contents of databases accessed by your application. The results displayed for table and database checkpoints are similar. When you run your test or component, QuickTest compares the expected results of the checkpoint to the actual results of the run session. If the results do not match, the checkpoint fails. You can check that a specified value is displayed in a cell in a table by adding a table checkpoint to your test or component. For ActiveX tables, you can also check the properties of the table object. To add a table checkpoint, you use the Checkpoint Properties dialog box. Table checkpoints are supported for Web and ActiveX applications, as well as for a variety of external add-in environments. You can use database checkpoints in your test or component to check databases accessed by your web site or application and to detect defects. You define a query on your database, and then you create a database checkpoint that checks the results of the query. Database checkpoints are supported for all environments supported by QuickTest, by default, as well as for a variety of external add-in environments. There are two ways to define a database query.
    1. Using Microsoft Query. Can be installed Microsoft Query from the custom installation of Microsoft Office.
    2. Manually define an SQL statement.
    Note: The Checkpoint timeout option is available only when creating a table checkpoint. It is not available when creating a database checkpoint

    Bitmap Checkpoint:

    One can check an area of a Web page or application image as a bitmap. While creating a test or component, you specify the area you want to check by selecting an object. You can check an entire object or any area within an object. QuickTest captures the specified object as a bitmap, and inserts a checkpoint in the test or component. You can also choose to save only the selected area of the object with your test or component in order to save disk space. When you run the test or component, QuickTest compares the object or selected area of the object currently displayed on the Web page or application with the bitmap stored when the test or component was recorded. If there are differences, QuickTest captures a bitmap of the actual object and displays it with the expected bitmap in the details portion of the Test Results window. By comparing the two bitmaps (expected and actual), you can identify the nature of the discrepancy. For more information on test results of a checkpoint, see Viewing Checkpoint Results.
    Note: The results of bitmap checkpoints may be affected by factors such as operating system, screen resolution, and color settings.

    Envision-Edge QTP Descriptive Programming

    By Rinki Guchhait

    This blog demonstrates the usage of Descriptive programming in QuickTest. It also discusses situations where Descriptive programming can be used. Using Descriptive Programming automation scripts can be created even if the application has not been developed.
    As a normal approach of object identification in QuickTest, when QuickTest records any action on an object, it adds some description to object repository on how to recognize the test object. QuickTest cannot take action on an object until and unless its object description is in the Object Repository. But descriptive programming by nature is an alternate way to object repository and allows users to perform actions on objects which are not present in Object repository. A simple image below shows how and what kind of object description gets stored in Object Repository and later this is utilized during test run.
    Here, to recognize a radio button on a page QuickTest had added two properties i.e. “name” and “html tag” of radio button. The name the left tree view is the logical name given defined by QuickTest for the object. This can be changed as per the object naming convention followed. Now with the current repository that we have, we can only write operation on objects which are in the repository. Some of the example operations are given below
    Browser("Browser").Page("Page").WebRadioGroup ("testPath").Select "3"
    cellData = Browser("Browser").Page("Page").WebTable ("WebTable").GetCellData (5,3)
    Browser("Example2").Page("Page").WebEdit("testPath").Set "filepath"
    This is the way the regular approach using Object Repository is followed by QuickTest. However, as mentioned earlier, there is a possibility using Descriptive Programming one can avoid Object Repository. Object Repository based approach looks to be very smooth and easy then why one needs to follow descriptive programming. Below are few cases which will give an idea of necessity of this alternate approach.
    1. The objects in the application are dynamic in nature and need special handling to identify the object. The best example would be of clicking a link which changes according to the user of the application, Ex. “Logout <>”.
    2. A case where in user wants to close all opened browsers, this case is not easy to implement using Object Repository approach as user will not be certain how many and what all browser be at anytime opened
    3. When number of repeatable objects in Object Repository are getting huge. If the size of Object repository increases too much resulting decrease the performance of QTP while recognizing an object.
    4. 4. When you don’t want to use object repository at all. Well the first question would be why not object repository? Consider the following cases which would help understand why not Object repository
      • Case 1: Suppose we have a web application that has not been developed yet. Now QTP for recording the script and adding the objects to repository needs the application to be up, that would mean waiting for the application to be deployed before we can start with working on scripts. But if we know the descriptions of the objects that will be created then we can still start off with the script writing for testing
      • Case 2: Suppose an application has 3 navigation buttons on each and every page. Let the buttons be “Cancel”, “Back” and “Next”. Now recording action on these buttons would add 3 objects per page in the repository. For a 10 page flow this would mean 30 objects which could have been represented just by using 3 objects. So instead of adding these 30 objects to the repository we can just write 3 descriptions for the object and use it on any page.
    5. Modification to a test case is needed but the Object repository for the same is Read only or in shared mode i.e. changes may affect other scripts as well
    6. When you want to take action on similar type of object i.e. suppose we have 20 textboxes on the page and their names are in the form txt_1, txt_2, txt_3 and so on. Now adding all 20 the Object repository would not be a good programming approach
    Having understood what and where we could be resisted without descriptive programming, let’s explore the ways of implementing descriptive programming as follow.
    There are two ways in which descriptive programming can be applied
    1. Linear Descriptive Programming
    2. Complex Descriptive Programming – Using Description.Create method

    1. Linear Descriptive Programming

    You can describe an object directly in a statement by specifying property:=value pairs describing the object instead of specifying an object’s name.
    The general syntax is:
    TestObject("PropertyName1:=PropertyValue1", "..." , "PropertyNameX:=PropertyValueX")
    TestObject—the test object class could be WebEdit, WebRadioGroup etc.
    PropertyName:=PropertyValue—the test object property and its value. Each property:=value pair should be separated by commas and quotation marks. Note that you can enter a variable name as the property value if you want to find an object based on property values you retrieve during a run session.
    Consider the HTML Code given below:

    Now to refer to the textbox the statement would be as given below
    Browser(“Browser”).Page(“Page”).WebEdit(“Name:=txt_Name”,”html tag:=INPUT”).set “Test”
    And to refer to the radio button the statement would be as given below
    Browser(“Browser”).Page(“Page”).WebRadioGroup(“Name:=txt_Name”,”html tag:=INPUT”).set “Test”
    If we refer to them as a web element then we will have to distinguish between the 2 using the index property
    Browser(“Browser”).Page(“Page”).WebElement(“Name:=txt_Name”,”html tag:=INPUT”,”Index:=0”).set “Test” ‘ Refers to the textbox Browser(“Browser”).Page(“Page”).WebElement(“Name:=txt_Name”,”html tag:=INPUT”,”Index:=1”).set “Test” ‘ Refers to the radio button

    2. Complex Descriptive Programming

    This kind of descriptive programming uses object property collections and description.create method. This is illustrated as follows along with examples.
    Dim obj_Desc ‘Not necessary to declare Set obj_Desc = Description.Create
    Now we have a blank description in “obj_Desc”. Assume this description has 3 properties “Name”, “Value” and “Regular Expression”. When you use a property name for the first time the property is added to the collection and when you use it again the property is modified. By default each property that is defined is a regular expression. Suppose if we have the following description
    obj_Desc(“html tag”).value= “INPUT” obj_Desc(“name”).value= “txt.*”
    This would mean an object with html tag as INPUT and name starting with txt. Now actually that “.*” was considered as regular expression. So, if you want the property “name” not to be recognized as a regular expression then you need to set the “regularexpression” property as FALSE
    obj_Desc(“html tag”).value= “INPUT” obj_Desc(“name”).value= “txt.*” obj_Desc(“name”).regularexpression= “txt.*”
    This is how of we create a description. Now below is the way we can use it
    Browser(“Browser”).Page(“Page”).WebEdit(obj_Desc).set “Test”