The self-testing system

Only recently, I have been repeatedly asked about the topics of test management and test data generation. Specifically, customers have asked me whether Solution Manager also supports the concept of test data generation. In the overall context of all the functions provided by SolMan, this is a very advanced question.

Before thinking about this, some preliminary work needs to be done. Automatic provision of the data makes sense, but should be accompanied by an overall package.

The first step is to record the business processes and document and record them in the solution documentation. With the SAP note on the Blueprint Generator, the individual transactions used in the productive system can be inventoried.

A transaction is assigned to an outline level based on its package. Each package is assigned a unique SAP component.

Customers who have packaged all their Z-transactions into one package across modules need to revise this. The created outline with its individual transactions must be combined into several end-to-end process chains by means of links for the test procedure.

The next sensible step is to use the Business Process Change Analyzer. For this purpose, parts lists must be recorded of all relevant business processes. On the basis of these parts lists, which represent the programs that run and the Customizing entries used, it is possible to determine which business processes a transport request relates to during each productive import. In this way, an initial tendency can be given as to whether a test makes sense.

Since these parts lists change with each import into the production system, continuous updating is required. Once these processes are established, one can now move on to the next topic, the automation of test cases. The somewhat outdated ECatt, basically nothing more than a batch input recording, should no longer be used.

With Component-based Test Automation, SAP provides a tool for customers with Enterprise Support contracts that is significantly easier to handle, record and repair test cases.

In addition to the classic SAP Gui, all modern interface technologies are also supported. The tool already embeds the known program flows of all transactions delivered by SAP, so that one test case can be easily linked to another on a graphical interface.

In-depth programming knowledge is therefore no longer necessary. Professional users will certainly consider licensing a test tool such as Worksoft Verify or HP Quick Test Pro or HP Quality Center as an alternative to CBTA. The next step is the automatic generation of test data.

Many customers like to create a system copy of the production system, either classically or with tools to narrow down the database content. I am not a fan of copies in regulated environments, as this also puts relevant, business-critical data into the quality assurance system.

Usually the authorization concept on the quality assurance system is somewhat more permissive than on the production system, so this is a relevant problem. A generation of relevant test and master data can now only be ensured by creating test cases to build this data, which then each run before a test chain and generate the data. The construction of this data can of course become arbitrarily complicated.

With the CBTA, SAP provides a very good and advanced tool to record test cases easily and quickly. There is definitely some preliminary work to be done in order to enjoy automatic test cases.

Certainly, this approach is not worthwhile for all processes, but only for the particularly relevant ones or those that can only be tested manually with a lot of effort. An overall concept always consists of increased use of unit tests, automated tests, and continuous updating of the existing process documentation.