Share this page

# Create test sets

This task describes how to create and define test sets in the Test Lab module.

In this topic:

## Test sets overview

After you design tests in the Test Plan module, you organize test execution by creating test sets in the Test Lab module. A test sets tree enables you to organize your application management process by grouping test sets in folders and organizing them in different hierarchical levels.

Test sets, tests, and test instances

A test set contains a subset of the tests in your project designed to achieve specific test goals.

A test instance is an occurrence of a test in a test set. When you add tests to a test set, instances of your selected tests are added to the test set. Each test instance contains a defined test configuration. A test configuration enables you to run the same test under different scenarios. For more details on test configurations, see Test configurations.

Supported test set types

The following table describes the supported test set types.

Test Set Type | Description
--- | ---
Performance | For running unattended remote performance tests. You can add only performance tests to this test set. You arrange for a performance test to be executed from the server by scheduling a timeslot. A timeslot contains a test set, the details of the remote hosts on which the test set runs, and a time and duration for running the test set. For more details about how to run a Performance test, see Test Lab. For more details on timeslots, see Timeslot reservations. Editions: Performance test execution is available only for the ALM edition and QC Enterprise edition. For information about editions and their functionality, see Editions and lifecycle. To find out which edition you are using, ask your site administrator.
Default | For running client-side, locally controlled and launched functional tests. You can add both manual and automated functional tests to this test set. You can arrange for default tests to be run in an ad hoc manner. For more details on how to run default test sets, see Test Lab.
Functional | For running server-side, unattended functional tests. You arrange for a functional test set to be executed from the server by scheduling a timeslot. A timeslot contains a test set, the details of the testing hosts on which the test set runs, and a time and duration for running the test set. For more details about how to run a Functional test set, see Test Lab Build verification suites are a key component in the Continuous Delivery solution. They facilitate an automated, end-to-end deployment and testing framework that makes application development more efficient, reliable, and quick. For details about how build verification suites can be used as part of this process, see Deploy and test your application. For more details on timeslots, see Timeslot reservations. Editions: Functional test sets are available only for the ALM edition. For information about editions and their functionality, see Editions and lifecycle. To find out which edition you are using, ask your site administrator.
External | Contains external type tests (EXTERNAL-TEST ). External type test sets are read-only. You cannot create, modify, or run external test sets directly from OpenText Application Quality Management. For details about external testing, see Integrate with external tests.

Test set example

To decide which test sets to create, consider the goals you defined at the beginning of the application management process. Consider issues such as the current state of the application, and the addition or modification of new features.

Here are examples of general categories of test sets you can create.

Test Set | Description
--- | ---
Sanity | Checks the entire application at a basic level—focusing on breadth, rather than depth—to verify that the application is functional and stable. This set includes fundamental tests that contain positive checks, validating that the application is functioning properly. For example, in the Mercury Tours application, you could test whether the application opens, and enables you to log in.
Regression | Tests the system in a more in-depth manner than a sanity set. This set can include both positive and negative checks. Negative tests attempt to fail an application to demonstrate that the application is not functioning properly.
Advanced | Tests both breadth and depth. This set covers the entire application, and also tests the application's advanced options. You can run this set when there is ample time for testing.
Function | Tests a subsystem of an application. This can be a single feature or a group of features. For example, in the Mercury Tours application, a function set could test all activities related to booking a flight.

Back to top

## Define test sets

Define a hierarchical framework for your test sets by creating a test sets tree that contains folders and subfolders.

To create a test set:

1. On the sidebar, under Testing, select Test Lab.

2. Right-click the Root folder and select New Folder. To create a sub-folder, right-click a folder and select New Folder.

3. Right-click the test set folder and select Assign to Cycle. Select a cycle from the releases tree.

4. Right-click a folder and select New Test Set.

   UI Element | Description
   --- | ---
   Name | Give the test set a unique name. Syntax exceptions: A test set name cannot include the following characters: \ ^ , " *
   Type | Select the test set type that corresponds to the types of tests you are grouping together. For details, see Supported test set types.
   Details | Lists test set fields.
   Attachments | Enables you to add attachments that provide additional information about the test set. For details, see Work with attachments.
   Test Set Folder | Displays the preselected folder name.

Example:

Suppose you want to test new features added to Release 10.5 of the Mercury Tours application. Release 10.5 consists of four cycles, and you want to test the new features for the release in Cycle 1, Cycle 2, and Cycle 4. Because the tests you need to run to test the new features are the same for each of these cycles, you want to use the same test set as a basis for testing new features in each of the cycles.

In the test sets tree, you can create the folder, Release 10.5, for the release. Under this folder, you create the folder, Cycle 1, for the first cycle of the release. In the Cycle 1 folder, you create a test set, New Features, containing the tests necessary to test new features for the release. After you create this test set and add its tests, you can copy and paste the Cycle 1 folder and use it as a basis for the other cycles that test new features.

5. To copy test sets from another project:

   Note:

   - Test run information is not copied.

   - The source and target projects must use the same version and patch level.

   1. In the source project, right-click a test set or a test set folder and select Copy.

   2. Open the target project in a separate browser window.

   3. In the target project, right-click a test set folder below which you want to insert the copied test set or test set folder, and select Paste.

      UI Element | Description
      --- | ---
      Copy Test Set Folders and link to existing related entities | Copies the test sets or test set folders and pastes them into the target project. The copied test sets or test set folders are linked to existing test resources and called tests with the same name and path. If a related test resource or a test does not exist in the target project, it is copied to the target project.
      Copy Test Set Folders and related entities | Copies the test sets or test set folders along with the related test resources and called tests, and pastes them into the target project. If a related test resource or a called test already exists in the target project, the copied related test resource or called test is renamed to resolve the duplicate name.
      Copy Test Set Folders without copying related entities | Copies the test sets or test set folders without copying the related test resources or called tests, and pastes them into the target project. The copied items are not linked to any related entities.

Back to top

## Add tests to test sets

A test added to a test set is a test instance. You can add tests to a test set from the test plan tree or copy test instances from other test sets.

- Add tests from the test plan tree

- Copy test instances from other test sets

Add tests from the test plan tree

1. Click the Execution Grid tab or the Execution Flow tab and then click Select Tests.

2. To add tests from the following tabs in the test selection pane:

   - Test Plan Tree. Add tests or test configurations from the test plan tree to the test set.

   - Requirements Tree. Add tests covering requirements from the requirements tree to the test set.

   The following tests can be added to a test set:

   Test Set Type | Tests to Include
   --- | ---
   Functional test set | You can add tests of the following test types to a Functional test set: BUSINESS-PROCESS SERVICE-TEST QUICKTEST-TEST SYSTEM-TEST VAPI-XP-TEST
   Default test set | You can add manual and automated functional tests to a Default test set.
   Performance test set | You can only add tests of the PERFORMANCE-TEST type to a Performance test set.

   For details about test types, see Test types.

Copy test instances from other test sets

You can add test instances by copying existing test instances from other test sets within the same project.

Consider the following when you copy and cut test instances:

- You can copy test instances across test sets within the same project. You cannot copy test instances across projects.

- If a test set is pinned to a baseline, you cannot copy its test instances or paste test instances into the test set.

- You cannot copy test instances to an external type test set.

To copy test instances from other test sets:

1. Open the source test set, select the target test instances, right-click any of them, select Copy.

   To copy test instances from multiple test sets under the same test set folder, you can open the test set folder. In the Test Board tab, select the test instances you want to copy. For details about Test Board, see Test Board.

   Note: You can select up to 500 test instances to copy at a time.

2. Open the target test set. In the Execution Grid tab, right-click in the grid and select Paste.

   Only the test instances whose types are compatible with the type of the target test set are copied. For details about the compatibility, see Tests that can be added to a test set.

   Note the following for the copied test instances:

   - The test instances are copied with the No Run status.

   - The run history of the source test instances are not copied.

   - The Target Cycle of the copied test instances is set to the cycle of the target test set.

Back to top

## Move test instances across test sets

Available from: 25.1 P1

You can move manual test instances across test sets within the same project by cut and paste.

Consider the following when you move test instances:

- You can move test instances across test sets within the same project. You cannot move test instances across projects.

- If a test set is pinned to a baseline, you cannot move test instances from or into the test set.

- You cannot move test instances to an external type test set.

To move test instances from other test sets:

1. Open the source test set, select the target test instances, right-click any of them, and select Cut.

   To move test instances from multiple test sets under the same test set folder, you can open the test set folder. In the Test Board tab, select the test instances you want to move. For details about Test Board, see Test Board.

   Note: You can select up to 500 test instances to move at a time.

2. Open the target test set. In the Execution Grid tab, right-click the grid and select Paste.

   Only the test instances whose types are compatible with the type of the target test set are copied. For details about the compatibility, see Tests that can be added to a test set.

   Note the following for the moved test instances:

   - The statuses and run history of the test instances are kept.

   - The Target Cycle of the moved test instances is set to the cycle of the target test set.

Back to top

## Manage host requests for Functional test sets

You can manage which hosts are requested for a Functional test set execution.

Host requests management modes

Testing host requests are managed in two different modes.

Mode | Description
--- | ---
Auto mode | In the default auto mode, each time you add a test instance to a test set, the system checks if the host requested by this new test instance (whether it is a specific host or an automatch host) was already requested for the selected test set. If the new test instance contains a host request which does not already exist in the Requested Hosts grid, a new testing host is automatically added to the test set. If the grid already contains the host being requested for the new test instance, no new hosts are added. Example: The test set already contains a host request for a host in London with a VAPI-XP purpose, and you add a new test instance which requires an automatch host with a VAPI-XP purpose. A new host request is added to the grid for the automatch host. Even though the London host request technically covers the new automatch host, they are not the same, so a new automatch host request is added to the grid.
Manual mode | You may decide to manually edit the hosts being requested for a selected test set. For example, you may have only one testing host available in your pool and it can cover a few different test instances. In that case, you modify the hosts in the Requested Hosts tab and arrange for only a single host. Once you make a change in the grid, the test set is put into manual mode. In manual mode, new host requests for additional test instances are automatically added only when it is necessary to maintain the validity of the test set. This is the case when the added test instance cannot possibly be satisfied by the already existing host requests for that test set. Example: The test set already contains a host request for an automatch host with a VAPI-XP purpose, and you add a new test instance which requires a host in London with a VAPI-XP purpose. A host request is added for the new test instance because the first automatch host request does not necessarily cover the London host request. If your test set already contains a host request for a host in London with a VAPI-XP purpose, and you add a new test instance which requires an automatch host with a VAPI-XP purpose, a new host request is not added to the grid. The London host request suffices for the new test instance, therefore, a new host request is not added.

To manage hosts requests for a Functional test set:

1. From the test set tree, select the target Functional test set, and click the Requested Hosts tab.

2. Add or edit host requests.

   UI Element | Description
   --- | ---
   Add Automatch Host | Opens the Select Automatch Host dialog box, enabling you to add a new host request based on criteria you specify. A testing host that fits the criteria is automatically allocated and reserved. You can block hosts from being included in the automatch selection. For details, see Exclude From Automatch.
   Add Specific Host | Opens the Select Specific Testing Host dialog box, enabling you to request a specific testing host. You can select from the remaining available hosts in the host pool of the project. You can make specific hosts available only to specific users. For details, see Reserved for User. Use case If you want to reserve a specific testing host for a test set,: Add the testing host as the requested host. Exclude the host from automatch by setting Exclude from Automatch to Y. For details, see Exclude From Automatch. The specific host is selected as Testing Host in each test instance of the test set.
   Edit Host Request | Enables you to edit the selected host request.
   Remove | Removes the selected host request. If you remove a host request that is required for a specific test instance, the test cannot run.
   Restore Default | Resets the host requests to their default state. All current host requests are removed and a default set of requests is created. One host request will be created for each type of test in the test set. Restores the selected test set to auto mode.
   Resolve Missing Hosts | Enables you to automatically generate the remaining host requests if the current host requests are insufficient for executing the selected test set. The requested hosts will be determined based on the test instances in the Execution Grid.
   Testing Host | Displays the name of the host specified in the host request. If the value Automatch is displayed in this field, it indicates that no particular host was specified. A host is automatically allocated and reserved based on the criteria in the Purposes, Location, Amount, and Attributes fields. For details about how testing hosts are allocated and reserved, see Host Allocation.
   Amount | Displays the number of hosts specified in the host request.
   Purposes | Lists the purposes specified in the host request.
   Location | Displays the host location specified in the host request.
   Attributes | Lists the host attributes specified in the host request.
   Messages | Displays all messages related to host request validation. Example: If a test set cannot run because the requested hosts have not been reserved, you are informed that the tests cannot be run and the reason is provided.

Back to top

## Pin a test set to a baseline

When you pin a test set to a baseline, you associate the tests in the test set with the versions of the tests stored in a baseline you select. When you run a test set that has been pinned to a baseline, the versions of the tests that are stored in the specified baseline are run.

Before you pin a test set to a baseline

Consider the following before you pin a test set to a baseline:

- A pinned test set can include only tests that are included in the baseline. When you pin a test set, the tests that are not included in the baseline are removed from the test set.

- A pinned test set is displayed with the pinned test set icon in the test set tree.

- When you pin a test set, all test runs are deleted from the test set.

To pin a test set to a baseline:

1. From the test set tree, right-click the target test set, and select Pin to Baseline.

2. From the libraries tree, select the target baseline.

To clear a pinned baseline:

From the test set tree, right-click the target test set, and select Clear Pinned Baseline.

When you clear a pinned test set:

- The tests in the test set are then associated with the latest version of the tests in the Test Plan module.
- All test runs in that test set are deleted

For concept details on pinned test sets, see Overview.

Back to top

## Link defects to test sets

You can view, add, and remove defect links for test sets.

To add linked defects:

1. From the test set tree, select the target test set, and go to the Linked Defects tab.

2. To add and link to a new defect, click Add and Link Defect. Provide the defect details.

3. To link to an existing defect, click Link Existing Defect and select one of the following options:

   - By ID. Enter the defect ID.

   - Select. Select the defect to link.

Note:

- Defects linked to a test instance are indirectly linked to the test set.

- You can remove direct defect links only.

Back to top

https://admhelp.microfocus.com Application Quality Management 8942
Tips to improve your search results... OpenText™ Application Quality Management Help Center OpenText™ Application Quality Management Help Center OpenText™ Application Quality Management Help 26.1 All View Local Help Center View Online Help Center Version: