One thing that probably all SAP projects
have in common is that they have to be tested. Whether you’re working
on a big-bang implementation for a multinational company, applying the
latest legal changes to mySAP HR in a single country, performing a regression
test for a release upgrade, or rolling out a major in-house development,
you need to ensure that the changeover in your production system will
be as smooth as possible.
Essentially, there are two ways to test
software. You can either assemble a group of living, breathing human beings
and make them work through test plans, or you can try to automate the
test process as far as possible. For usability testing, your team of human
testers is irreplaceable, of course. But for functional testing (e.g.,
checking that business process transactions are functioning properly once
you apply Customizing settings), automated testing provides numerous benefits:
your test scripts can be run over and over again — and without demoralizing
a human tester! Most test tools will also collate test results automatically,
giving the test administrator a real-time overview of the state of play
— what has been tested, and with what degree of success.
There are various tools for automated testing
available on the market, many of which can be used to test SAP applications.
However, these tools all work by harnessing the SAP GUI — recording
the user’s entries when you create the test script, and playing them
back at runtime. As such, these tools have no access to what is happening
within the SAP application server during the test. This means that while
it is possible to follow a transaction, or sequence of transactions, from
start to successful (or unsuccessful) finish, there are only limited opportunities
to check things along the way — like the value of a particular screen
field, or even whether certain data has been written to the database successfully!
The Evolution from CATT to eCATT
The tool in the best position to cover
the entire transaction has been SAP’s own test tool, the Computer
Aided Test Tool (CATT), available since R/3 Release 3.0 as part of the
Basis system. With CATT, you could take a look inside the applications
and check various elements, such as variables, messages, and table contents.
You could also simulate changes to Customizing settings without having
to make them hard and fast in your system, allowing you to create very
elaborate tests before resetting your original Customizing settings with
a single command.
In recent R/3 releases, however, CATT has
been unable to test certain features that have become standard in the
SAP landscape. For example, the controls technology for developing more
powerful, user-friendly interfaces introduced in Release 4.6 uses techniques
that are incompatible with CATT testing. Increasingly, too, business processes
reach across system boundaries. Sales orders entered in a CRM system may
be relayed to an R/3 system, which in turn communicates with an APO system
before the production planning is finally fixed. While it is possible
to test such business processes with CATT, managing test cases in various
systems could be difficult as the number of test cases and different systems
starts to increase.
In view of these limitations, Release 6.20
of the SAP Web Application Server (Web AS) contains a new test tool to
assist SAP customers working in Release 4.6C and up: the Extended Computer
Aided Test Tool or eCATT.
The main features of eCATT are:
- Improved test support for distributed systems
- Test support for controls technology
- A new and improved user interfacen Support for external testing tools
- A new management concept for test data
Let’s look at each of these five points in a little more detail.
Improved Test Support for Distributed Systems
In CATT, remote execution of test procedures
was possible, but not always particularly convenient. The most frequently
used solution was to store the test procedures remotely in the target
systems and to call them from a central script, which led to the problem
of keeping track of all of those scripts across various systems!
Figure 1 compares that approach
to eCATT’s new process for remote script execution. All test scripts
are created and maintained in a designated system, but they can be executed
in any system running Release 4.6 or higher that is accessible using RFC.
A separate eCATT object, called a system data container, contains
a list of all of the target destinations that a script needs to address.
||Comparison of Script Management Techniques in CATT and
Test Support for Controls Technology
One of the major problems of using CATT
to test R/3 4.6C systems has been the lack of adequate support for controls.1
The reason for this lies in the nature of the controls themselves and
the existing CATT architecture. At runtime, CATT procedures are executed
wholly on the application server, that is, with no associated SAP GUI
instance. However, for controls to function correctly, they must be instantiated
at the frontend within a running SAP GUI. Consequently, CATT is unable
to record or play back control data adequately.
In eCATT, this has been remedied by the
new SAPGUI command, which uses a new scripting engine within the SAP GUI
to record a user’s on-screen actions. This recorded data is stored
in a test script and can be parameterized and replayed in much the same
way as a conventional transaction call, thus opening up many more SAP
applications to automated testing.
New, Improved User Interface
While SAP has been extending the scope
of eCATT to include transactions that use controls, the development team
has also made extensive use of the same technology to create a new user
interface for eCATT. Compared with the CATT user interface, it is now
easier to use and more compact — as Figure 2 shows, you can
now edit your script commands and parameters all on the same screen.
||eCATT Script Editor
A structure editor also allows you to display
and edit structured parameters, such as internal tables for function modules,
the structure of screens and fields within a transaction, or ABAP Dictionary
Integration with Third-Party Testing Tools
eCATT contains a new interface allowing
vendors of third-party test tools to integrate their tools with the eCATT
environment. This integration allows you to use eCATT in conjunction with
an external tool to test applications that cannot otherwise be tested
using “pure” eCATT means, such as any applications with user
interfaces written in HTML, Swing, Visual Basic, and so on. Scripts created
using the external tool can be stored centrally in the SAP database, transported
through your test landscape using the SAP Change and Transport System,
and called from any eCATT script.
New Management Concept for Test Data
In CATT, the data that you used for a test
was stored together with the test procedure itself in the form of a variant.
This meant that test data couldn’t be reused — but how many
test procedures do you have that first require you to create the same
sets of master data? Probably a lot.
In eCATT, this concept has been changed,
and data is now stored separately from test scripts in special objects
called test data containers. The advantage of using separate data
containers is that the data becomes available to any script that needs
To create an executable test (shown back
in Figure 1), you use an object called a test configuration, which
is the combination of a test script, a test data container, and a system
data container (the list of target systems that will be addressed by that
eCATT is available with the SAP Web Application
Server Release 6.20. Patches will also be available for previous releases
from Release 4.6C onward to enable you to use the SAP Web AS 6.20 as a
central test system, from which you can run tests in other systems.
As you can see in Figure 3, only
the central test system requires Release 6.20. So, long before you upgrade
your other solutions to a release based on Web AS 6.20, you could use
a standalone SAP Web AS to take advantage of the new features offered
||Using the SAP Web AS 6.20 as a Central System to Test
For more information on getting started
with eCATT, consult the documentation for Release 6.20 of the Web Application
Server under http://help.sap.com.
Migrating Existing CATT Procedures
An important consideration for many
customers who have invested a lot of time and money in building
up CATT tests is Can I migrate from CATT to eCATT? The answer
is a resounding Yes!
In addition to the new features described
here, eCATT also includes a migration tool that converts CATT test
procedures into eCATT test scripts. Much of the conversion is automatic,
although there are certain conventional CATT techniques (such as
dynamic changes to RFC destinations during a procedure) that will
have to be manually adjusted after the conversion.
more information on controls technology in R/3 4.6B and up, see the book
Controls Technology, available from SAP at www.sap.com/shop.
See also the June 2000 issue of SAP Insider in
the Article Archives, and the article “SAP Controls Programming
Essentials — What Every ABAP Developer Now Needs to Know” in
the November/December 2001 issue of SAP Professional Journal (www.SAPpro.com).
graduate in modern languages from the University of Bristol (UK), Jonathan
Maidstone joined SAP in Walldorf in 1996 and worked as a translator for
the ABAP Workbench and ABAP language groups until late 1999. Following
a spell as a technical writer for the SAP Control Framework and DCOM Connector
groups, he is now part of the product management group for Business Programming
Frameworks, with particular responsibility for eCATT rollout. Jonathan
can be reached at firstname.lastname@example.org.