The people component includes human resource allocations and the required skill sets. The test team should comprise the highest-caliber personnel possible. They are usually extremely busy because their talents put them in great demand, and it therefore becomes vital to build the best case possible for using these individuals for test purposes. A test team leader and test team need to have the right skills and experience, and be motivated to work on the project. Ideally, they should be professional quality assurance specialists but can represent the executive sponsor, users, technical operations, database administration, computer center, independent parties, etc. The latter is particularly useful during final system and acceptance testing. In any event, they should not represent the development team, for they may not be as unbiased as an outside party. This is not to say that developers shouldn’t test. For they should unit and function test their code extensively before handing it over to the test team.

There are two areas of responsibility in testing:

1. Testing the application, which is the responsibility of the test team
2. The overall testing processes, which is handled by the test manager.

The test manager directs one or more testers, is the interface between quality assurance and the development organization, and manages the overall testing effort. Responsibilities include:

• Setting up the test objectives
• Defining test resources
• Creating test procedures
• Developing and maintaining the test plan
• Designing test cases
• Designing and executing automated testing tool scripts
• Test case development
• Providing test status
• Writing reports
• Defining the roles of the team members
• Managing the test resources
• Defining standards and procedures
• Ensuring quality of the test process
• Training the team members
• Maintaining test statistics and metrics

The test team must be a set of team players and have the following responsibilities:

• Execute test cases according to the plan
• Evaluate the test results
• Report errors
• Design and execute automated testing tool scripts
• Recommend application improvements
• Record defects

The main function of a team member is to test the application and report defects to the development team by documenting them in a defect tracking system. Once the development team corrects the defects, the test team reexecutes the tests which discovered the original defects.

It should be pointed out that the roles of the test manager and team members are not mutually exclusive. Some of the team leader’s responsibilities are shared with the team member and visa versa.

The basis for allocating dedicated testing resources is the scope of the functionality and the development time frame, e.g., a medium development project will require more testing resources than a small one. If project A of medium complexity requires a testing team of 5, project B with twice the scope would require 10 testers (given the same resources).

Another rule of thumb is that the testing costs approach 25% of the total budget. Since the total project cost is known, the testing effort can be calculated and translated to tester headcount.

The best estimate is a combination of the project scope, test team skill levels, and project history. A good measure of required testing resources for a particular project is the histories of multiple projects, i.e., testing resource levels and performance compared to similar projects.

Identifing Manual / Automated Test Types

The types of tests that need to be designed and executed depend totally on the objectives of the application, i.e., the measurable end state the organization strives to achieve. For example, if the application is a financial application used by a large number of individuals, special security and usability tests need to be performed. However, three types of tests which are nearly always required are: function, user interface, and regression testing. Function testing comprises the majority of the testing effort and is concerned with verifying that the functions work properly. It is a black-box-oriented activity in which the tester is completely unconcerned with the internal behavior and structure of the application. User interface testing, or GUI testing, checks the user’s interaction or functional window structure. It ensures that object state dependencies function properly and provide useful navigation through the functions. Regression testing tests the application in light of changes made during debugging, maintenance, or the development of a new release.

Other types of tests that need to be considered include system and acceptance testing. System testing is the highest level of testing which evaluates the functionality as a total system, its performance and overall fitness of use. Acceptance testing is an optional user-run test which demonstrates the ability of the application to meet the user’s requirements. This test may or may not be performed based on the formality of the project. Sometimes the system test suffices.

Finally, the tests that can be automated with a testing tool need to be identified. Automated tests provide three benefits: repeatability, leverage, and increased functionality. Repeatability enables automated tests to be executed more than once, consistently. Leverage comes from repeatability from tests previously captured and tests that can be programmed with the tool, which may not have been possible without automation. As applications evolve, more and more functionality is added. With automation, the functional coverage is maintained with the test library.

Identifing the Test Exit Criteria:

One of the most difficult and political problems is deciding when to stop testing, since it is impossible to know when all the defects have been detected. There are at least four criteria for exiting testing:

Scheduled testing time has expired: This criteria is very weak, since it has nothing to do with verifying the quality of the application. This does not take into account that there may be an inadequate number of test cases or the fact that there may not be any more defects that are easily detectable.

Some predefined number of defects discovered: The problems with this is knowing the number of errors to detect and also overestimating the number of defects. If the number of defects is underestimated, testing will be incomplete. Potential solutions include experience with similar applications developed by the same development team, predictive models, and industry-wide averages. If the number of defects is overestimated, the test may never be completed within a reasonable time frame. A possible solution is to estimate completion time, plotting defects detected per unit of time. If the rate of defect detection is decreasing dramatically, there may be “burnout,” an indication that a majority of the defects have been discovered.

All the formal tests execute without detecting any defects: A major problem with this is that the tester is not motivated to design destructive test cases that force the tested program to its design limits, e.g., the tester’s job is completed when the test program fields no more errors. The tester is motivated not to find errors and may subconsciously write test cases that show the program is error free. This criteria is only valid if there is a rigorous and totally comprehensive test case suite created which approaches 100% coverage. The problem with this is determining when there is a comprehensive suite of test cases. If it is felt that this is the case, a good strategy at this point is to continue with ad hoc testing. Ad hoc testing is a black-box testing technique in which the tester lets his or her mind run freely to enumerate as many test conditions as possible. Experience has shown that this technique can be a very powerful supplemental or add-on technique.

Combination of the above: Most testing projects utilize a combination of the above exit criteria. It is recommended that all the tests be executed, but any further ad hoc testing will be constrained by time.

The purpose of test planning is to provide the basis for accomplishing testing in an organized manner. From a managerial point of view it is the most important document, because it helps manage the test project. If a test plan is comprehensive and carefully thought out, test execution and analysis should proceed smoothly.

The test plan is an ongoing document, particularly in the spiral environment since the system is constantly changing. As the system changes, so does it. A good test plan is one which:

• Has a good chance of detecting a majority of the defects
• Provides test coverage for most of the code
• Is flexible
• Is executed easily, repeatably, and automatically
• Defines the types of tests to be performed
• Clearly documents the expected results
• Provides for defect reconciliation when a defect is discovered
• Clearly defines the test objectives
• Clarifies the test strategy
• Clearly defines the test exit criteria
• Is not redundant
• Identifies the risks
• Documents the test requirements
• Defines the test deliverables

The planning test methodology includes three steps:

1. Building the test plan
2. defining the metrics
3. reviewing/approving the test plan.

Step 1: Build a Test Plan

- Prepare an Introduction
- Define the High-Level Functional Requirements (In Scope)
- Identify Manual / Automated Test Types
- Identify the Test Exit Criteria
- Establish Regression Test Strategy
- Define the Test Deliverables
- Organize the Test Team
- Establish a Test Environment
- Define the Dependencies
- Create a Test Schedule
- Select the Test Tools
- Establish Defect Recording / Tracking Procedures
- Establish Change Request Procedures
- Establish Version Control Procedures
- Define Configuration Build Procedures
- Define Project Issue Resolution Procedures
- Establish Reporting Procedures
- Define Approval Procedures

Step 2: Define the Metric Objectives

- Define the Metrics
- Define the Metric Points

Step 3: Review/Approve the Plan

- Schedule / Conduct the Review
- Obtain Approvals

Below are some usefull tips and general guidelines will help you become more efficient while using SiteCheck:

1. Is your Web server getting full? Click List View Defects Orphans to see all files that have no links to them. Delete those orphans you don’t need.

2. Can you remember the title of the document you are looking for but not the file name? Use List View to find the file by title and then view its other attributes, like the file name.

3. Use the toolbar filter buttons in Page View to reduce file clutter and help you better understand the structure of your Web site.

4. Rational SiteCheck automatically fixes links when you move files. All files and their respective links are maintained during this process. When working on local sites, you can drag files from one directory to another and the links to those files are preserved.

5. Source View offers you enhanced text editing, including color-coded text and a link-sensitive right-click menu. You can make on-the-fly updates to your HTML documents from Source View.

6. Rational SiteCheck can check all your links: the internal links within your site and external links to other Web sites.

7. Is it safe to delete a file? Select the document in Page View and you'll see all links to and from the file.

8. LinkWizard instantly recognizes when a file operation will affect links and can fix them automatically.

9. Rational SiteCheck saves you time by providing customizable e-mail templates that automatically create messages that you send frequently.

10. Check your content before going live. Rational SiteCheck's list of broken links will show all the documents that need repair.

11. Switch quickly between the views offered by Rational SiteCheck. The function keys F4 and F6 through F10 are shortcuts to all the views.

12. All Rational SiteCheck views stay synchronized as you move through your Web site.

13. In List View, click on a column heading to sort the items by that column. Click again to reverse the sort order.

14. You can rearrange, add, or delete columns to create a custom report in List View. You can then print or export the List View.

15. Use SiteMonitor to automatically check for defects on your Web site.

16. To check the status of external links at any time, you can right-click on an external link and click Check Link or Recheck Link.

17. When a page uses frames and Rational SiteCheck reports a broken link, be sure to check the NOFRAMES section of the frameset page.

18. When Rational SiteCheck reports a broken link to an image map but it looks correct from your browser, be sure to check both the server-side and client-side image maps.

19. With Rational SiteCheck, you can analyze any site that you can visit with your browser, even sites that are managed by other people.

20. Rational SiteCheck fully supports access to sites through your corporate firewall. To specify your firewall settings, click the Proxy Settings button found on the HTTP Options tab of the Preferences dialog box and the HTTP Options dialog box of the Site Settings wizard.

21. Use the ActiveScan View to follow links from Forms, Java applets, JavaScript, VB scripts and ActiveX controls.

22. Want a quick summary of your Web site statistics? Use the Site Properties View to get an overview of your Web site, including the total number of pages, the total size, and the number of broken links.

23. Want to speed up your load time for large sites? Switch to Site Properties View to increase performance.

24. Do you have a multiserver domain? Rational SiteCheck offers full multiserver support. Click the Servers button in the General dialog box of the Site Settings wizard, and enter the server path. Use wildcard characters (*) to enter a group of related sites.

25. You can save your site at any time. This creates a "site map" that provides a "snapshot" of your site structure at the time of the save. This operation does not save changes or updates to actual Web files.

26. All external links that do not refer to a specific HTML file are displayed in Page View and List View using the "default page name" for the file name. This does not affect any functionality. Actual HTTP requests for this link do not include the default page name.

27. When you move HTML page files, you can choose to leave bookmarks. Bookmarks do not apply to other file types.

28. Rational SiteMonitor is a site-management tool that comes with Rational SiteCheck. With SiteMonitor, you can automatically schedule scans of any site, at any time. You can use SiteMonitor to scan your complete site for defects, check your site to make sure it is reachable, compare two Web sites for differences, or compare your site against a previously saved site map to look for changes.

29. Assertions let you to set your own test conditions. You can check for the presence or absence of display text, HTML tags, links, Java applets, ActiveX controls and other features. With assertions, you can enforce coding standards and verify that corporate standards, like meta tag content, logos and legal notices, are used consistently on your Web site.

30. You can exclude portions of a site from a scan. When opening your site, click the Exclude button on the General dialog box of the Site Settings wizard, and enter the directories you do not want to scan.

31. You can scan to a given number of levels. Simply enter the number of levels in the scan settings when opening your site.

32. You use realms to access password-protected areas of a site and you can enter multiple user names and passwords for each realm.

33. HTML reports let you view summary and detailed data about any site you load. You can generate reports detailing broken links, pages with broken links, failed assertions, slow pages, permanently moved pages, orphan pages, and files with viruses. The reporting utility creates an executive summary of the data as well as a detailed breakdown of all defects. Because the report is loaded directly into your browser, you can move directly to defective files by clicking the link.

34. When saving reports, select a dedicated directory. If you are analyzing a large site, you may end up with a large number of files.

As I wrote in my previous posts, Integration testing is designed to test the structure and the architecture of the software and determine whether all software components interface properly. Integration testing does not verify that the system is functionally correct, only that it performs as designed.

It is the process of identifying errors introduced by combining individual program unit tested modules. Integration Testing should not begin until all units are known to perform according to the unit specifications. It can start with testing several logical units or can incorporate all units in a single integration test.

Below are the four steps of creating integration test cases:

Step 1 - Identify Unit Interfaces: The developer of each program unit identifies and documents the unit’s interfaces for the following unit operations:

- Responding to queries from terminals for information
- Managing transaction data entered for processing
- Obtaining, updating, or creating transactions on computer files
- Passing or receiving information from other logical processing units
- Sending messages to terminals
- Providing the results of processing to some output device or unit

Step 2 - Reconcile Interfaces for Completeness: The information needed for the integration test template is collected for all program units in the software being tested. Whenever one unit interfaces with another, those interfaces are reconciled. For example, if program unit A transmits data to program unit B, program unit B should indicate that it has received that input from program unit A. Interfaces not reconciled are examined before integration tests are executed.

Step 3 - Create Integration Test Conditions: One or more test conditions are prepared for integrating each program unit. After the condition is created, the number of the test condition is documented in the test template.

Step 4 - Evaluate the Completeness of Integration Test Conditions: The following list of questions will help guide evaluation of the completeness of integration test conditions recorded on the integration testing template. This list can also help determine whether test conditions created for the integration process are complete.

Q1. Is an integration test developed for each of the following external inquiries:

- Record test?
- File test?
- Search test?
- Match/merge test?
- Attributes test?
- Stress test?
- Control test?

Q2. Are all interfaces between modules validated so that the output of one is recorded as input to another?

Q3. If file test transactions are developed, do the modules interface with all those indicated files?

Q4. Is the processing of each unit validated before integration testing?

Q5. Do all unit developers agree that integration test conditions are adequate to test each unit’s interfaces?

Q6. Are all software units included in integration testing?

Q7. Are all files used by the software being tested included in integration testing?

Q8. Are all business transactions associated with the software being tested included in integration testing?

Q9. Are all terminal functions incorporated in the software being tested included in integration testing?

In this post, I'm going to describe techniques and strategies for software testing. Techniques cover different ways testing can be accomplished. Testing techniques can be defined in three ways: Preparation, Execution and Approach.

Deciding when software is ready to release is a difficult. You have pressure from all sides to release perfect software, with added features. Below are some common facts:

- The engineers have said that the code was complete months ago, but are still making code changes.

- Sales people promised the software to major accounts months ago and are making commitments for the next release.

- The product manager wants a few more features added and you want to release a zero defect software.

Having no specific release criteria, many organizations wait for the manager to say "Release it", not knowing when or why the decision was made at that time. In other cases, there is a general group consensus to just push the software out the door because the tired and stressed group wants to move out from the seemingly never ending cycles.

You can never take all of the stress out of releasing good software, but by planning ahead and setting up a good defect tracking repository, predetermining acceptable bug counts, properly testing the software and effectively triaging the defects you can always know the current state of the software, but most importantly know when the software is ready to ship.

Defect Tracking Repository:

The most common as well as important tool to determine the state of the software is the defect tracking repository. The repository must be able to provide information required for the triage process. The repository must include the following info:

- The expected results of the testers test
- The steps to recreating the defect
- The version in which the defect was found
- The module in which the defect was found
- The severity of the defect
- A short descriptive name for the defect
- A description of the defect
- The actual results if the testers test
- Resolution notes

The project team should be able to query the database and gather information such as defect counts at various severity levels, and module levels, descriptions of the defects and steps to reproduce them. The repository becomes the archive for the project and it becomes important that correct and complete information be entered in order to use this information for later projects as a planning tool.

Predetermined Acceptable Bug Counts: The goal of releasing software with no defects cannot be achieved given the limited time and resources so, in the preliminary planning of the project exit criteria must be set up. The exit criteria should then be translated into the test plan outline, which should include acceptable bug count levels in order to ship the software.

The exact acceptable bug count level is not some magic number that will insure a successful product, but more a target goal that the group can use to see that they are moving forward toward a common goal. An acceptable bug count statement may look like this:

- Showstoppers: There may not be any
- High: There may not be any
- Medium: There may not be any that have a high probability of appearance to the customer
- Low: There may be a minimal amount in specified core areas and all other areas may have any amount.

In order for the entire group to know the state of the software at all timesit would be preferable to produce a weekly build grading process. The idea is that each week the build would be treated as if it were the software to be shipped and given a grade. The weekly grade keeps the team current on the software state and the team can see the software progressively improve.

This quantitative method takes a lot of the guesswork out of the equation.

Proper Testing: The key to shipping quality software is finding and fixing all defects. The testers responsibility becomes finding the defects and properly reporting them. In order for the testers to find the defects the lead tester must set up in the test plan outline, the specific stages of testing to ensure that the process is organized and covers all aspects of the software. The test plan may contain the following 7 phases:

- Test Case and Test Suite Planning
- Unit Testing
- Regression Testing
- System Testing
- Regression testing
- Performance Testing
- Release Candidate Testing

The goal is to turn up as many defects as early as possible in order to make the fixes easier on the engineers and to provide ample time for regression testing since every time the code is altered there is a greater risk of creating more defects.

As important as finding the defect, the tester must be able to correctly report it in the repository. This becomes extremely important in large projects where the defect counts may rise in the thousands.

Effective Triage:

The Test Lead and Engineer must sit down regularly to evaluate the reported defects and drive the process forward in the most efficient manner for the engineers as well as the testers. Much of the decision making here is based on queries from the defect repository, which shows the importance of the accuracy and completeness of the repository.

The creation of a "Hot List" which is a list of important bugs is a great tool to create. This can be done in an plain Excel sheet, which identifies the most important defects, their module and a brief description. This list is great to use in triage to identify the defect action items for the upcoming week.

Defects that prevent further testing in a certain area must be given precedence and the engineers can assist in the risk analysis of future modules to assist the testers in their test case development. In the determination of what to fix next generally it is advantageous to group and fix defects relating to the same module at the same time even though there may be other important defects in other modules. Grouping of defects assists the engineers finish a module and move on.

Shipping quality software is not an easy task but by being organized from the start of the project the ship date and defect counts don't have to be a "gut feeling". The project must have a Defect Tracking Repository that must be maintained and updated continually with correct and complete information. The Repository is used as the main tool for an effective triage process and in conjunction with the Test Plan Outline that must be createdat the start of the project describing in detail the exit criteria to ship the software.

Please note the entire process rests on proper testing and the use of proper test planning which is what uncovers the defects. If you do not uncover the defects the users of the software will.

Thus, by following the above described process it is possible to know the state of the software at any time so that the entire team knows the goal, sees the progress and knows when the software is ready to release.

Integration Testing is a four step procedure. Below are the steps for creating integration test cases:

1. Identify Unit Interfaces: The developer of each program unit identifies and documents the unit’s interfaces for the following unit operations:

- External inquiry (responding to queries from terminals for information)
- External input (managing transaction data entered for processing)
- External filing (obtaining, updating, or creating transactions on computer files)
- Internal filing (passing or receiving information from other logical processing units)
- External display (sending messages to terminals)
- External output (providing the results of processing to some output device or unit)

2. Reconcile Interfaces for Completeness: The information needed for the integration test template is collected for all program units in the software being tested. Whenever one unit interfaces with another, those interfaces are reconciled. For example, if program unit A transmits data to program unit B, program unit B should indicate that it has received that input from program unit A. Interfaces not reconciled are examined before integration tests are executed.

3. Create Integration Test Conditions: One or more test conditions are prepared for integrating each program unit. After the condition is created, the number of the test condition is documented in the test template.

4. Evaluate the Completeness of Integration Test Conditions: The following list of questions will help guide evaluation of the completeness of integration test conditions recorded on the integration testing template. This list can also help determine whether test conditions created for the integration process are complete.

1. Is an integration test developed for each of the following external inquiries:

- Record test?
- File test?
- Search test?
- Match/merge test?
- Attributes test?
- Stress test?
- Control test?

2. Are all interfaces between modules validated so that the output of one is recorded as input to another?

3. If file test transactions are developed, do the modules interface with all those indicated files?

4. Is the processing of each unit validated before integration testing?

5. Do all unit developers agree that integration test conditions are adequate to test each unit’s interfaces?

6. Are all software units included in integration testing?

7. Are all files used by the software being tested included in integration testing?

8. Are all business transactions associated with the software being tested included in integration testing?

9. Are all terminal functions incorporated in the software being tested included in integration testing?

Many applications include ActiveX controls developed with third-party vendors. You can use the QuickTest Professional ActiveX Add-in to test ActiveX controls. You can create and run software tests and components on these controls, as well as check their properties. QuickTest Professional supports Software Testing on ActiveX controls in any application.

• In QuickTest Professional ActiveX Add-in is considered a Windows-Based add-in.



• You can check the properties of an ActiveX control as you check the properties of any other Windows object. You can also use output value steps to output property or text values from the objects in your ActiveX application.



• When you create a checkpoint on an ActiveX control, QuickTest Professional captures all the properties for an ActiveX control, but it does not select any properties to check.
• You use the Windows Applications tab in the Options dialog box to set global preferences for testing ActiveX applications.
• You use the Windows Applications tab of the Record and Run Settings dialog box or the Application Area Settings dialog box to set preferences for testing ActiveX applications.



• The ActiveX Add-in provides custom test objects, methods, and properties that can be used when testing objects (controls) in ActiveX applications.
• The application containing the ActiveX controls on which you want to record must be opened after setting the Record and Run options.



• In QuickTest Professional It is recommended that you begin your recording session before opening the application containing the ActiveX controls on which you want to record.
• When testing ActiveX objects in a browser, the top-level ActiveX object is inserted within the standard Web object hierarchy, for example, Browser > Page > ActiveX.
• QuickTest Professional can record on standard controls within an ActiveX control and if an ActiveX control contains another ActiveX control, then QuickTest Professional can record and run on this internal control as well. For example, suppose your ActiveX control is a calendar that contains a drop-down list from which you can choose the month. If you record a click in the list to select the month of May, QuickTest Professional records this step in the Expert View as:

Dialog("ActiveX Calendars").ActiveX("SMonth Control").WinComboBox("ComboBox").Select "May"

• When creating a programmatic description for an ActiveX test object and the relevant run-time object is windowless (has no window handle associated with it), you must add the windowless property to the description and set its value to True. For Example:

Set ButDesc = Description.Create
ButDesc("ProgId").Value = "Forms.CommandButton.1"
ButDesc("Caption").Value = "OK"
ButDesc("Windowless").Value = True
Window("Form1").AcxButton(ButDesc).Click

In this post, I'm going to describes the elements and attributes available for creating test object configuration XML content to be used with your QuickTest extensibility project.

In a test object configuration XML, you define the test object classes (for example, their identification properties, the test object methods they support, and so on). To do this, you define a ClassInfo element for each test object class. In addition, you define the name of the environment for which the test object classes are intended, and the QuickTest add-in which they extend. If the relevant add-in is not loaded when QuickTest opens, QuickTest does not load the information in this XML. Similarly, if the environment name is displayed in the Add-in Manager dialog box and the check box for this environment is not selected, the information in this XML is not loaded.

A test object class definition can include the following:

- The name of the new test object class and its attributes, including the base class—the test object class that the new test object class extends.

- The test object class name must be unique among all of the environments whose support a QuickTest user might load simultaneously. For example, do not use names of test object classes from existing QuickTest add-ins, such as WebButton, WebEdit, Page, etc.

- The path of the icon file to use for this test object class (Optional. If not defined, a default icon is used.) The icon file must be in an uncompressed .ico format.

- A context-sensitive Help topic to open when F1 is pressed for the test object in the Keyword View or Expert View. The definition includes the Help file path and the relevant Help ID within the file.

- The methods of the new test object, including the following information for each method:

1. The arguments, including the argument type (String or Variant) and direction (In or Out)
2. Whether the argument is mandatory, and, if not, its default value
3. Whether a dynamic list of possible values for this argument can be retrieved from the supported control and displayed in the Keyword View, Expert View, and Step Generator
4. The method description (shown as a tooltip in the Keyword View, Expert View, and Step Generator)
5. The Documentation string (shown in the Documentation column of the Keyword View and in the Step Generator)
6. The return value type
7. A context-sensitive Help topic to open when F1 is pressed for the test object method in the Keyword View or Expert View, or when the Operation Help button is clicked for the method in the Step Generator. The definition includes the Help file path and the relevant Help ID within the file.

- The test object method that is selected by default in the Keyword View and Step Generator when a step is generated for an object of this class

- The identification properties of the new test object

1. The identification properties that are used for the object description
2. The identification properties that are used for Smart Identification (Smart Identification needs to be enabled for these definitions to take effect)
3. The identification properties that are available for use in checkpoints
4. The identification properties that are selected by default for checkpoints (in the QuickTest Checkpoint Properties dialog box)

Each time you run QuickTest, it reads all of the test object configuration XMLs and merges the information for each test object class from the different XMLs into one test object definition.

Each time you open QuickTest, it reads all of the test object configuration files located in the \dat\Extensibility\ folders. QuickTest then merges the information for each test object class from the different files into a single test object class definition, according to the priority of each test object configuration file.

You define the priority of each test object configuration file using the Priority attribute of the TypeInformation element.

Please Note:

- If the priority of a test object configuration file is higher than the existing class definitions, it overrides any existing test object class definitions, including built-in QuickTest information. For this reason, be aware of any built-in functionality that will be overridden before you change the priority of a test object configuration file.

- QuickTest ignores the definitions in a test object configuration files in the following situations:

a. The Load attribute of the TypeInformation element is set to false.
b. The environment relevant to the test object configuration file is displayed in the Add-in Manager dialog box, and the QuickTest user selects not to load the environment.

When multiple test object class definitions exist, QuickTest must handle any conflicts that arise. The following sections describe the process QuickTest follows when ClassInfo, ListOfValues, and Operation elements are defined in multiple test object configuration files. All of the IdentificationProperty elements for a specific test object class must be defined in only one test object configuration file.

ClassInfo Elements:

If a ClassInfo element is defined in a test object configuration file with a priority higher than the existing definition, the information is appended to any existing definition. If a conflict arises between ClassInfo definitions in different files, the definition in the file with the higher priority overrides (replaces) the information in the file with the lower priority.

If a ClassInfo element is defined in a test object configuration file with a priority that is equal to or lower than the existing definition, the differing information is appended to the existing definition. If a conflict arises between ClassInfo definitions in different files, the definition in the file with the lower priority is ignored.

ListOfValues Elements:

- If a conflict arises between ListOfValues definitions in different files, the definition in the file with the higher priority overrides (replaces) the information in the file with the lower priority (the definitions are not merged).

- If a ListOfValues definition overrides an existing list, the new list is updated for all arguments of type Enumeration that are defined for operations of classes in the same test object configuration file.

- If a ListOfValues is defined in a configuration file with a lower priority than the existing definition, the lower priority definition is ignored.

Operation Elements:

- Operation element definitions are either added, ignored, or overridden, depending on the priority of the test object configuration file.

- If an Operation element is defined in a test object configuration file with a priority higher than the existing definition, the operation is added to the existing definition for the class. If a conflict arises between Operation definitions in different files, the definition in the file with the higher priority overrides (replaces) the definition with the lower priority (the definitions are not merged).

Using Web Add-in Extensibility, you can implement full support for all QuickTest features for your controls. You can implement Web Add-in Extensibility support for a set of controls (also referred to as a toolkit or custom toolkit) by developing a toolkit support set.

Implementing Web Add-in Extensibility consists of the following stages:

1. Planning the Toolkit Support Set

- Determine the set of Web controls that comprise your custom toolkit.

- Define the test object model by determining which test objects and operations you want to support based on the controls and business processes supported by your toolkit.

2. Developing the Toolkit Support Set: A Web Add-in Extensibility toolkit support set is comprised of the following files:

- One test object configuration file, which describes the test object model for your toolkit to QuickTest.

- One toolkit configuration file, which describes which test object class represents each control in the toolkit and how QuickTest interacts with each control.

- One or more files containing JavaScripts that QuickTest can call to perform operations on the custom controls.

3. Deploying the Toolkit Support Set: To deploy your toolkit support set and enable QuickTest to support your controls, you need to copy the files you created to specific locations within the QuickTest installation folder.

After you deploy the toolkit support set, when QuickTest opens, it displays your toolkit name as a child node under the Web Add-in node in the Add-in Manager. If you select the check box for your toolkit, QuickTest supports the controls in this toolkit using the toolkit support set that you developed.

4. Enhancing the Toolkit Support Set: After you have created and tested basic Web Add-in Extensibility support for your controls you can enhance your toolkit support set by using some of the more complex options to fine-tune your support.

When you develop a Web Add-in Extensibility toolkit support set, you can start by creating a simple and basic support set and deploying it to QuickTest. This enables QuickTest to recognize your controls correctly and enables QuickTest user to create and run tests on the controls. You can then enhance your support to enable more complex capabilities, such as filtering the child objects learned with a control and more advanced handling of events when recording a test.

`
Here are some of the sample question papers of QTP HP-M016, CSTE, ISEB, ISTQB and CSQA: