When running a bitmap checkpoint, QuickTest compares the area that you are checking in the application with the bitmap stored in the checkpoint, pixel by pixel. By default, if any pixels are different, the checkpoint fails. The Bitmap Checkpoint Properties dialog box provides options for fine-tuning the bitmap comparison.

You can adjust the comparison to enable the checkpoint to pass even if the bitmaps are not identical by setting the RGB tolerance and Pixel tolerance options described below.

In addition, QuickTest enables you to use custom comparers for bitmap checkpoints. A custom comparer is a COM object that you or a third party developed to run the bitmap comparison in the checkpoint according to a more specific algorithm. If one or more custom comparers are installed and registered on the QuickTest computer, the Bitmap Checkpoint Properties dialog box includes a Comparer option. This option enables you to select the QuickTest default comparer or a custom comparer that performs the bitmap comparison according to your testing requirements.

If you select a custom comparer, some of the options in the Bitmap Checkpoint Properties dialog box are different.

Bitmap Checkpoint Tolerance Options:

RGB tolerance: The RGB (Red, Green, Blue) tolerance determines the percent by which the RGB values of the pixels in the actual bitmap can differ from those of the expected bitmap and allow the checkpoint to pass. (The RGB tolerance option is limited to bitmaps with a color depth of 24 bits.)

For example, a bitmap checkpoint on identical bitmaps could fail if different display drivers are used when you create your checkpoint and when you run your test. Suppose one display driver displays the color white as RGB (255, 255, 255) and another driver displays the color white as RGB (231, 231, 231). The difference between these two values is about 9.4%. By setting the RGB tolerance to 10%, your checkpoint will pass when running your test with either of these drivers.

Note: QuickTest applies the RGB tolerance settings when comparing each pixel in the actual and expected bitmaps. The Red, Green, and Blue values for each pixel are compared separately. If any of the values differs more than the tolerance allows, the pixel fails the comparison.

Pixel tolerance: The pixel tolerance determines the number or percentage of pixels in the actual bitmap that can differ from those in the expected bitmap and allow the checkpoint to pass.

For example, suppose the expected bitmap has 4000 pixels. If you define the pixel tolerance to be 50 and select the Pixels radio button, up to 50 pixels in the actual bitmap can be different from those in the expected bitmap and the checkpoint passes. If you define the pixel tolerance to be 5 and select the Percent radio button, up to 200 pixels (5 percent of 4000) in the actual bitmap can be different from those in the expected bitmap and the checkpoint passes.

Using both RGB and Pixel Tolerances: If you define both RGB and pixel tolerances, the RGB tolerance is calculated first. The pixel tolerance then defines the maximum number of pixels that can fail the RGB criteria and allow the checkpoint to pass.

For example, suppose you define an RGB tolerance of 10 percent and a pixel tolerance of 5 percent for a bitmap that has 4000 pixels.

For the checkpoint to pass, each pixel in the actual bitmap must have RGB values that are no greater than or no less than 10 percent of the RGB values of the expected bitmap. If that criterion fails, QuickTest checks that the number of pixels that failed are less than 200. If that criterion passes, the checkpoint passes.

You can view the step in QuickTest that corresponds to a node in the run results tree. To view the step in the test that corresponds to a node:

1. Select a node in the run results tree.

2. Perform one of the following:

- Click the Jump to Step in QuickTest button from the Run Results toolbar.
- Right-click and select Jump to Step in QuickTest from the context-sensitive menu.
- Select View > Jump to Step in QuickTest.

3. The QuickTest window is activated and the step is highlighted.

To jump to a step, the following conditions must be true:

a. QuickTest must be running and open to the test whose results are displayed in the Test Results window.

b. The test was run in a version of QuickTest that supports the Jump to Step in QuickTest functionality.

c. The node has a corresponding step in QuickTest. This feature is disabled for the Action, Iteration, Run-Time Data Table, and Test Summary nodes.

d. The step was not performed by a recovery scenario.

e. The step was not run from the Watch or Command tabs of the Debug Viewer.

f. The step is not part of an action that was run using the LoadAndRunAction statement.

g. The test was saved before the run session.

h. The test ran in Normal mode. For information on running QuickTest in Normal mode.

The custom comparer that you develop needs to be installed on any computer that runs a test that includes a bitmap checkpoint that uses the custom comparer.

Make sure that when the custom comparer is installed, the documentation that you provide for the QuickTest user is placed in the location that you specified in the GetHelpFilename method.

In addition, for QuickTest to recognize the COM object that you create as a custom comparer, you must register it to the component category for QuickTest bitmap comparers.

You register a COM object to a component category by listing the relevant component category ID as a registry key under the COM object's HKEY_CLASSES_ROOT\CLSID\Object's CLSID\Implemented Categories key.

The component category ID must be registered under the HKEY_CLASSES_ROOT\Component Categories key. When QuickTest is installed, it adds the component category ID for QuickTest bitmap comparers as a registry key in this location.

The component category ID for QuickTest bitmap comparers, CATID_QTPBitmapComparers, is defined in QuickTest installation folder\dat\BitmapCPCustomization\ComponentCategory.h.

When you design your custom comparer, you must ensure that when it is installed on the QuickTest computer, it is also registered to the component category for QuickTest bitmap comparers. This can be achieved in different ways.

If you develop your custom comparer in C++ using Microsoft Visual Studio, you can specify this name in the Type box in the ATL Simple Object Wizard.

If you develop the custom comparer in Visual Basic, this value is automatically set to the COM object's ProgID. If you want to modify the custom comparer name, you can edit it manually in the registry after the comparer is installed, or design the program that performs the installation and registration to edit this value as well.

If you develop your custom comparer in C++ using Microsoft Visual Studio, you can modify the DllRegisterServer and DllUnregisterServer methods to handle this registration. These methods are called when you run a DLL using the regsvr32.exe program.

If you develop your custom comparer in an environment that does not enable you to modify the registration methods, you can add an additional program that handles this registration and instruct users who install the custom comparer to run this program as well. You can see an example of this type of implementation in the Visual Basic sample custom comparer that QuickTest provides.

In QTP, to develop a custom comparer, below are some importants to keep in mind:

1. To develop a custom comparer you must understand image processing and know how to develop COM objects.

2. You can implement a custom comparer using any language and development environment that supports creating COM objects.

3. Custom comparers run within the QuickTest context. You must therefore exercise care when developing your custom comparer, as its behavior and performance will affect the behavior and performance of QuickTest.

4. The custom comparer must be installed and registered on any computer that runs a test with a bitmap checkpoint using the custom comparer.

5. Before installing and registering a new version of a custom comparer, unregister the existing comparer.

6. More than one custom comparer can be installed and registered on the same QuickTest computer. In the Bitmap Checkpoint Properties dialog box, QuickTest displays all of the available custom comparers, and the QuickTest default comparer. The QuickTest user can select the appropriate comparer to use for each bitmap checkpoint.

7.The computer that runs the custom comparer must have installed the runtime environment associated with the configuration in which the custom comparer DLL was built.

8. You create the custom comparer DLL using a specific development environment version; the computer on which this DLL runs must have the corresponding runtime environment installed.

Using QuickTest Professional 10.00 you can develop custom comparers for bitmap checkpoints. A custom comparer is a COM object that performs the bitmap comparison for the checkpoint according to your testing requirements. For example, you could define a custom comparer that allows a bitmap checkpoint to pass even if the image in the application shifts by an amount specified when the checkpoint is defined.

After you install and register a custom comparer on the QuickTest computer, your comparer is available for selection in the Bitmap Checkpoint Properties dialog box. The dialog box provides space for specifying additional configuration preferences expected by your comparer.

When QuickTest performs a bitmap checkpoint that uses a custom comparer, it supplies the expected and actual bitmaps to the custom comparer object. It then receives and reports the results that the custom comparer returns.

To develop a custom comparer, you -create a COM object that implements the QuickTest bitmap checkpoint comparer interfaces to perform the following tasks:

- Accept input from QuickTest and perform the bitmap comparison.
- Provide comparison results to QuickTest.
- Provide information that QuickTest can display in the Bitmap Checkpoint Properties dialog box when a user creates or edits a bitmap checkpoint.

Creating a custom comparer in C++ using Microsoft Visual Studio:

1. In Microsoft Visual Studio, select New > Project. The New Project dialog box opens.

2. Select the ATL Project template, enter SampleCPPCustomComparer in the Name box for the project, and click OK. The New ATL Project wizard opens.

3. In Application Settings, make sure that the Attributed option is not selected, and click Finish.

4. In the class view, select the SampleCPPCustomComparer project, right-click, and select Add > Class. The Add Class dialog box opens.

5. Select ATL Simple Object and click Add. The ATL Simple Object Wizard opens.

6. In the Short name box, enter BitmapComparer. The wizard uses this name to create the names of the class, the interface, and the files that it creates.

7. In the Type box, enter Sample Custom Comparer. This is the custom comparer name that QuickTest will display in the Bitmap Checkpoint Properties dialog box and in the test results.

8. Click Finish. The wizard creates the necessary files for the class that you added, including .cpp and .h files with implementation of CBitmapComparer class.

9. In the class view, select CBitmapComparer, right-click, and select Add > Implement Interface. The Implement Interface wizard opens.

10. In the Implement interface from option, select File. Browse to or enter the location of the QuickTest bitmap checkpoint comparer type library. The type library is located in: \dat\BitmapCPCustomization\BitmapComparer.tlb.

The wizard displays the interfaces available in the selected type library, IBitmapCompareConfiguration and IVerifyBitmap.

11. Add both interfaces to the list of interfaces to implement, and click Finish.
In the BitmapComparer.h file, the wizard adds the declarations, classes, and method stubs that are necessary to implement the interfaces. In subsequent steps you will need to add implementation to these method stubs.

Please note that in Microsoft Visual Studio 2005, the wizard generates the signature for the CompareBitmaps method in the IVerifyBitmap interface incorrectly. To enable your project to compile correctly, manually change the type of the last argument (pbMatch) from BOOL* to VARIANT_BOOL*.

12. Open the BitmapComparer.h and BitmapComparer.cpp files.

13. In BitmapComparer.h, create declarations for the bitmap checkpoint comparer interface methods (based on the function bodies that the wizard created): CompareBitmaps, GetDefaultConfigurationString, and GetHelpFilename.

14. Move the function bodies that the wizard created for the bitmap checkpoint comparer interface methods from the BitmapComparer.h file to the BitmapComparer.cpp file.

15. For QuickTest to recognize the COM object that you create as a custom comparer, you must register it to the component category for QuickTest bitmap comparers. The component category ID is defined in \dat\BitmapCPCustomization\ComponentCategory.h.

You can implement this registration in the DllRegisterServer and DllUnregisterServer methods in the SampleCPPCustomComparer.cpp file that the wizard created as part of your project. These methods are called when you run a DLL using the regsvr32.exe program.

- Add the \dat\BitmapCPCustomization folder to your project's include path.

- Open the SampleCPPCustomComparer.cpp file and add the following line: #include "ComponentCategory.h"

- In the SampleCPPCustomComparer.cpp file, modify the DllRegisterServer and DllUnregisterServer methods created by the wizard.

Your custom comparer can now be used in QuickTest for bitmap checkpoints by using the following steps:

a. Open QuickTest and create a bitmap checkpoint on the Windows Calculator application (Standard view).The Bitmap Checkpoint Properties dialog box includes the Comparer option, in which you can select the QuickTest default comparer or your sample custom comparer.

b. Change the Calculator view to Scientific. The size of the calculator object is now larger. Run the checkpoint using the default QuickTest comparer. The checkpoint fails.

c. Edit the checkpoint and select Sample Custom Comparer in the Comparer box.

Generaly, tests and their resource files are stored on network drive or in Quality Center, as this enables the reuse of actions and other resources, and helps ease test management.

However, you may need to open or run a test when you do not have access to a network drive or Quality Center. For example, you may need to create a portable copy of a test for use when travelling to other sites. You can save a standalone copy of your test and its resource files to a local drive or to another storage device using the File > Save Test with Resources command.

When you save a test in this manner, QuickTest creates a copy of the following and saves the files in the location you specify:

1. Source test: QuickTest saves a copy of this test in the location you specify.

2. Resource files: QuickTest saves a copy of all resource files associated with the source test, such as function libraries and shared object repositories. QuickTest stores these files in sub-folders of the copied test.

3. Called actions: QuickTest saves a copy of any external actions called by the source test. For example, if Test A calls actions that are stored in Test B, QuickTest creates a local copy of the actions stored in Test B and stores them in a sub-folder of Test A. The sub-folder has the same name as the test from which the called actions were copied. In this example, the sub-folder is named Test_B. QuickTest also creates a copy of any resources associated directly with these actions, such as its local shared object repositories and action sheets in the Data Table. QuickTest does not, however, save the resource files associated with Test B, so you must ensure that these resources are associated with the source test, Test A.

This enables you to modify or run the test without access to a network drive or Quality Center.

Also, if you use QuickTest with a concurrent license but do not have access to the concurrent license server, you can install a commuter license. For more information, see the HP QuickTest Professional Installation Guide.

QuickTest Professional enables you to compare existing assets from two different object repositories using the Object Repository Comparison Tool. The tool is accessible from the Object Repository Manager, and enables you to compare different object repository resources, or different versions of the same object repository resource, and identify similarities, variations, or changes.

You can compare two object repositories by following below steps:

1. In QuickTest Professional, select Resources > Object Repository Manager.

2. In the Object Repository Manager, select Tools > Object Repository Comparison Tool. The New Comparison dialog box opens on top of the Object Repository - Comparison Tool window.

3. In the First file and Second file boxes, enter or browse to and select the .tsr object repository files that you want to compare. The object repository files can be located in the file system or Quality Center. By default, the boxes display the last files selected for comparison using the Object Repository Comparison Tool. You can click the down arrow next to each box to view and select recently used files.

4. Click OK. The Object Repository Comparison Tool compares the objects in the selected object repositories and displays the results in the Statistics dialog box on top of the Object Repository - Comparison Tool window.

5. Review the statistics.

6. In the Object Repository - Comparison Tool window, you can:

- Filter the objects in the object repositories
- Find specific objects in the object repositories

Please note that the Object Repository Comparison Tool does not compare checkpoint or output objects. You cannot work with the Object Repository Manager or the Object Repository Merge Tool when the Object Repository Comparison Tool is open.

This Comparison Tool automatically identifies objects during the comparison process by classifying them into one of the following types:

1. Identical: Objects that appear in both object repository files. There is no difference in their name or in their properties.

2. Matching description, different name: Objects that appear in both object repository files that have different names, but the same description properties and values.

3. Similar description: Objects that appear in both object repository files that 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. This implies that it is likely to be a less detailed description of the same object. For example, an object named Button_1 in the second object repository has the same description properties and values as an object named Button_1 in the first object repository, but also has additional properties and values.

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 object repositories but with different names, they will be shown in the object repositories as two separate objects.

Please note that the Object Repository Comparison Tool gives precedence to matching object descriptions over the matching of object names. For this reason, certain object nodes may be linked during the comparison process and not others.

4. Unique to first file, or Unique to second file: Objects that appear in only one of the object repository files.

5. Does not exist: Objects that do not exist in one of the repository files, but do exist in the other file.

After the compare process, the Comparison Tool provides a graphic presentation of the objects in the object repositories, which are shown as nodes in a hierarchy. Objects that have differences, as well as unique objects that are included in one object repository only, can be identified according to a color configuration that you can select. Objects that are included in one object repository only are identified in the other object repository by the text "Does not exist". You can also view the properties and values of each object that you select in either object repository.

If you are connected to a Quality Center 10.00 project with version control enabled, you can compare two versions of the same object repository.

In QTP 10.00, you can view comparison of two versions of an asset either side-by-side, or one above the other.

Compare versions of an integral element: You can view a drilldown comparison of a specific element in the currently open version comparison. Elements include any resource that is an integral part of the test (not saved as an external resource), such as the Data Table or local object repository. When you check in a test, these elements are checked in, too. This enables you to view a version comparison of these elements directly from the test.

View the latest content of an associated resource file: An associated resource file is any resource file used by an asset. For example, a function library and a shared object repository are examples of resource files that can be used by a test. When you drill down in a test, you can view the last saved version of a resource file. This enables you to view the latest content. (If you want to compare different versions of the drilled-down resource, you can open the resource and perform a new comparison.)

To drill down:

1. Click the blue drilldown arrow adjacent to any asset that can be compared.
2. Double-click the element.
3. Right-click the element and select View Drilldown of Selected Asset.

View the QuickTest location of an element: You can view a screen capture depicting the QuickTest location of an element by right-clicking the relevant node and selecting View Sample Snapshot. The screen capture displays an example of the relevant dialog box. The option (or area) for the node you right-clicked is highlighted in the screen capture.

For example, suppose you are viewing a comparison of a test, and you notice that the Disable Smart Identification during the run session node is highlighted, indicating that it was changed. If you are not sure where this option is located in QuickTest, you can right-click the node in the comparison tree and select View Sample Snapshot. QuickTest then opens a dialog box showing you that this area is located in the Run pane of the Test Settings dialog box. The title bar of the dialog box lists the selected element, and a purple rectangle outlines the option.

You can modify the text and background colors for the filter types (changed, added, removed, and so on) in the Asset Comparison Tool window using the Color Settings dialog box.

When you modify the background color of a filter type, the color of the filter type in the legend at the top of the window changes accordingly. These changes remain in effect unless you change them again or restore the default settings

If the sub-elements of an element are different between versions, and you collapse the node representing that element, a legend is displayed adjacent to the node. This legend indicates the number of differences that exist under the collapsed element.

The Resources and Dependencies model provides very good integration between QuickTest and Quality Center.

1. It replaces the use of attachments with linked QuickTest assets. You store your tests in the Test Plan module, and you store your resource files in the Test Resources module. When you associate a resource file to a test, these assets become linked. Linking assets improves runtime performance by decreasing download time. It also helps to ensure that the relationships between dependent assets are maintained. (Using attachments increases download time from Quality Center 10.00)

2. It also supports versioning & baselines for tests and resource files. You can create versions of these assets in QuickTest or in Quality Center. You manage asset versions and baselines in Quality Center.

3. Enables you to view and compare your QuickTest assets in both Quality Center and QuickTest. You can use the Asset Comparison Tool to compare versions of individual QuickTest assets and the Asset Viewer for viewing an earlier version of a QuickTest asset. Both of these viewers are available in Quality Center and in QuickTest.

4. Enables you to import and share assets across Quality Center projects.

Further, please note that if you are working with the Resources and Dependencies model with Quality Center 10.00, specify an absolute Quality Center path.

New version of QTP offers the following product and feature enhancements. Click a link to view more details about the selected item.

1. Upgrade from QuickTest 9.5: If QuickTest 9.5 is installed on your computer, you can choose to upgrade to QuickTest version 10.00. This enables you to continue using many of the configurations and options you already set in QuickTest 9.5. You can also use an msi silent installation command line to upgrade from QuickTest 9.5.

2. Improved IntelliSense Functionality: QuickTest now provides full IntelliSense for the following types of objects:

- Objects created by a step or function (for example, by calling the CreateObject method)
- Variables to which an object is assigned
- Reserved objects
- COM objects
- Properties that return objects
- IntelliSense sentence completion now provides lists of local variables.
- Multi-level IntelliSense information is available for all reserved objects, COM objects, and objects created using the CreateObject method. For example, method names and available properties are offered for each item in the statement below:

attr_count = XMLUtil.CreateXML.ChildElementsByPath("").ItemByName("abc").Attributes.Count

3. Added Control for Editing and Managing Actions in Automation Scripts: The QuickTest Professional Automation Object Model has a new set of objects and methods for manipulating test actions and action parameters. You can now use automation scripts to create new actions, modify and validate the syntax of action scripts, create and modify action parameters, and more.

4. Improved Debugger Pane Design and Functionality: The Debug Viewer pane has a new look, including icons to help you identify the type of information displayed.

The Watch tab and Variable tab now display the types of expressions or variables, in addition to their names and values.

The Command tab now displays the command history (in read-only format) in addition to the command line, enabling you to view previously-run commands and select commands to reuse.

In addition, a right-click context menu in the Command tab enables you to:

- copy from the command history and edit the command line using the clipboard.
- clear the command history.

5. New Object Identification Solutions in Maintenance Run Mode: In addition to helping you update your steps and object repositories when objects in your application change, the Maintenance Run Wizard can now help you solve the following problems:

- The step failed because the object in your test is missing from the action's associated object repositories.
- The object in your step exists in the application, but can be identified only through Smart Identification.

6. Additional Configuration Settings for Text Recognition Mechanism: You can now set all text recognition configuration settings from the QuickTest Options Dialog Box (Tools > Options > General > Text Recognition), including new options for selecting the text block mode and specifying the languages to be used with the OCR mechanism. This makes it easier to make any necessary adjustments and to optimize the way that QuickTest identifies text in your application.

7. New Look for Options, Settings, and File Dialog Boxes: The QuickTest Options and Settings dialog boxes have changed from their former tab-based design to a more easily navigable tree-based structure. The tree contains only the options relevant for the add-ins that are currently loaded.

QuickTest file dialog boxes such as the New, Open, and Save dialog boxes, now include a sidebar for quickly switching between the file system and Quality Center and for switching between various Quality Center resource storage locations.

8. QuickTest Toolbar Customization Options: You can use the new Customize Dialog box (Tools > Customize) to customize the appearance of existing menus and toolbars, and to create your own user-defined menus, toolbar buttons, and shortcuts.

You can also add new commands to the QuickTest Tools menu so that you can launch an application directly from the menu. For example, you can use this option to create a shortcut to the application you want to test or to an automation script.

9. Improved Web Extensibility: QuickTest Professional Web Add-in Extensibility enables you to develop packages that provide high-level support for third-party and custom Web controls that are not supported out-of-the-box by the Web Add-in.

Limited extensibility support for the ASP .NET AJAX Control toolkit is provided with the extensibility installation. You can use this package as an example for reference or as a basis for your own Ajax extensibility packages.

By creating support for a Web control using Web Add-in Extensibility, you can direct QuickTest to recognize the control as belonging to a specific test object class. You can also extend the list of available test object classes that QuickTest is able to recognize and the list of operations that are available for each class. This enables you to create tests that fully support the specific behavior of your custom Web controls.

The QuickTest Professional Web Add-in Extensibility SDK 10.00 offers the following improvements:

- The Web Add-in Extensibility SDK now provides a global object, window, that you can use in your JavaScript code to access the Internet Explorer global namespace. This enables you to access client-side JavaScript objects and functions in the application you are testing.

- You can now use the Microsoft Script Debugger or the Microsoft Visual Studio debugger to debug JavaScript code that you write for Web Add-in Extensibility.

- The LogLine method provided by the _util object can now (optionally) accept a numeric ID and a numeric Category for the log entry that it passes to the event log. Users can later use this information to filter log entries in the Event Viewer. In addition, the LogLine method can now accept string values for the severity argument, in addition to numeric values.

10. .NET Add-in and Extensibility Improvements:

- The .NET Add-in now supports learning, recording, and running on .NET Windows Forms property grids. QuickTest learns these controls using the new SwfPropertyGrid test object class.

- The .NET Add-in has a new GetErrorProviderText method and ErrorProviderText identification property, which is supported for all .NET Windows Forms test objects. You can use this method or property to retrieve the tooltip text of the error icon associated with the object.

- The C# and Visual Basic project templates and wizards provided with the .NET Add-in Extensibility SDK installation are now provided on Microsoft Visual Studio 2008 (as well as on Microsoft Visual Studio .NET and Microsoft Visual Studio 2005).

- .NET Add-in Extensibility now enables users to create support for table checkpoints on custom .NET Windows Forms table controls

11. New Terminal Emulator Configuration Validation: The Terminal Emulator pane of the Options dialog box now includes a Validate button. When you click this button, QuickTest checks the current configurations of the selected emulator. If a problem is detected, a brief description is displayed in the pane. You can also click the Troubleshoot button to view a Help page that provides additional information about the detected problem.

QTP 10.00 includes a excellent feature of new reporting options that help you analyze and manage your run results more thoroughly and efficiently. These include:

1. Jump to step: When you want to know more about a particular node in the Test Results window, right-click it and select Jump to Step in QuickTest. The QuickTest main window comes into focus, and the cursor jumps to the relevant step.

2. Export Test Results to Microsoft Word or PDF Formats: In addition to HTML format, you can now select to save your QuickTest run results in Microsoft Word or PDF formats. You can then share this information, together with any local system monitoring data, with your developers and performance testing teams.

3. Add Images to the Test Results: When you use the Reporter.ReportEvent method to add information to the run results, you can now specify an image file as the fourth argument. When you view the results, the image is displayed in the Result Details tab of the Test Results window. For example, you can include an image returned by a CaptureBitmap step in the run results.

4. View Bitmaps Differences in Bitmap Checkpoints: In addition to the expected and actual bitmaps that are displayed in the Test Results window, you can also select to view the differences between the two. The difference bitmap is a black-and-white image that contains one black pixel for every pixel that is different between the two images.

5. Include Images in Exported and Printed Test Results: When you choose the Detailed option for printing or exporting, the document now includes all images. These include screen captures of steps, expected, actual, and difference bitmaps for bitmap checkpoints, and any images sent to the run results using the ReportEvent method.

6. Additional Quality Center Details: The run results for tests and components that are run as part of a Quality Center test set now include the Quality Center server and project name.

QuickTest Professional (QTP) 10.00 has a powerful feature of new Quality Center 10.00 integration capabilities for QuickTest assets, Dependencies, and Versions. QuickTest assets include tests, components, application areas, and the resources associated with them, such as shared object repositories, function libraries, recovery scenarios, and external data tables.

These integration capabilities include:

- New resources and dependencies model for storing and managing shared assets
- Excellent Support for asset versioning and baselines
- Good asset Comparison Tool for comparing versions of individual QuickTest assets
- Asset Viewer for viewing an earlier version of a QuickTest asset
- A special tool for Quality Center administrators that upgrades all QuickTest assets to use these new features.

1. New resources and dependencies model: The new Quality Center resources and dependencies model enables you to store your tests, components, and resources such that you can manage the relationships between them and you can analyze the impact on all your assets when one asset changes.

If you are working with a Premier edition Quality Center server, then you can also import and share your resources across different projects. You can synchronize these assets in both projects when changes are made. This functionality also enables you to reuse your existing assets instead of creating new assets whenever you create a new project. For example, you can create a set of template assets to use as a basis for new projects.

In previous versions of QuickTest and Quality Center, a test's associated resource files (such as shared object repositories, function libraries, recovery scenarios, and external data tables), were stored in Quality Center as attachments, while files associated with an application area were stored in a standalone Resources folder in the Business Components module.

Quality Center 10.00 introduces a new Test Resources module. This module enables you to store all of these resources as separate entities that are linked to their owners and marked as dependencies. Tests or actions that call other tests are also linked as dependencies.

When you select a QuickTest test, business process test, or individual component in the Quality Center test or component tree, you can view these dependent resources and tests in a new Dependencies tab. The Dependencies tab shows all Quality Center entities that are used by your testing document as well as all entities that are using it. For example, if your QuickTest test is associated with two function libraries, and the actions in your test are associated with three object repositories, these entities will be displayed in the Using table of the test's Dependencies tab. If one of the actions in your test is called by another test, then that calling test will be displayed in the Used by table.

In QuickTest, you can also view the action-specific dependencies in the Used By tab of the Action Properties dialog box.

Quality Center recognizes assets that are linked as owned by or owner dependencies and ensures that these important relationships are maintained when you import or create baselines, rename or move resources, select to delete resources, or perform other operations that can impact these relationships.

Note: If required, you can continue using the previous attachments model for all or some of your QuickTest assets. However, if you use the old model, you will not be able to take advantage of many of the features associated with the resources and dependencies model.

2. Versioning: In previous versions of QuickTest and Quality Center, limited version control options were available if your Quality Center server had the Version Control Add-ins, which worked with third-party version control tools to perform version control. Now, version control is fully integrated into Quality Center, and the site administrator can enable version control on a per project basis.

When QuickTest is connected to a Quality Center project with version control support, you can check any QuickTest asset into or out of the version control database.

3. Baselines: In Quality Center, a project administrator can create baselines that provide "snapshots" of a project at different stages of development. In the Management module—Libraries tab, the administrator first creates a library, which specifies the root folders from which to import the data. The administrator then creates the actual baseline, which comprises the latest checked in versions of every asset included in the library. The administrator can also import and share entire baselines from other Quality Center projects.

When a project reaches an important stage in the project lifecycle, the administrator can create a new baseline of the files in the library at that point.

In Quality Center, these baselines can be viewed and compared in their entirety. In QuickTest, you can view, retrieve, or compare the individual assets saved in any baseline of a library. This enables you to review an asset as it appeared at a specific phase in the project time line.

Also, please note that baselines are supported in Quality Center 10.00 Enterprise and Premier editions only. They are not supported in Quality Center Starter edition.

4. Asset Comparison Tool and Asset Viewer: The QuickTest Asset Comparison Tool enables you to compare two versions of a particular QuickTest asset, such as a test, function library, shared object repository, or recovery scenario. For example, tests in different baselines or shared projects may be using different versions of the same resource. You can use the comparison tool to make sure that each test is using the correct version of its resources.

The QuickTest Asset Comparison Tool compares each element of the asset in a hierarchal display. The tool also enables you to drill down to view a comparison of the assets that are associated with that asset. For example, when comparing two versions of a test, the comparison may indicate that two of the function libraries, a recovery scenario, and some of the action steps changed between the two versions. You can then drill down to view a comparison of the two versions of any of these items.

The QuickTest Asset Viewer is similar to the Asset Comparison Tool, but is used to view the data for a single version of a QuickTest asset.

5. Asset Upgrade Tool: The QuickTest Asset Upgrade Tool for Quality Center enables you to upgrade, in a batch, all the QuickTest assets in a Quality Center project from an earlier QuickTest version to the current format and to convert testing document attachments to the new resources and dependencies model. QuickTest assets include:

a. QuickTest testing documents, such as tests, components, and application areas
b. Testing document attachments, such as function libraries, shared object repositories, and recovery scenario files

This tool is intended for use only by the Quality Center Administrator and must be run during the Quality Center upgrade process, before you begin working with Quality Center integration features.

The QuickTest Asset Upgrade Tool for Quality Center is the only way to upgrade QuickTest assets in a Quality Center 10.00 project, from an earlier QuickTest version to the current format.

Before starting the actual testing, it is important to check whether the system / project / environment is ready for testing. This is called as Test Readiness Review. It is better to do it with a checklist.

Below is a sample Test Readiness Review Checklist:

1. Whether all the tests are conducted according to the Test Plan / Cases ?

2. Are all problems / defects translated into Defect Reports ?

3. Are all the Defect Reports satisfactorily resolved ?

4. Is the log of the tests conducted available?

5. Is unit testing complete in all respects?

6. Is Integration testing complete ?

7. Is all the relevant documentation baselined ?

8. Is all work products products baselined?

9. Is the test plan baselined ?

10. Does the test plan contain the strategy / procedure to conduct the system test ?

11. Are baselined test designs and test cases ready?

12. Is unit/integrated test software ready ?

13. Is the user manual ready?

14. Is the installation procedure documented ?

15. Are all the product requirements implemented?

16. Is the list of known problems available? Is there any "workaround" procedure for the known bugs ?

17. Are test environment needs met for Hardware, code, procedures, scripts, test tools etc.?

18. List of exceptions in test software and test procedures and their work around if any?

19. Is the test reporting tool is available?

20. Are the designers educated on Test reporting tool?

21. Is any standard methodology / tool used and is appropriate to the type of the project?

22. Is the criteria for regression testing defined? Has the regression testing been done accordingly?

23. Is the source code available from the client for performing regression testing complete in all respects?

24. Is the source code freezed for testing?