Delphi Add-in in QTP 10

Below is the basic information about the Delphi Add-in and how it relates to some commonly-used aspects of QTP.

General Information:

Add-in Type: This is a Windows-based add-in. Much of its functionality is the same as other Windows-based add-ins.

Checkpoints and Output Values: Bitmap, Standard, Table, Text, Text Area, XML.

Prerequisites:

Opening Your Application: You can open your Delphi application before or after opening QTP.

Add-in Dependencies: None

Other: Before running a test on a Delphi application, the application being tested must be compiled with the QTP Professional agent MicDelphiAgent.

Setting Preferences:

Options Dialog Box : Use the Windows Applications pane. (Tools > Options > Windows Applications node)

Record and Run Settings Dialog Box (tests only):

Use the Windows Applications tab.
(Automation > Record and Run Settings)

QTP recognizes only Delphi applications that have been precompiled with the MicDelphiAgent.pas module.

Custom Active Screen Capture Settings Dialog Box
(tests only): Use the Windows section. (Tools > Options > Active Screen pane > Custom Level button)

Application Area Settings Dialog Box: Use the Applications pane. (File > Settings > Applications node).

Localization Testing

Localization testing is part of software testing focused on internationalization and localization aspects of software.

Localization Test is the process of adapting globalized application to a particular culture/locale. Localizing the application requires a basic understanding of the sets of character commonly employed in modern software development and an apprehension of the risks associated with them.

Localisation testing checks how well the build has been interpreted into a particular target language. This test is founded on the results of globalized validation where the functional support for that particular locale has already been validated. Whenever the product is not globalised enough to support a given language, you probably will not try to focalise it into that language in the first place.

You still have to check that the application you are delivering to a specific market actually works and the following section shows you some of the common areas on which to focus when executing a Localization of test.

Localization testing contains the translation of the application user interface and adapting graphics for a particular culture/locale. The localisation process can also include translating any help content associated with the application program into native language.

Localisation of business solutions needs that you implement the correct business processes and practices for a culture/locale. Differences in how cultures/locales conduct business are to a great extent determined by governmental and regulatory requirements. Hence, localisation of business logic can be a big task.

Things which are often altered during localization, such as the user interfaces and content files. Below is a sample localization testing checklist:

- Spelling Rules
- Sorting Rules
- Upper and Lower case conversions
- Printers
- Size of Papers
- Operating System
- Key boards
- Text Filters
- Hot keys
- Mouse
- Date formats
- Measurements and Rulers
- Available memory

Note: It is as well a good idea to test that everything you are going to distribute in a local market complies with the local laws and regulations

IBM RFT FAQ - 2

Q. 28: What are the environmental prerequisites prior to playback of RFT scripts?

Ans.

- Make sure that the application under test is in the same state that it was in when you record the script.
- Ensure that applications and windows that were open or displayed or active when we started recording the script must be open or displayed or active when we start playback.
- Ensure to restore relevant network settings, active databases and system memory (if any) to the same state as when the script was recorded.

Q. 29: When we run a RFT script what actions are performed?

Ans. When script runs from Rational Functional Tester, it plays back all recorded actions. Playback Monitor starts and provides information when the script plays back. A log file gets displayed after the script runs completed. When script runs from Test Manager, Test Manager creates a temporary suite, runs the suite and removes the suite after the run is completed. We can run a script either from the Test Manager Test Scripts window or from the Test Manager File menu.

Q. 30: Out of test scripts or test cases which one should be run to generate test case results?

Ans. Test cases should be run to generate test case results instead of the script. If we run a script the Test Manager does not generate test case coverage results.

Q. 31: Describe the process of debugging of scripts in Rational Functional Tester.

Ans. If the scripts are recorded in the Java programming language - debugging scripts is the same process as debugging a Java application. If the scripts are recorded in the VB.NET Scripting - debugging scripts is the same process as debugging a Visual Basic application.

Q. 32: What is the procedure to create data pools in Rational Functional Tester?

Ans. A data pool is a test data set - a collection of related data records which supplies data values to the variables in test script during test script play back. You can create data for a data pool from scratch or we can import existing data into a new data pool from another Functional Tester data pool or from a .csv file.

Note: If you need to import the data, you will need to import the data into the same Rational Functional Tester project as the test scripts that access the data. If you need to import data from Test Manager data pool, you will need to first associate a RFT project with a Rational project to use the Test Manager data pool.

Q. 33: What type of changes we can do in a data pool?

Ans. Once we data drive a test to create a data pool or create an empty data pool, then we can edit the records and variables in the data pool. We can
1) Add – Remove – Move - Edit a record and variable
2) Edit data pool values
4) Cut - Copy or Paste a cell or record or a variable

Q. 34: Can we replace literal values in a script with data pool references?

Ans. Yes. We can replace literal values in existing script with data pool references to add realistic data to the script. We can replace all literal values or just the number or string or Boolean literals with a data pool reference. If we do not use an existing datapool variable, then the same literal values are used each time we run the script.

Q. 35: Which events take place when we run a script?

Ans. Verification point accesses the data in the datapool and creates the expected results from the baseline and the active data pool record. Datapool reference resolves and supplies data to verification point. The expected result is compared to the actual result. The expected and actual results are recorded in the log. Any deviations from the expected results are logged as a failure in the test log.

Q. 36: Name the two types of datapool record selection orders available in RFT?
Ans. Sequential record selection order and Random record selection order.

Q. 37: Explain the purpose of Test Object Inspector?

Ans. It is used to get a display of the test object information in running application. The information can be of parent hierarchy, inheritance hierarchy, test object properties, non-value properties and method information. Test Object Inspector automatically tracks the cursor and performs live updates after the application is opened. Test Object Inspector does not capture the object / objects in the application if it is not active.

Q. 38: What is the wait state feature for the objects?

Ans. In RFT, this feature is used to set wait state for an object during the playback to check its existence. It is useful when waiting for an object after starting the application or after other actions taking a long time.

Q. 39: What happens to the related files when we rename a test asset?

Ans. When we rename a script, Rational Functional Tester renames all its related files like the helper script files, private object map and any verification point files. If you rename a test object map, the associated scripts with the new name gets updated.

Note: After renaming operation, we need to change all callScript commands in scripts which reference the old script name.

Q. 40: How Data driving testing is helpful in RFT?

Ans: During data driven testing, the script uses variables for key application input fields and programs instead of literal values so that we can use external data to drive the application being tested. Data driven testing uses data from an external file called as datapool. We can add data to the data pool after finishing the recording of the test script.

Q. 41: Name two methods to select an object in an application under test in RFT?

Ans. Object Finder Tool method and Test Object Browser method

Q. 42: Name the various types of datapools in Rational Functional Tester.

Ans. There are two types of datapools: Private datapool and Shared datapool

Q. 43: In how many ways test scripts can be saved in RFT?

Ans. Three ways: Save the current test script or file, Save all test scripts & files and Save a script under another name

Q. 44: Sometimes record monitor goes blank when recording against Java or HTML application. What is the reason for that?

Ans. Record Monitor goes blank while recording against Java or HTML application when JREs or browsers are not enabled.

Q. 45: What are the actions performed by the agent computers?

Ans.

- Running the scripts on more than one computer.
- Test different machine configurations.
- Run Functional Tester scripts remotely on Linux or Windows computers.

Q. 46: What is required to run a RFT script from Test Manager?

Ans. Java Scripting / VB.NET Scripting. On a remote computer, you need to install Rational Test Agent software on the Agent computer and start the agent.
However, if we need external library to run scripts, then we need to install the software on the system on which we plan to run the script. To install a .dll, you need to add the library to directory that is in system search paths and to install a .jar file, you will need to add it to the Functional Tester customization directory. Default location for the customization directory is: C:\ Documents and Settings \ All Users \ Application Data\IBM\RFT\customization

Q. 47: What is the purpose of using Script Assure in RFT?

Ans. This feature helps the successful playback of scripts even when the application under test has been updated. We can play back scripts in RFT by using the ScriptAssure feature to control object-matching sensitivity.
For RFT to recognize an object in the application-under-test, the object properties must match the properties recorded in test object map. RFT can find the object if 1 or 2 properties do not match. If 2 properties do not match, RFT gives a weak recognition warning to the log. If more than 3 properties do not match, RFT cannot find the object in the application.

Q. 48: Ways of using ScriptAssure in RFT.

Ans. - Standard way: ScriptAssure Page - Standard controls object-matching sensitivity during playback by using a slider control.
- Advanced way: The ScriptAssure Page - Advanced sets thresholds for recognition scores. You can set a maximum score to consider a test object as a candidate for recognition.

Q. 49: What is the purpose of Hover feature during recording?

Ans. Hover feature is useful to move the mouse towards a particular place during playback in HTML application. It is helpful for clicking on menus or links in HTML testing.

Q. 50: What are the six steps involved in test development using RFT?

Ans

- Restore test environment and set the playback options.
- Play back each script against the same version of the application under test that was used for recording.
- Analyze the results in the Rational Functional Tester log.
- Use Functional Tester Verification Point Comparator for determining the cause of verification point failures.
- If the script fails; then edit it or debug it or re record it so that it runs as required.
- If we associate a Rational Functional Tester project with the current Rational project, we can group various scripts into test suite and play back the suite to verify that the scripts work properly.

Q. 51: What are the two main phases of script playback?

Ans. Test Development Phase and Regression Testing Phase

Q. 52: What are the six steps involved in regression testing phase using Rational Functional Tester?

Ans.

- Restore testing environment and set playback options.
- Play back test script against a new build of the application under test.
- Analyze the test results in the Rational Functional Tester log.
- Use the Rational Functional Tester Verification Point Comparator to determine the cause of verification point failures.
- If required, revise your test scripts to use new features in the application under test and playback the revised test scripts.

Q. 53: What is purpose of Playback Monitor in Rational Functional Tester?

Ans. Using playback monitor, during the playback of script; we can view the script name, number of the line that is executing, status icons and a description of the action in progress.

Q. 54: What are the Local and agent computers / machines in RFT?

Ans. When we associate Rational Functional Tester project with a Rational project, we can use Test Manager to run the RFT scripts on computers that are designated as Agent computers from a single Windows computer called the Local computer.

Also See:

- Rational Functional Tester Interview Questions - 1

Rational Functional Tester Interview Questions - 1

Q. 1: What are the main features of Functional Tester?

Ans.
- Complete functional testing of the application
- test the state of objects through verification points.
- Testing any object in the application, including the object's properties and its data.
- Creating and editing simple object-oriented test scripts.
- Generating code through wizards, for example automatically creating a verification point through wizard.

Q. 2: What Process is followed by Rational Functional Tester for test automation?

Ans. Recording of Test Scripts, Enhancing the Test Scripts and then Playing Back the Scripts

Q. 3: For how many development platforms & Languages Functional Tester is available?

Ans.
- Java Scripting uses the Java language and the IBM Rational Software Development Platform.
- VB.NET Scripting uses the VB.NET language and the Microsoft Visual Studio .NET development environment.

Q. 4: What is benefit of test object map in Rational Functional Tester?

Ans. Test object map gets created automatically when recording the script for the application under test. It provides quick way to add objects to a script. It creates a list of test objects available in the application whether they are currently displayed or not. We can create a new test object map either by basing it on an existing map or by adding objects as required. It contains recognition properties for every object; so we can update the recognition information in one central location. Therefore, any scripts using this test object map shall be able to share the updated information. Test object maps created for HTML applications are more hierarchical than those created for Java applications. A browser is the top level of the test object map and the HTML application is inside the browser.

Q. 5: How various objects are identified by Functional Tester?
Ans. In Functional Tester object-oriented technology is used to identify various objects by their internal object properties and not by their screen coordinates. Thus even if the location or text of an object changes, the Functional Tester can still find it on playback.

Q. 6: In how many ways we can test the applications on Linux using RFT?

Ans.
First Way: We can record a script on Windows Environment and export it to Linux & then play it back on Linux.

Second Way: By writing scripts using the Test Object Insert tool. Instead of creating an object map through recording we populate it outside of the recorder by opening the map and selecting objects in the test application.
We can insert verification points without recording, by opening the Verification Point wizard from the Script Explorer.

Q. 7: What are two types of TestManagers in RFT?

Ans.
1) TestManager: It includes the Test Manager Log, running Windows & Linux remote playback agents and test management features like running scripts as part of a test suite. Functional Tester has its own logs and does not depend on the TestManager log integration.

2) ClearQuest Test Manager: It helps us in associating functional test scripts to Test Cases and executes them. Using CQTM we can analyze the received execution results and record those results for reporting and analysis.

Q. 8: What is a Rational and Functional Test project?

Ans. Rational Test project is used for storing test assets like test plans test cases, test logs, reports, builds etc. To associate a Functional Tester project with a Rational project, a Rational project needs to be created to store the test assets. Functional Test project stores all application test assets like scripts, object maps, verification point baseline files and script templates. Functional Test project is created before recording the scripts.

Q. 9: What is the use of associating a project with TestManager in RFT?

Ans. 1) Creating and playingback the scripts from within Rational TestManager.
2) Using the TestManager Agent for playing back scripts on remote computer.
3) You can view the scripts from the Test Scripts window of Rational TestManager.

Q. 10: Benefits of associating a Functional Tester project with Rational Project.

Ans.
1) Management of testing assets from one Rational project.
2) You can record and play back all Functional Tester scripts from Rational TestManager.
3) Playing back Functional Tester script on different computer using Rational Test Agents through TestManager.
4) Management Functional Tester logs using the Test Log window of TestManager.
5) Use of Test Manager reports to get information about the results of running Functional Tester test script and get coverage report for testing project.
6) Use TestManager suite to coordinate the way that scripts run.

Q. 11: Are there any restrictions when we disassociate a project from the current Rational project?

Ans. Yes. We can not play back Functional Tester script or test cases or suites that include Functional Tester scripts in disassociated project from TestManager. Test Manager deletes test script source from the disassociated project. This operation can not be undo. If we associate Functional Test project with Rational project again, TestManager creates new test script source.

Q. 12: Name three buttons available in Functional Tester Projects view banner.

Ans.
- Connect to Functional Test Project: It allows us to connect to an existing Functional Tester project.
- Refresh Projects: It enables us to repaint the display to reflect changes.
- Synchronize with Editor: It scrolls in the tree hierarchy to the name of the script currently displayed in the Java Editor.

Q. 13: Can we export Functional Test project items?

Ans. We can export project items like scripts, test object maps, Java files, Visual Basic files and data pools to another Functional Tester project. When we export a script Functional Tester includes all necessary files like shared test object maps even though it was not selected by us.

Q. 14: What is the utility of a verification points in Rational Functional Tester?

Ans. During the recording verification points can be inserted in the script to confirm the state of an object in the application.
A verification point captures the object information based upon the type of verification point and stores it in a baseline data file. The information in the base file becomes baseline of expected state of object during subsequent builds.

Q. 15: What types of verification points are provided by RFT?

Ans.: Rational Functional Tester has two types of verification points: Object properties verification point and Data verification points. Data verification point has five further points: Menu hierarchy verification point, Table verification point, Text verification point, Tree hierarchy verification point, List verification point.

Q. 16: How RFT playback depends upon the platform and the browser?

Ans.: Test playback in RFT is independent of the platform as well as independent of browser. E.g. we can record script on Windows and play it back on Linux. Also, the script contains no references to the browser during the recording, we can play back the script using any of the supported versions of Firefox, Mozilla, Internet Explorer or Netscape.

Q. 17: What host & test platforms supported by RFT?

Ans. Functional Tester runs on the following Host and Test platforms: Windows XP Professional, Windows 2000 Professional & Server, Windows 2000 Server & Advanced Server, Windows 2003 Enterprise, Standard & Server

Platforms supporting all functions of RFT except the recording: Red Hat Linux Enterprise Workstation 4.0, SuSE Linux Professional version 9.0, SuSE Linux Enterprise Server 10.0, Novel Desktop 10.0

Q. 18: What types of nesting of objects is supported by Functional Tester?

Ans. Parent-child nesting and Owner-owned nesting

Q. 19: Type of file extensions created while exporting Functional Test project items?

Ans. RFT compresses a copy of the files into a data transfer file with the name specified by us. It also appends a .rftjdtr (Functional Tester Java Scripting) or .rftvdtr (Functional Tester VB.NET Scripting) extension to it.

Q. 20: What is the helper superclass in RFT?

Ans. All Functional Tester scripts use default helper superclass. These scripts extend the RationalTestScript class and thereby inherit a number of methods. However, advanced users can create their own helper superclass (if they want to add additional methods or override the methods within RationalTestScript).

Q. 21: Name the Functional Test project items that can be imported?

Ans. Project items like scripts, test object maps, Java files or Visual Basic files, and datapools can be imported into a Functional Tester project. Functional Tester adds all the project items from the data transfer file into the project specified by us. We can use any file compression program which support the .zip to view and work with items in the data transfer file.

Q. 22: RFT provides how many type of delete Cookies methods?

Ans.
- Method of deleting all cookies for the current profile or user
- Method of deletes cookies in a specific page or domain for the current profile or user

Q. 23: How an application starts during recording the tests?

Ans. While recording tests the application can be started by using startApp command. It makes playing back the tests more reliable because startApp uses the application configuration information. RFT will open either Java applications that we specify or HTML pages in our browser, or run applications in executable form.

Q. 24: What is a test project in RFT?

Ans. Location where Functional Tester keeps all of the scripts, along with expected and actual results is called as a test project. The format of test project is governed by the environment being used.

Note: If you are using the Java language, create a Java test project. However you are using Visual Basic.NET, create a .NET test project.

Q. 25: How can we create a new RFT script without recording?

Ans. In new script > RFT includes import statements for files we need to compile the script and comments containing information of archiving. Functional Tester uses the script name as the class name and sets up testMain. Here, you can add the commands to include in the script.

Q. 26: Can we do recording in an existing RFT script?

Ans. Yes. We can do the recording in existing RFT script by bringing our cursor to the desired location & just start the recording. Start the application >> insert verification points >> and add all script support functions.

Q. 27: How can we record script for testing the HTML applications using RFT?

Ans.
- Enabling the Web browser: Enabling of the browser can be done by clicking on Configure > "Enable Environments for Testing". This will enable the environments for testing.

- Configuring the HTML applications for testing: It can be done by clicking on Configure > "Configure Applications for Testing" to specify information about our application and its environment. For testing MS HTML Applications (MSHTA), we need to run mshta.exe to configure application desired to be tested.

Agile Testing

Historically, testing has always been about finding where the software breaks. In fact, when we talk about the qualities of a good tester we quote anecdotes about how "she was able to break my program in 3 minutes" or that "he found 27 bugs when running on Linux with Apache". In other words, testing was about finding bugs. Testers would get rewarded for and take satisfaction from finding bugs.

Whereas agile testing is more about keeping the bugs out than finding the ones that are in there. The (automated) tests that are written in agile testing are more about showing that the software works the way we expect than about finding where it breaks.

This doesn’t mean that agile testers should not attempt to find bugs nor that pre-agile testers never write tests to show what works. It means agile thinking has introduced a change in emphasis from “fault-finding” to “working software”.

In pre-agile days, developers would bang away on the code until they considered it done. Then they would throw the code over the wall to QA to find the bugs. QA's first task would be to find the places where it would break. They'd submit a whole bunch of bugs which developers would fix. This cycle would repeat until they couldn't find any more.

Testing now happens closer to the developer in space and in time. Testers design tests to show that the software works as expected. The developers and testers work together in a room to expand the set of cases that works. The bugs should never get introduced in the first place.

In the old days the conversation might have gone something like this:

=========================================================
Developer: The baby has been delivered.
Tester: Your baby is early,
Developer: Everything works.
Tester: C is broken
Developer: fixed C
Tester: E doesn't work with X
Developer: fixed E with X
and so on until the tester can't find any more bugs.
=========================================================

In agile environment, it would go more like this:

=========================================================
Developer: A is done
Tester: A works

Developer: B is done
Tester: B works
and so on until every case works
=========================================================

Nature of Agile Testing:
The biggest difference between agile projects and most ‘traditional’ software development projects is the concept of test-driven development. With agile, every chunk of code is covered by unit tests, which must all pass all the time. The absence of unit-level and regression bugs means that testers actually get to focus on their job: making sure the code does what the customer wanted. The acceptance tests define the level of quality the customer has specified (and paid for!).

Testers who are new to agile should keep in mind the agile values: communication, simplicity, feedback and courage.

Difference between Traditional Testing and Agile Testing:

Agile testing was different in many ways from ‘traditional’ testing. The biggest difference is that on an agile project, the entire development team takes responsibility for quality. This means the whole team is responsible for all testing tasks, including acceptance test automation. When testers and programmers work together, the approaches to test automation can be pretty creative. Testing is integrated into software development. Having everyone in one room speeds up communication by an astonishing amount. Questions that might otherwise take a couple days to be answered over email are answered within a couple of minutes. There can be numerous occasions when hours of time could be saved by overhearing a conversation in the team room.

On traditional projects, folks with Quality somewhere in their title (Quality Assurance, Quality Engineers, et al) perform Independent Verification and Validation (IV&V) activities to assess the quality of the system. Often these teams also review design artifacts. Sometimes they also have a hand in defining and/or enforcing the process by which the software is made.

Agile project teams generally reject the notion that they need an independent group to assess their work products or enforce their process. They value the information that testing provides and they value testing activities highly. Indeed they value testing so much, they practice Test-Driven Development (TDD), writing and executing test code before writing the production code to pass the tests. However, even though agile teams value testing, they don't always value independent testers. And they're particularly allergic to the auditing or policing aspects of heavyweight, formal QA.

So how can testers make themselves useful on a team that does not see much use in traditional, formal QA methodologies? Here's what they can do:

1. Supporting Programmer Testing (Technology facing):

When supplementing programmer testing the testers support the programmers in creating the software. They sit in the synergy with the programmers. If the programmers are practicing agile, it's a given that they have an extensive set of unit tests. The tester’s role is not to do the programmers' unit testing for them. Instead, most of their work involves manual exploratory testing to discover important information about the software that the unit tests failed to reveal.

In order to do this, they have to:

- Get and build the latest source code.
- Run all the unit tests to verify they are starting from a "known good" place.
- Run the application (usually locally from the IDE).
- Minimize documentation: Test documentation can account for a large percentage of the test effort. An informal poll among 135 testers across 57 organizations revealed that testers spend about one third of their time just documenting test cases
- Occasionally add to the automated unit or acceptance test suites.
- Asking “what if” questions to programmers in the planning game. For example, “What if the migrated data has null values?” Analyzing risks and providing information early.
- Offering information about external dependencies or requirements that the team might not otherwise know about.

Unlike unit tests that use mocks and stubs to isolate the code under test, this exploratory testing is as end-to-end as possible. As a result, they are usually able to find issues and risks that the unit tests don't reveal. And they are finding them sooner than we would if we waited for the customer to try things end-to-end. (Early feedback is good.) In doing so, testers not only help the programmers improve the software, they also help them improve their unit tests.

To support programmer testing, you're going to have to be comfortable mucking about in source code. If you haven't coded in a long time (or ever) that means more than just learning Java or whatever language your organization uses. You'll also have to be comfortable:

- Working in the development environment the developers are using, whether that's Visual Studio, Eclipse, IntelliJ, or something else.
- Fetching and building the latest code from the source control system.
- Using the test frameworks the developers are using such as jUnit or NUnit.
- Configuring your own system and setting up your own data, so you may have to learn more about operating systems, networks, and databases

In short, technology-facing testers become members of the development team. You'll need to grow your technical skills accordingly.

Supporting Customer Testing(Business Facing):

The word "Customer" is used in the sense: The set of people who represent the business-facing stakeholders on a project, and not referring to the customers who pay for the software. When supplementing customer testing, they support them by helping them define and execute acceptance tests. Specifically, they:

- Walk through the existing software with them, using an interview-style conversation to surface assumptions and expectations.
- Use the information from walkthroughs and other sources to design and articulate acceptance tests.
- Use a variety of analysis techniques to discover risks and implications of decisions.
- Help the customers and programmers define what "good enough" means for their context.
- Execute acceptance tests manually where needed.
- Automate acceptance tests (either by automating them themselves or by working with a programmer or existing automation engineer)
- Provide metrics or other high level data as needed to help the Customer satisfy his management's need for numbers

In this second role, testers spend as much of their time facilitating communication and clarifying expectations.

To help business stakeholders articulate their needs, you're going to end up doing a whole lot of requirements extraction. Business-facing testing is as much about distilling requirements and testing assumptions as it is about testing software. There's an entire body of knowledge on requirements analysis, design analysis, and modeling that can help.

- Consider brushing up on UML.
-Learn how to be an effective interviewer and facilitator.
-Grow both your analysis skills and soft skills.

Fine-Tuning the Bitmap Comparison

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.

Jumping to a Step in QuickTest 10.00

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.

Installing Custom Comparer and Registering to QuickTest

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.

Considerations for Developing Custom Comparers

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.

Developing Bitmap Checkpoint Comparison Algorithm

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.

Creating Portable Copies of Tests

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.

Comparing Shared Object Repositories

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.

Asset Comparison Tool and Asset Viewer

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.

Resources and Dependencies Model

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.

Enhancements in QuickTest Professional 10

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.