QTP I

The approach of .xls being used as Object Repository instead of QTP Object Repository is because of the fact that the team wanted to use advantages of “Descriptive Programming”
A programmatic description can be very useful if you want to perform an operation on an object that is not stored in the object repository. You can also use programmatic descriptions to perform the same operation on several objects with certain identical properties, or to perform an operation on an object whose properties match a description that you determine dynamically during the run session.
In some screens, we had observed some tables having rows depending on some input data and hence the buttons and links also being dynamic. To handle such scenarios, we could write common functions which can be called n number of times for different objects.

Organizing and maintaining Object Repository in excel sheet is easy and less time consuming. For e.g. to check a property of a link finding and updating it is easy (since we can list all links once)

Moreover, in QTP’s Object Repository the Object Identification properties have to be set on each QTP machine so that the recorded Object Repository can be used.

Finally, the .xls approach is very supportive and flexible to follow the hybrid framework and descriptive programming.
In this framework for example If a Textbox is changed to a list box, then only the object properties in the .xls needs to be changed and the script will run fine.
Moreover, in the existing structure, the Object repository and the xls they have used needs to be changed.

The existing library functions are using the object’s name stored in Object Repository, so they could not be reused. In our case, we pass the properties of objects instead the object’s name as per Descriptive programming syntax.

There are 3 approaches which can be used to automate the test cases:
1. Scripting using the Native Object repository
2. Scripting using the Native Object repository and using Function Libraries to handle the actions on Objects ( This is the approach in the Existing Stuff)
3. Using Descriptive programming.
The team was informed that in Grizzly there are going to be major UI Changes. Some of the existing objects would be replaced by other objects for e.g. a Text Box may be replaced by a List Box.
In such a case the changes required to execute the scripts would be:

In Approach 1: a. Change the Object Repository
b. Change the scripts for those particular changed objects as some of the actions which need to be performed, then the function calls need to be changed.
In Approach 2: a. Change the Object Repository
The Scripts do not need to be changed as the actions are being performed using common functions. To handle the changes for Class Names, there is a xls which maps the object Name (In Native OR) to its class.
b. If the class is changed then the xls needs to be updated.
In Approach 3: a. The Objects properties and class name are in one xls file. If an object is changed then, only the xls needs to be changed.
Common library functions are being called to perform actions on objects hence NO change is required in SCRIPTS & Functions.

This approach (Approach 3) has the following advantages:
 The OBJECT IDENTIFICATION does not need to be set for individual QTP machines.
 Using Descriptive programming, the objects which are being populated during runtime, are handled easily. For e.g. the Table which lists all the Plans has Links and Button to release, Unrelease, and Delete the plan. These need not have unique IDs as they can be dealt with using Descriptive programming.
 In case the identification properties and values match more than one object, QTP will through an "object’s description matches more than one of the objects currently displayed in your application" error. If we’re using the native OR, there no easy way to deal with the situation (we could use a complex Recovery Scenario, but it gets very ugly, very soon). However, DP easily deals with double objects by using the index property. We can add "index:=X" to the description strings (when X is a zero-based counter), and QTP will point to object #X.

 Object reference in external functions: when using external functions, you can never count on the relevant object being defined in the calling action’s OR. And even if the object is defined there, the logical name may be different, so DP remains the only option.

 Objects that change hierarchies: sometime an object will appear under a different parent (e.g. – a pop-up which appears under the initiating sub-window). Then the best way to work with such objects is with DP.

 If the size of the OR becomes large, then opening, changing and updating it is a time consuming task as the loading is slow.

After evaluating all the approaches, we found Descriptive Programming better and using the xls to store the object properties better as no modifications in script or library files is required. Only changes required are in the xls file.

Note: The entire framework (consisting of Library functions, scripts and the xls) is interlinked. As changing any one of these will require changes in all others.

Understanding Checkpoint Types
QuickTest Professional offers the following types of checkpoints:
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 compliancy. 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.
You can add most checkpoints to your test either while recording or afterward. The following sections explain how to create some of the checkpoints described above, in the test you created in Recording Tests.
Note: When QuickTest creates a checkpoint, it assigns a name based on information inside the checkpoint—the checked value, for example. The checkpoint name remains unchanged, even if you subsequently modify the information on which it was based. Keep this in mind when looking for checkpoints displayed in the Keyword View. However, note that QuickTest may shorten the name displayed in the Keyword View.
Frameworks
Keyword driven –in script it will identify by keyword(from datasheet)
Library driven (from .vbs file)
Data driven (from local sheet)
Modular driven (individual modules like keyword driven, library driven, datadriven)

All frameworks we can call it as hybrid driven

Local sheet- for individual scripts
Global sheet-it is used when ever we create test suite

Qtp updation

The scripts are running from qc

In that
Test name
Run on host
Status
In qc expected result and actual result will be there

Then it will connect automatically to qtp and run the script

Data Driven Testing

 A test that runs one set of user actions with multiple input values.
 Data driving allows one script to test AUT with many sets of data.

Benefits
 Increased Testing coverage
 Test boundary conditions
 Test good data and bad data

Elements of Data Driven Tests

 Recorded Test Script
 Parameter (s)
A parameter is a variable which replaces the recorded value in the script.
At run time, quick test substitutes a value from the data source for the parameter.
 Data Source
The location of data that Quick Test will use to supply the parameter
23. what do you call the window testdirector-testlab?

Ans : "Execution Grid". It is place from where we Run all Manual / Automated Scripts