Testcases can be arranged in a hierarchical structure. The root of the structure is the TestSuite. All Testcases must exist within a TestSuite, so the most basic structure is a TestSuite containing a list of Testcases. However, it is possible to create TestGroups, which in turn contain a number of other TestGroups and Testcases. This flexible structure allows the tests within a particular TestSuite to be arranged in a logical manner, and for execution of a particular subset of the tests based on their position in the hierarchy.

A new TestSuite may be created using the Create TestSuite menu option. The application will create an empty TestSuite with a default name and location. The location of a TestSuite will be used to store all data files associated with the TestSuite, and the TestGroups and Testcases contained within the TestSuite. It is not possible to partition these files across multiple locations, although different TestSuites may be stored in different locations.

TestSuites may be removed from the workspace either by a) deleting, or b) unloading. If the TestSuite is deleted, then all data files associated with the TestSuite will be deleted from disk and will not be recoverable. If the TestSuite is unloaded, this will just remove it from the current workspace, but it may later be loaded back into the same, or another workspace.

The application also provides a full cut, copy, and paste facility for Testcases, TestGroups, and TestSuites. These operations will recursively copy all the properties, procedures, input data, and benchmark data. The pop-up menu on the test hierarchy view provides each of these operations. Note that the copy and paste operations must copy the input and benchmark files on disk, so these may take some time if the disk files are large.

The application will not allow pasting of a test object into itself, or into a child of itself. The menu options will be greyed-out if the paste is invalid.

There is also a drag-and-drop facility for moving Testcases and TestGroups around the hierarchies. This is performed with the traditional drag-and-drop mouse operations.

Property and Input File Sharing
There are several reasons why it may be desirable to organise related Testcases into TestGroups. The first is that a TestGroup is a unit of execution, so a new Run can be created from a single TestGroup. The second reason is that properties and input data, can be assigned to the TestGroup. These values are propogated to each Testcase that is contained within the TestGroup.

For example, suppose there are a number of Testcases that use the RunExecutable execution procedure. This procedure requires a property called ExeName to be set to the name of the executable to be run. If each Testcase is running the same executable, then the ExeName property may be set once on the TestGroup, rather than setting it against each Testcase. Doing this will help the maintainability of the Testcases, because when the value changes it will only require changing in one place.

If there are several levels of TestGroup nesting, each property value will be propogated down the hierarchy to the Testcases. If the same property is set at several levels of the hierarchy, the value set at the lowest-level will override the higher-level value. In other words, the value closest to the Testcase will always take precedence.

As with properties, it is also possible to set input data at the TestGroup level. This data is copied into the staging area of each Testcase, before the execution takes place. Again this can be used to set input data that is common to several Testcases, in one place only, in order to help the maintainability of the test data.

Input data from Testcases will overwrite the input data from the TestGroups, if the data has the same name. This allows the common data to be assigned to the TestGroup, and specific data to be assigned to the Testcase.

Version 1.1 TestSuite Conversion
Version 2.0 of Test Manager uses a different filestructure for TestSuite and Run data, than versions 1.1 and 1.0. If a workspace containing older TestSuites and Runs is opened with Test Manager version 2.0, those TestSuites and Runs will not be opened. For Runs, the only option is to use version 1.1 to view the data. However, there is a conversion procedure for Test Suites.

First, the "Load TestSuite" menu option should be selected, and the old TestSuite should be loaded. The application will display a dialog indicating that this is an old TestSuite, and asking whether or not it should be converted to the new format. Selecting "Yes" will cause the conversion to take place, and the newly converted TestSuite to be loaded into the workspace.

The converted TestSuite will be located in the same directory as the old TestSuite. For this reason, it is important that the TestSuite files are not read-only or the operation will fail. The old TestSuite structure will be renamed with a .old extension to the original name.