Jon Maidstone

PM Group -
Design Tools

eCATT: Test Configurations and

Test Data Containers
A worked example

09. July 2003

eCATT: Test Configurations and Test Data Containers

Contents

1 Introduction .................................................................................................................... 3

2 How Does Data Get Into a Script? ................................................................................ 3

3 Introducing our Example............................................................................................... 4

3.1 Test Configuration...................................................................................................................................... 5

3.2 Test Data Containers.................................................................................................................................. 6

3.3 Assigning Data From Test Data Containers to a Configuration ............................................................ 7

3.3.1 The Variant Wizard .................................................................................................................................. 7

3.4 Executing the Configuration ..................................................................................................................... 9

4 Conclusion ................................................................................................................... 10

C:\Jon\eCATT\Documents\TDC_Example_Paper.doc Page 2
eCATT: Test Configurations and Test Data Containers

1 Introduction
One of the main features of eCATT (and CATT before it) is the relative ease with which you can compile
complex data-driven tests, running a test script several times with different sets of data. There are essentially
two reasons why you might want to do this:
To test borderline values: When you test how a transaction behaves, you will typically have
some control data. Normally, you will always have one set of data that will always cause the
application to run successfully, and you may well have a second set of data that should always
cause the application to fail. In between these black and white values, you have a large gray
area, where you want to try out various different sets of data to see whether they are valid or fail your
script.
To set up data for subsequent tests: When you test an SAP System, it is very likely that you will
have to set up certain data before many of your actual test cases can be performed. For example, if
you are implementing Warehouse Management and want to test material movements, you need a
warehouse with goods in it that you can move. This means setting up the warehouse and the
required material masters, then posting some inbound goods to stock the warehouse. Now you can
actually test the material movement!
In CATT, you could store test data alongside the test procedure that is, within the same object. Although
this had the advantage that you could execute the procedure quickly and easily, it did mean that the data
that you had was not reusable with other scripts.
In the design for eCATT, this was changed. Test data is now not stored in the eCATT test script, but in
separate objects called test data containers. The fact that the data is now separate makes it easier to reuse,
since data from a single container can be assigned to any number of eCATT scripts. Furthermore, scripts
can draw on data from more than one test data container. This allows you to store logically-grouped data in
separate test data containers and merge it with other data into a single test case in the form of a test
configuration.
In this article, I want to show you the relationships between test scripts, test data containers, and test
configurations and, using a worked example, show you how to plan a strategy for managing test data.

2 How Does Data Get Into a Script?

Each test script may have importing and exporting parameters. Importing parameters are the values that are
passed to the script by its caller when it is called. Exporting parameters are the values that a script returns to
its caller when it has finished.
A script may be called in one of two ways either from another script, using the REF command or from a test
configuration. In the former case, the script will have a command interface that can be supplied with values in
the same way that you might parameterize a TCD or a SAPGUI command. When the script is called directly
from a test configuration, the importing parameters of the test script are exposed in the test configuration for
you to assign one or more sets of values, known as variants (see figure 1).
Within the script, you may assign a default value to each parameter. While this is fine for testing the script
while you are developing it, it is thoroughly unsuitable for a live test run for the following reasons:
You can only assign one value at a time to each parameter in this way
Each time you wanted to change the parameter, you would have to modify the script
Consequently, eCATT uses test configurations as a vehicle for passing data to a test script. Once you have
assigned a script to a configuration, you can use the Variants section of the test configuration editor to
maintain sets of data with which the script will be executed. The script is executed once for each set of data
or variant that you enter. You can either enter variants manually, or use data from a test data container to
populate them.

C:\Jon\eCATT\Documents\TDC_Example_Paper.doc Page 3
eCATT: Test Configurations and Test Data Containers

eCATT Script eCATT Script

Importing params. Importing params.

REF (X, X_1).

Command
Interface
Exporting params. Exporting params.

n eCATT Script Log

Test Configuration
repetitions
Importing params. Importing
Parameters
Variant 1
Variant 2 Commands
Variant 3
Variant n
Exporting params. Exporting

Fig. 1: Passing parameters to a script in a REF command (top) or from a test configuration (bottom)

3 Introducing our Example

I want to use an example to illustrate how we can build a test configuration. The example is based on a
transaction, which I recorded in a test script using the TCD command.
The transaction is based on the flight data model used in ABAP training, and can be used to add a new flight
to the booking system.
It has two screens:

Fig. 2: First screen of demonstration transaction

C:\Jon\eCATT\Documents\TDC_Example_Paper.doc Page 4
eCATT: Test Configurations and Test Data Containers

Fig 3. Second screen of demonstration transaction

The transaction requires you to supply certain information. In my test script, I parameterized the fields of the
transaction so that each field is filled from an importing parameter of the script. The table below shows the
field names on the left, and the parameter names on the right:
Airline I_AIRLINE
Flight Number I_FLIGHT_NUMBER
Date I_DATE
Airfare I_PRICE
Local Currency I_CURR
Plane Type I_PLANE_TYPE
Max Capacity Econ I_CAP_ECON
Max Capacity Business I_CAP_BUS
Max Capacity First I_CAP_FIRST

3.1 Test Configuration

In order to create an executable test case in which we can pass several sets of values to the transaction, we
need to create a test configuration, to which we assign the test script. Once we have done that, the test
configuration has the following set of parameters that needs to be filled:

Fig 4: Parameters of a test configuration

As you can see, the parameters correspond to those of the script (see table above). You will also notice that
there is already a variant in place the default variant. This consists of whatever default values have been

C:\Jon\eCATT\Documents\TDC_Example_Paper.doc Page 5
eCATT: Test Configurations and Test Data Containers

maintained for the various importing parameters of the script. Later you will see how to control whether this
variant is actually executed or not.
So we can now start to assign the data with which we want to execute the test case. For example, a set of
variants might look like this:
NAME I_AIRLINE I_FLIGHT I_DATE I_PRICE I_CURR I_PLANE_TYPE I_CAP_E I_CAP_B I_CAP_F

1 LH 400 31.08.2002 500 EUR A340 200 20 0

2 LH 400 01.09.2002 500 EUR 747-400 250 50 15
3 LH 400 02.09.2002 650 EUR 747-400 250 50 15
4 LH 400 03.09.2002 495 EUR 747-400 250 50 15
5 QF 005 01.10.2002 1000 AUD 747-400 250 50 15
6 QF 005 02.10.2002 1050 AUD 747-400 250 50 15

There are two comments that we can make about this table already, the most striking of which is the
redundancy of so much of the data the combination LH 400 appears four times, QF 005 twice, and the
plane type 747-400 (along with the capacity of the aircraft) five times. The second thing that may have
occurred to you is the way in which much of the data falls into two distinct groups the airline code and flight
number on the one hand, and the aircraft type and its capacity in each of the three classes on the other.

3.2 Test Data Containers

A more efficient way of managing this data would surely be to maintain the flight number or aircraft type data
separately and link it into the relevant fields of the test configuration. Furthermore, it would be best if the data
could be stored separately from any particular test configuration to allow it to be reused by other
configurations and scripts that require the same data.
We would then have something like this, where the various combinations are maintained in the separate
object on the left a test data container - and are linked by reference into the corresponding fields of the test
configuration:

I_AIRLINE I_FLIGHT I_AIRLINE I_FLIGHT. . .

AA 0017 LH 0400
LH 0400
LH 0400

QF 0005 LH 0400
QF 0005
UA 0945
QF 0005

Test Data Container Test Configuration

Fig 5: Using test data containers to reduce redundancy

A test data container has a set of parameters in this case I_AIRLINE and I_FLIGHT, and a set of
variants the data that is managed in the container. Test data containers are not release-specific. However,
each variant has a description, in which you can state in which cases that particular data can be used.

C:\Jon\eCATT\Documents\TDC_Example_Paper.doc Page 6
eCATT: Test Configurations and Test Data Containers

The parameters of a test data container work in a similar fashion to the parameters of a script. Each must
have at least a name and a type.
Assuming, therefore, that we have created two test data containers for our scenario one containing the
airline and flight number, the other containing the aircraft type and the numbers of seats in first, business,
and economy class, we now need a way of using those data in our test configuration.

3.3 Assigning Data From Test Data Containers to a Configuration

When you create a new test configuration, you must specify the script that is to be executed. You may also
specify a system data container, which tells eCATT the system landscape in which it is to execute the test,
and you may specify one or more test data containers to be used as data sources for the configuration.
Note that it is also possible not to specify a test data container at all, but to supply any required data by
hand.

Fig 6: Assigning test data containers to a test configuration

Here, the two test data containers ZECATTWS_FLIGHTS (containing airline and flight number) and
ZECATTWS_AIRCRAFT (containing aircraft details) have been assigned to the script. That data is now
available to the configuration, and can be assigned using the Variant Wizard.

Hint: To look at the definition of a test script or test data container, just double-click its name in the
test configuration editor.

3.3.1 The Variant Wizard

You start the variant wizard from the Variants tab of a test configuration using the wand icon (see fig. 8). It
consists of two areas. On the left-hand side, you can see the contents of one test data container. Within this
area, you can use the buttons at the bottom of the dialog box to scroll through the various test data
containers assigned to the test configuration. On the right-hand side, you can see the variants currently
assigned to the test configuration (that is, the sets of data that will actually be executed in the configuration).
In this area, you can only add data to the variants by adopting values from one of the test data containers.
However, once you leave the variant wizard, you can fill in any gaps manually.
The variant wizard allows you to

C:\Jon\eCATT\Documents\TDC_Example_Paper.doc Page 7
eCATT: Test Configurations and Test Data Containers

Add a new variant to the configuration

Add fields from a variant in a test data container (left-hand side) to an existing variant in the
configuration (right-hand side)
Place the value of a single field from a variant in a test data container (left-hand side) in a single field
of an existing variant in the configuration (right-hand side)
Place the value of a single field from a variant in a test data container (left-hand side) into a
particular field of all existing variants in the configuration (right-hand side).
Clear the values in a particular cell, variant, or column.
Note that all of these actions only fill fields that are still initial.
Your first step will usually be to add a set of variants to the configuration from one of your test data
containers:

Fig 7: The variant wizard

You can do this by dragging a variant from the left-hand side of the screen to the right-hand side. Note that
you may use the same variant more than once. On the right-hand side, only fields with identical names to
parameters in the test data container will be filled.
Having picked out variants from your first test data container, you will probably need to fill in gaps by using
variants from further test data containers. To switch to another container, use the scroll buttons in the bottom
left-hand corner of the variant wizard. Once you have the next variant, you can merge its fields with the
variants you have already created on the right-hand side of the screen by selecting one of the variants in the
test data container (by single-clicking it) then selecting a variant on the right-hand side and choosing Add to
Variant. In this way, you can unite data that you have stored in any number of different test data containers.

C:\Jon\eCATT\Documents\TDC_Example_Paper.doc Page 8
eCATT: Test Configurations and Test Data Containers

Remember that this operation only fills fields that are currently empty. If you want to replace values, you
must first clear the existing values by selecting the relevant cells and clicking the trash can icon.
If you want to transfer the value of a single field from a test data container to a variant in the configuration,
single-click the field in the test data container display (left-hand side), then single-click the target field on the
right-hand side. Now choose Link Individual Field. To add the single value to the entire column in the
configuration (that is, to use the same value in every variant useful, for example, for fields like Company
Code or Sales Organization), choose Insert Field in Column instead. Remember again that this operation
only works on cells that are currently empty.
On returning to the test configuration editor by choosing Continue in the bottom right-hand corner of the
variant wizard, you will see something like this:

Fig 8: Test configuration with references from test data containers

Notice that the fields do not contain values, but a reference to the source of the data. This is a genuine
reference in other words, if you change the value within the test data container, the value in the
configuration will change with it.
If you leave a field blank, it will be sent to the eCATT script as such. Within the script, any default value
maintained for the parameter will be applied.
As well as using the variant wizard to construct your variants, you can also create variants manually within
the test configuration editor. Equally, you can fill out manually any fields in any variants that you have not
filled from a test data container.

3.4 Executing the Configuration

When you execute a test configuration, you have various start options. These are similar to the execution
options in the script editor, but certain options apply specially to test configurations. In particular, you can
specify which variants will be executed in one of three ways:
Leave the Variant field blank in the start options: All variants, including ECATTDEFAULT, are
executed.
Enter * in the Variant field: All variants except ECATTDEFAULT are executed.
Enter a pattern, for example, LH*: All variants whose names start with LH are executed.
You can also determine how the configuration should behave if it encounters an error. Sometimes an error
will be so severe that not just the variant in which it occurred, but also subsequent variants, are affected by it.
In other cases, it might be possible to continue processing the current variant despite the error. You can
therefore choose between the following start options for a test configuration:
Terminate start process: The configuration stops processing immediately.
Continue with next variant: The current variant is terminated, processing resumes with the next
variant
Continue with next test configuration: The current test configuration is terminated, processing
resumes with the next test configuration (this option is only applicable to mass starts in the Test
Workbench)
Continue with next script command: The error is logged, but eCATT continues processing the variant
in which it occurred.

C:\Jon\eCATT\Documents\TDC_Example_Paper.doc Page 9
eCATT: Test Configurations and Test Data Containers

4 Conclusion
Test configurations allow you to create powerful data-driven test cases while keeping the data separate from
the test scripts themselves. This clean division is more than just nice-to-have in terms of the aesthetics of
software design, it also makes it easier to separate the tasks of creating test scripts and assembling test
cases. Furthermore, the addition of test data containers to the testing environment allows you to separate
your test data even from a particular test configuration, increasing the potential for reusing this data and,
through this reuse, reducing the amount of effort required to create consistent automated test cases across
the whole scope of a particular test project. Since test data containers are extensible, you can even reuse
them across several releases by adding additional parameters and sets of data as required.

C:\Jon\eCATT\Documents\TDC_Example_Paper.doc Page 10