1. Descriptive programming solves many object recognition and maintenance problems that are otherwise going to stay (if we use Object Repository). So, we can rely on Descriptive Programming, ignoring Object Repository.

What happens if we ignore Object Repository:

All the properties you use in Descriptive Programming will be treated as Mandatory properties. In turn we are losing the power of Assistive properties in the object recognition mechanism of QTP .

QTP identifies an object using test object description stored in Object Repository. This description is made up of two sets of properties:

1. Mandatory Properties
2. Assistive Properties

For any object you can dictate QTP what properties to consider as mandatory and what properties as Assistive properties in a facility called "Object Identification".

Quick Test learns all mandatory properties by default. If it can't create a unique description for the object using mandatory properties alone, it starts learning one assistive property at a time until it creates a unique description for the object in question.

So, what it means is that just because you told QTP to use several Assistive Properties, it does not mean that it learns them all. It learns only to the extent needed i.e. until a unique object description is created

Also, in Descriptive Programming, you can't make use of the modern technology available in QTP - Smart Identification. You can use this only if have Object Repository.

If an object is not learned into Object Repository, there will be no logical name, no assistive properties, nor there do any base and optional properties to use for smart identification.

2. Descriptive Programming is better than Object Repository in cases where objects in the application are dynamic in nature and need special handling to identify the object.

Objects whose properties change dynamically for each run or depending on input data can be handled equally well by Object Repository.

In both cases you can use global or local sheet parameters, environment parameters as well as regular expressions to parameterize object properties.

3. If the size of Object repository increases too much then it decreases the performance of QTP while recognizing an object. Descriptive Programming is better in such situations.

Size of the Object Repository has very little or nothing to do with performance of QTP. It is rather the nature and number of objects in a given page that impact the performance of QTP. For example if there is one web button on a web page, QTP needs only one property (class name) to uniquely recognize that object right away. If you have, say 100 web buttons in a web page, then QTP has to use additional properties to recognize the object (may be "Value" property). Like this, QTP keeps on using more and more properties until it recognizes the object uniquely and this is what causes performance degradation not the size of Object Repository. However using descriptive programming we can have just one utility function that can be called as and when we want to execute the specific event, by sending the associated set of properties for the corresponding objects. This is how we handle the Submit button click on all the pages in the application. We expect that each scenario requires the submit button to be clicked and parameterizing the properties and calling a single function helps us validate the scenario without increasing too much of the object repository size.

4. Descriptive Programming makes maintenance easy!

No. It is as bad/good as maintaining Object Repository. Just because if we use the traditional abject repository method, we can easily get the object set properties updated by using the tool provided within the QTP, however using descriptive programming, we need to manually alter the [properties and that is a very time consuming one.

5. QTP cannot take action on an object until unless its object description is in the Object Repository. But descriptive programming provides a way to perform action on objects which are not in Object repository

If an object is not defined in the object repository, you will have to create your own description of that object so that QTP can recognize and act on it. You will have to create the description very carefully otherwise you will get run error.

In Descriptive Programming, creating a workable description for some objects can prove to be very tedious and time consuming some times. Properties that work are not always consistent. Sometimes you have to dig through several combinations of properties to find one that works correctly.

You will be better off adding object to the Object Repository with just click of a button rather than creating a time consuming buggy description all by yourself.

6. Using Descriptive Programming, automation scripts can be created even if the application has not been developed.

If you build object descriptions (and scripts based on those descriptions) without ever spying on the objects, the chances are that, in more than 50% of the cases, the description might fail. But if you have great development discipline in place, we go for this approach. Several projects utilize the keyword driven aopproach to mae this all successful.

Scripts you create without having the application developed will hardly serve you any purpose. This is because, without having the application developed, you can't have active screens captured, can't insert checkpoints, can't output values. But Reporter.reportevent is something that serves the purpose with a beauty. You need to be sufficiently expert in the Vbscript usage and optimize the code using it by various combinations of conditional looping and things as such.

Advantages of Descriptive programming

Descriptive Programming Solves redundancy problem.

If you have same objects on many pages, you don't need to add them to Object Repository under each page. You can handle it with Descriptive Programming and avoid redundancy.

Descriptive Programming solves the problem of dealing with large number of objects of same type.

For example, you can't anticipate search results and put them in Object Repository in advance. You can create descriptions for such objects and make QTP act on them based on, for example, ordinal identifier. A yet another powerful utility in the object recognition mechanism.

Conclusion

Descriptive programming helps us handle special circumstances which otherwise can't be handled with Object Repository alone. However, in the final analyses, Descriptive Programming should NOT be treated as replacement for Object Repository for it is far from being a viable alternative to object Repository.

Descriptive Programming is a necessary exception rather than a norm. But, at the same time, we can't live without Descriptive Programming.

For gaining more insights in the automation using QTP log on to below url :

Synchronization of the application load with the Script execution :Wait and WaitRoproperty.
In scenarios wherein the properties of the object changes after some time we use waitproperty.

Object Recognition Mechanism in QTP :

Add object in the Object Repository using Object Spy

Creating the same using Descriptive programming.

Using the active screen or going into the application and clicking insert new object.

Regular Expression Usage Effectively in the scripting :
After having gone through the Book Ticket scenario in the Flight application . just go into the File menu for Fax order scenario.
Go to file and select Fax the booked tickets.
Select for regular expression option so that the fax order number gets recognised each time on the basis
of this very regular expressionJust put a .* after the point from where the characters is expected to be changed.
Text Checkpoint : Checked text, Text Before, After text
Match CAse, exact match,
Text Area checkpoint is for tabular display for any specific row.
namespace standards in xml.
XML Addins is required for the XML checkpoints.

Test Objects used by web services.
Strat Transaction end transactionm...
Time frames get retunrned
Generally used foir query time out features related to databasae interactions.
Colon is used to combine multiple statement in one line

Important conecpts in Advanced QTP workaround :

Parameterization

Checkpoint

Synchronization

Object Repository

Descriptive Programming is a technique used when an object property changes frequently.
No Object Repository method is used for object identification.

Static are the necessary properties of an objects.
Methods like SET are used for creating references to the objects actually present in the application.

Let us look into describing the Objects in the application. Do remember the hierarchy of the Parent and child objects. Generally the approach we follow for the description programming is coding in the hierarchial manner that an object is recognized by the QTP tool during the course of object identification.

Login Box Which is a dialog box
Keep your appplication open, Object Spy tool can be useed to spy onto the objects and highlight and copy the properties of the required objects.
Individually search for each of the objects associated properties.
Always use the two things, class name and the text name genuinely very relevant.

For Button to log on OKSet oOKButton=Description.Create() oOKButton("Class Name").Value="WinButton"
oOKButton("text").Value="OK"

For Button to log on CancelSet oCanButton=Description.Create() oCanButton("Class Name").Value="WinButton"
oCanButton("text").Value="Cancel"

Now , let us code using VBScript to execute the events in the application which is expected to be performed for logging into the application.
InvokeApplication "D:\Program Files\HP\QuickTest Professional\samples\flight\app\flight3a"
Dialog(oLogin).WinEdit(oUserNam).Type"employee"
Dialog(oLogin).WinEdit(oUserNam).Set "employee"
Dialog(oLogin).WinEdit(oPassword).Set "mercury"
Dialog(oLogin).WinButton(oOKButton).Click

Object Properties In QTP : Object identification is one of the most important aspect in any automation testing. QTP tool identifies objects in a very hierarchial manner. Browse through the below posts on QTP testing for various object identification and object properties.

Consider yourself as the Automation developer, myself as QTP and a parking lot as the application, cars parked in the parking area as the Test Objects.

Now you ask me (QTP) to bring a car from the parking lot and you point me to the car ( This is adding the Test Object to Object repository or recording on the same). By my previous knowledge and what I am programmed to learn, I look at the car and remember its # plate so that I can identify the same in future. The color of the car is red but I don’t remember this as # plate (My mandatory property settings) is good enough for me to recognize. This is about learning mandatory properties.

Now if I add color property to Mandatory list I will have 2 properties for identifying the car. If the car is painted to white color I would not be able to locate the car as I am still looking for a red color car with the same # plate as the white one in front of me. So this is why we don’t add all properties to Mandatory listNow let assume this parking lot has some new cars which has no # plates. So my mandatory properties doesn’t give me anything to re-identify the car later. I start looking at my assistive properties which is the color in this case. The parking lot has only 1 red car so I remember the color as well to re-identify the car. This is about learning assistive properties. If one assistive property doesn’t help I would look at others one by one.

So far so good. Now if we have another red car parked in the parking, so my identification of blank #plate and red color will still not resolve which car to pick. So I need to make a choice based on 1st or the 2nd one (index), left one or the right one (location), the car that came first in the parking lot or the one came later (creationtime in case of browser). This is where we need ordinal identifier.

Now coming to smart identification. Consider you told me to pick a red color car with some plate #X and car was repainted to white. Now I don’t find anything in the lot and I start getting smart. I would say lets just drop off all what you said and see if I can find the car. I first see how many cars in the lot, If there is only 1 then my issue is solved. But lets say there are 3 cars, Now my SI algo says to look for the #plate and i find that white car matches the # plate so I pick it up and the car for you. This is what is Smart Identification.

If my Smart identification had color as the first property to be checked then I would have looked only at white car present in the parking lot, if I found one I would give the same to you. Even though our car may not be present in the parking lot I still give you a car which may not be the one you were looking for. This is why it always advised to keep Smart Identification disabled.

Coming back to the QTP world I would like to highlight another point now. Mandatory, Assistive properties only come into picture when we add an object to the OR or record some action on the same. While identifying the object again QTP will not differentiate which property was a Mandatory one or Assistive one. It would just try to match all the properties it had been given to identify the object.

There is a small difference when it comes to ordinal identifiers. QTP only uses ordinal identifiers when there are multiple matches of an object. So Browser(”creationtime:=50″) is same as Browser(”micclass:=Browser”) when you only have one browser open as QTP will not use the Creationtime property at all. But when 2 browsers exist QTP will throw an error as there is none with creationtime:=50

I hope this cleared all doubts about these different properties are used in QTP to add and identify the object later.

Object Repository Enhancements :24. Ability to create and load OR’s from QTP script itself.
25. Ability to load Shared ORs dynamically to all the Actions. Currently RepositoriesCollection.Add methods adds the SOR to the current Action only and not other actions.
26. Changes made through SetTOProperty in one Action does not get propagated to Next Action.
27. Ability to enumerate all child objects present in the OR for a specified object.
28. Ability to specify nickname for Objects. This would help get a complete object hierarchy through just the nick name.
29. Ability to directly record objects into the SOR

Object Repository Manager Enhancements :30. Ability to load and save directly to OR in XML format.
31. Ability for multiple users to access the Shared OR at the same time for updating.
32. Export/Import of Checkpoints from one SOR to another.
33. Merging of SOR’s to an existing SOR. Currently when two SOR are merged, the merged SOR needs to be saved as a different file.
34. Ability to update code when conflict resolution renames object during SOR merge. In case object A and B are merged and name A is chosen over B, all scripts using name B needs to be updated manually.

Configuring Smart Identification

When the learned definition for an object does not enable QuickTest Pro/ QTP to identify an object, QuickTest uses the Smart Identification definition (if defined and enabled) to identify the object.

The Smart Identification dialog box enables you to create and modify the Smart Identification definition that QuickTest uses for a selected test object class.

About Configuring Smart Identification

When QuickTest uses the learned description to identify an object, it searches for an object that matches all of the property values in the description. In most cases, this description is the simplest way to identify the object, and, unless the main properties of the object change, this method will work.

If QuickTest is unable to find any object that matches the learned object description, or if it finds more than one object that fits the description, then QuickTest ignores the learned description, and uses the Smart Identification mechanism to try to identify the object.

While the Smart Identification mechanism is more complex, it is more flexible. Therefore, if configured logically, a Smart Identification definition can probably help QuickTest identify an object, if it is present, even when the learned description fails.

The Smart Identification mechanism uses two types of properties:

Base Filter Properties. The most fundamental properties of a particular test object class; those whose values cannot be changed without changing the essence of the original object. For example, if a Web link's tag was changed from to any other value, you could no longer call it the same object.

Optional Filter Properties. Other properties that can help identify objects of a particular class. These properties are unlikely to change on a regular basis, but can be ignored if they are no longer applicable.

Understanding Smart Identification :

If QuickTest activates the Smart Identification mechanism during a run session (because it was unable to identify an object based on its learned description), it follows the following process to identify the object:

QuickTest "forgets" the learned test object description and creates a new object candidate list containing the objects (within the object's parent object) that match all of the properties defined in the Base Filter Properties list.

QuickTest filters out any object in the object candidate list that does not match the first property listed in the Optional Filter Properties list. The remaining objects become the new object candidate list.

QuickTest evaluates the new object candidate list:

If the new object candidate list still has more than one object, QuickTest uses the new (smaller) object candidate list to repeat step 2 for the next optional filter property in the list.

If the new object candidate list is empty, QuickTest ignores this optional filter property, returns to the previous object candidate list, and repeats step 2 for the next optional filter property in the list.

If the object candidate list contains exactly one object, then QuickTest concludes that it has identified the object and performs the statement containing the object.

QuickTest continues the process described in steps 2 and 3 until it either identifies one object, or runs out of optional filter properties to use.

If, after completing the Smart Identification elimination process, QuickTest still cannot identify the object, then QuickTest uses the learned description plus the ordinal identifier to identify the object.

If the combined learned description and ordinal identifier are not sufficient to identify the object, then QuickTest stops the run session and displays a Run Error message.

Reviewing Smart Identification Information in the Test Results :

If the learned description does not enable QuickTest to identify a specified object in a step, and a Smart Identification definition is defined (and enabled) for the object, then QuickTest tries to identify the object using the Smart Identification mechanism.

If QuickTest successfully uses Smart Identification to find an object after no object matches the learned description, the step is assigned a Warning status in the Test Results, and the result details for the step indicate that the Smart Identification mechanism was used.

If the Smart Identification mechanism cannot successfully identify the object, QuickTest uses the learned description plus the ordinal identifier to identify the object. If the object is still not identified, the component fails and a normal failed step is displayed in the results.

The explanation below describes the process that QuickTest uses to find the Login object using Smart Identification:

According to the Smart Identification definition for Web image objects, QuickTest learned the values of the following properties it learned the Login image:

The learned values are as follows:

Base Filter Properties:

Property

Value

html tag

INPUT

Optional Filter Properties:

Property

Value

alt

Login

image type

Image Button

name

login

file name

login.gif

class

visible

1

QuickTest begins the Smart Identification process by identifying the five objects on the Mercury Tours page that match the base filter properties definition (html tag = INPUT). QuickTest considers these to be the object candidates and begins checking the object candidates against the Optional Filter Properties list.

QuickTest checks the alt property of each of the object candidates, but none have the alt value: Login, so QuickTest ignores this property and moves on to the next one.

QuickTest checks the image type property of the each of the object candidates, but none have the image type value: Image Button, so QuickTest ignores this property and moves on to the next one.

QuickTest checks the name property of each of the object candidates, and finds that two of the objects (both the basic and VIP Login buttons) have the name: login. QuickTest filters out the other three objects from the list, and these two login buttons become the new object candidates.

QuickTest checks the file name property of the two remaining object candidates. Only one of them has the file name login.gif, so QuickTest correctly concludes that it has found the Login button and clicks it.

You use the Smart Identification Properties dialog box, accessible from the Object Identification dialog box, to configure the Smart Identification definition for a test object class.

Select the properties you want to include in the Base Filter Properties list and/or clear the properties you want to remove from the list.

Note: You cannot include the same property in both the base and optional property lists.

You can specify a new property by clicking New and specifying a valid property name in the displayed dialog box.

Tip: You can also add property names to the set of available properties for Web objects using the attribute/notation. To do this, click New. The New Property dialog box opens. Enter a valid property in the format attribute/ and click OK. The new property is added to the Base Filter Properties list. For example, to add a property called MyColor, enter attribute/MyColor.

Click OK to close the Add/Remove Properties dialog box. The updated set of base filter properties is displayed in the Base Filter Properties list.

Select the properties you want to include in the Optional Filter Properties list and/or clear the properties you want to remove from the list.

Note: You cannot include the same property in both the base and optional property lists.

You can specify a new property by clicking New and specifying a valid property name in the displayed dialog box.

Tip: You can also add property names to the set of available properties for Web objects using the attribute/notation. To do this, click New. The New Property dialog box opens. Enter a valid property in the format attribute/ and click OK. The new property is added to the Optional Filter Properties list. For example, to add a property called MyColor, enter attribute/MyColor.

Click OK to close the Add/Remove Properties dialog box. The properties are displayed in the Optional Filter Properties list.

Use the up and down arrows to set your preferred order for the optional filter properties. When QuickTest uses the Smart Identification mechanism, it checks the remaining object candidates against the optional properties one-by-one according to the order you set in the Optional Filter Properties list until it filters the object candidates down to one object.

Retrieving and Setting Identification Property Values

The below stuff is very important and very frequently used by any QTP programmer in Object identification using QTP.

Sub GetROProperty_Example2()'The following example uses the GetROProperty method to retrieve the row'number of the first character in the "User" field.
row = TeWindow("TeWindow").TEScreen("Sign On").TEField("User").GetROProperty("start row")
MsgBox row

EndSub

Identification properties are the set of properties defined by QuickTest for each object. You can set and retrieve a test object's identification property values, and you can retrieve the values of identification properties from a run-time object.

When you run your test or function, QuickTest creates a temporary version of the test object that is stored in the test object repository. You can use the GetTOProperty, GetTOProperties,and SetTOProperty methods in your test or function library to set and retrieve the identification property values of the test object.

The GetTOProperty and GetTOProperties methods enable you to retrieve a specific property value or all the properties and values that QuickTest uses to identify an object.

The SetTOProperty method enables you to modify a property value that QuickTest uses to identify an object.

Note: Because QuickTest refers to the temporary version of the test object during the run session, any changes you make using the SetTOProperty method apply only during the course of the run session, and do not affect the values stored in the test object repository.

For example, the following statements would set the Submit button's name value to my button, and then retrieve the value my button to the ButtonName variable:

Function RemoveAllLinks(Root)'The following function recursively enumerates all the test objects under a specified object.'It looks for all test objects of class Link and removes them from their parent objects.

Understanding Object Conflicts In QTP

Merging two object repositories can result in conflicts arising from similarities between the objects they contain. The Object Repository Merge Tool identifies three possible conflict types:

Similar Description Conflict. Two objects that have the same name and the same object hierarchy, but that have slightly different descriptions. In this conflict type, one of the objects always has a subset of the properties set of the other object.

By default, the conflict resolution settings for conflicts of this type are configured so that the target object repository takes the object that has fewer identifying properties than the object with which it conflicts. For information on changing the default settings, see Defining Default Settings.

Same Name Different Description Conflict. Two objects that have the same name and the same object hierarchy, but differ somehow in their description (for example, they have different properties, or the same property with different values).

By default, the conflict resolution settings for conflicts of this type are configured so that the target object repository takes the object from both files. The object that is added from the secondary file is renamed by adding an incremental numeric suffix to the name, for example, Edit_1. For information on changing the default settings, see Defining Default Settings.

Same Description Different Name Conflict. Two objects that have identical descriptions and have the same object hierarchy, but differ in their object names.

By default, the conflict resolution settings for conflicts of this type are configured so that the target object repository takes the object name from the primary source file. For information on changing the default settings, see Defining Default Settings.

Note: Objects that do not have a description, such as Page or Browser objects, are compared by name only. If the same object is contained in both the source object repositories but with different names, they will be merged into the target object repository as two separate objects.

Similar Description Conflict

An object in the primary object repository and an object in the secondary object repository have the same name, and they have similar, but not identical, description properties and values. One of the objects always has a subset of the properties set of the other object. For example, an object named Button_1 in the secondary object repository has the same description properties and values as an object named Button_1 in the primary object repository, but also has additional properties and values.

You can resolve this conflict type by:

Keeping the object added from the primary object repository only.

Keeping the object added from the secondary object repository only.

Keeping the objects from both object repositories. In this case, the Object Repository Merge Tool automatically renames the object that is added from the secondary file by adding an incremental numeric suffix to the name, for example, Edit_1.

Ignoring the object from the local object repository and keeping the object from the shared object repository (when updating a shared object repository from a local object repository).

Same Name Different Description Conflict

An object in the primary object repository and an object in the secondary object repository have the same name, but completely different description properties and values.

You can resolve this conflict type by:

Keeping the object added from the primary object repository only.

Keeping the object added from the secondary object repository only.

Keeping the objects from both object repositories. In this case, the Object Repository Merge Tool automatically renames the object that is added from the secondary file by adding an incremental numeric suffix to the name, for example, Edit_1.

Ignoring the object from the local object repository and keeping the object from the shared object repository (when updating a shared object repository from a local object repository).

Same Description Different Name Conflict

An object in the primary object repository and an object in the secondary object repository have different names, but the same description properties and values.

You can resolve this conflict type by:

Taking the object name from the object in the primary object repository.

Taking the object name from the object in the secondary object repository.

Ignoring the object from the local object repository and keeping the object from the shared object repository (when updating a shared object repository from a local object repository).

Resolving Object Conflicts

Conflicts between objects in the primary and secondary object repositories are resolved automatically by the Object Repository Merge Tool according to the default resolution settings that you can configure before performing the merge. For more information, see Defining Default Settings.

However, the Object Repository Merge Tool also allows you to change the way the merge was performed for each individual object that causes a conflict.

For example, an object in the primary object repository could have the same name as an object in the secondary object repository, but have a different description. You may have defined in the default settings that in this case, the object with the more generic object description, meaning the object with fewer properties, should be added to the target object repository. However, when you review the conflicts after the automatic merge, you could decide to handle the specific conflict differently, for example, by keeping both objects.

Note: Changes that you make to the default conflict resolution can themselves affect the target object repository by causing new conflicts. In the above example, keeping both objects would cause a name conflict. Therefore, the target object repository is updated after each conflict resolution change and redisplayed.

You can identify objects that caused conflicts, and the conflict type, by the icon displayed to the left of the object name in the target object repository pane of the Object Repository Merge Tool and the text color. When you select a conflicting object, a full description of the conflict, including how it was automatically resolved by the Object Repository Merge Tool, is displayed in the Resolutions Options pane.

The Resolutions Options pane offers alternative resolution options. You can choose to keep the default resolution if it suits your needs, or use the alternative options to resolve the conflict in a different way. In addition, for a local object repository merge, you can click the Ignore Object button to exclude a specific local object repository object from the target shared object repository.

Tip: You can also change the default resolution settings and merge the files again. For more information, see Defining Default Settings.

To change the way in which object conflicts are resolved:

In the target object repository, select an object that had a conflict, as indicated by the icon to the left of the object name. The conflicting objects are highlighted in the source object repositories.

A description of the conflict and the resolution method used by the Object Repository Merge Tool is described in the Resolution Options pane. A radio button for each possible alternative resolution method is displayed. For information on each of the conflict types, see Understanding Object Conflicts.

In the Resolution Options pane, select a radio button to choose an alternative resolution method. The target object repository is updated according to your selection and redisplayed.

In the Resolution Options pane, click the Previous Conflict or Next Conflict buttons to jump directly to the next or previous conflict in the target object repository hierarchy.

Updating a Shared Object Repository from Local Object Repositories In QTP

You can update a shared object repository by merging local object repositories associated with one or more components (via the application area) into the shared object repository. The objects that are merged from the local object repositories are then available to any components that use that shared object repository.

In the merge process, the objects in the local object repository for the selected component are moved to the target shared object repository. The component then uses the objects from the updated shared object repository.

You can view or change how conflicting objects are dealt with during the update process in the Settings dialog box. For more information, see Defining Default Settings.

If you choose to add local object repositories for more than one component, QuickTest performs multiple merges, merging each component's local object repository with the target object repository one at a time, for all the components in the list. You can view and modify the results of each merge if necessary.

Notes:

The Object Repository Merge Tool does not merge checkpoint or output objects from a local object repository into the target shared object repository. You can export checkpoint or output objects from a local object repository to a shared object repository and then manually move the checkpoint and output objects from the exported object repository to your target object repository after you complete the merge process, using the Object Repository Manager.

You can merge local object repositories only from components whose application areas are associated with the shared object repository you are updating.

Note: For more information on the Object Repository Manager, see Managing Object Repositories.

In the Object Repository Manager, select File > Open or click the Open button . The Open Shared Object Repository dialog box opens.

In the sidebar, select the location of the object repository file, for example, File System or Quality Center Resources. Browse to and select the .tsr file that contains the shared object repository you want to update, clear the Open in read-only mode check box, and click Open. The file opens with the objects and properties displayed in editable format.

Tip: If you opened the object repository in read-only mode, select File > Enable Editing or click the Enable Editing button in the Object Repository Manager toolbar. The object repository file is made editable.

Make sure you are connected to your Quality Center project. Click the down arrow next to the Add Tests button , and select Browse for Component. The Open QuickTest Component from Quality Center Project dialog box opens.

Browse to the component whose local object repository you want to merge into the shared object repository.

Note: You can only add a component whose application area is associated with the shared object repository you are updating and whose local object repository contains objects.

Repeat step 5 to add additional components if required.

Note: The local object repositories associated with all the components are included in the merge. If you want to remove a component from the merge, select it in the list and click Delete .

Click Update All. QuickTest automatically merges the first component local object repository into the shared object repository according to the configured settings, and displays the results in the Statistics dialog box on top of the Object Repository Merge Tool window.

Note: Before each merge, QuickTest checks whether the local object repository is in use by another user. If so, the local object repository is locked and the objects for the selected component cannot be moved to the target shared object repository. A warning message is displayed. The merge can be performed when the local object repository is no longer in use by the other user.

Review the merge statistics, as described in Viewing Merge Statistics, and click Close.

The Object Repository - Merge Tool window for a local object repository merge displays the local object repository as the primary object repository, and the shared object repository as the target object repository.

At the left of each object in the target object hierarchy is an icon that indicates the source of the objects:

indicates that the object was added from the local object repository.

indicates that the object already existed in the shared object repository.

Note: If you specified more than one component in the Update from Local Repository dialog box, QuickTest performs multiple merges, merging each component's local object repository with the target object repository one at a time. The Statistics dialog box and the Object Repository Merge Tool - Multiple Merge window displayed after this step show the merge results of the first merge (the local object repository of the first component being merged into the shared object repository). QuickTest enables you to view, and modify if necessary, the results of each merge in sequence. The number of each merge set in a multiple merge is displayed in the title bar, for example, [Set 2 of 3].

For each object merged into the shared object repository, you can accept the automatic merge or use the Resolution Options pane to:

Keep a specific object from the shared object repository and delete the conflicting object from the local object repository.

Keep a specific object from the local object repository and delete the conflicting object from the shared object repository.

Keep conflicting objects from both the shared object repository and the local object repository.

Exclude a specific local repository object from the merge process so that it is not included in the shared object repository. Select the object in the Shared Object Repository pane and click Ignore Object at the bottom of the Resolution Options pane. The object is removed from the shared object repository and grayed in the local object repository tree. It remains in the component's local object repository when the merge is complete.

Notes:

The Ignore Object button is only visible in the Merge Tool window for a local object repository merge, and is only enabled when an object in the local object repository is selected.

The Ignore Object operation cannot be reversed. To include the object again in the merge process, you must repeat the merge by clicking Revert to Original Merged Files in the toolbar.

For more information, see Resolving Object Conflicts.

If you are performing multiple merges, click the Save and Merge Next button in the Object Repository Merge Tool toolbar to perform the next merge (the local object repository of the next component being merged into the shared object repository).

Click Yes to save your changes between merges. If you click No, the current merge (objects merged from the last component) will not be saved.