Although you can execute test scripts alone inside the eCATT development environment, this is normally only done during test development or troubleshooting. Test scripts can, and often do, contain default test data. However, a complete test case is represented by a test configuration, and it is test configurations that can be executed from the Test Workbench.
The graphic below shows the main components of a test configuration. As with other eCATT objects, the test configuration has mandatory attributes (title, package, person responsible, and application component) as well as attributes containing administrative information. At the core of the test configuration is the test script. Each test configuration references exactly one test script and the default variant is defined by the import parameters of the test script.
It is usual to reference a system data container and one or more test data containers, but these are optional. You can create variants manually or by referencing data in the test data containers. In many cases, referencing test data containers provides the advantage of reusability. The graphic below shows how the various eCATT objects work together.
The test script defines the actions to be executed. The system data container provides the system mapping that determines the systems affected by the commands. The system data container of the test configuration overrides all other system data containers.
The test script defines the importing parameters that make up the variants. The test data containers provide the bulk of the test data. The names of parameters defined in the test data containers do not need to be the same as those in the test configuration, although it can be convenient to arrange it so. There is considerable flexibility in building up variants. In one variant, you can link to fields in several different test data containers, manually enter values in other fields, and leave yet other fields empty to be filled with the default values.