Who tests is a coward

During the SAP release change, it is more than sensible to test the company processes again completely in a process chain and thus ensure a successful upgrade.

If the "SAP system" is now to be tested, the question usually begins as to what should be tested at all and how it should be tested. Many customers are then used to organizing the aged test plans of the last patch and, if necessary, still revising them.

However, this is usually where the first question arises: which transactions are not yet listed on the test plans and need to be included, which reports are outdated and are no longer used at all and can therefore be disregarded.

This compilation and inventory alone is no simple task. I have experienced an IT manager who, four weeks before the start of the test phase, instructed the departments to enter all used transactions in an Excel sheet on an ongoing basis.

Although this is a good start, it is a Sisyphean task. In particular, the period under consideration is usually insufficient. With the Blueprint Generator, which SAP now delivers as a note, the transactions used in the production system can be inventoried and stored in the solution documentation.

This is not yet a test plan, but at least it ensures that all transactions used are actually inventoried in a structure. This is a simple way to create a starting point for a test plan that is, above all, complete.

The helpful Blueprint Generator can also perform delta updates, i.e. add new transactions to existing structures. This is usually the case when documentation already exists, but is somewhat outdated.

How to create a powerful test tool

A test plan can then be built on the basis of the generated documentation structure. It is true that technically a test plan can then also be created and processed from this structure.

However, this plan then only contains the transactions. This is usually not very helpful, because relevant specifications are still missing, with which master data, document types and item categories a transaction is really to be tested.

It makes sense to supplement the generated structures with the Excel documents that most customers have on file shares anyway and use to organize their test cases to some extent.

These documents can also be revised and fine-tuned in a later step, but it is usually important to first create a starting point and a beginning.

If the documents are sufficiently complete, meaningful test plans can now actually be created. Test packages are usually formed from the test plans and these are assigned to individual persons.

It makes sense to test processes as they run in reality and not just to perform function-oriented individual tests. Under this prerequisite, "test sequences" must be formed that map the natural sequence of a process chain.

In this way, several specialist departments can also collaborate on a process via these sequences. The de-luxe variant in conjunction with test sequences provides for testers to be prompted to test their process or transaction by e-mail as well.

A reminder model with escalation function can also be implemented in the framework. All in all, a powerful test tool is created. Ideally, the test cases and test plans are also continuously maintained.

Which business processes are relevant?

Since the scope of testing usually grows continuously as the functional scope of an IT environment increases, it is all the more important to test in a targeted manner when it comes to integration testing.

SAP's Business Process Change Analyzer can identify the relevant business processes that have been changed as part of an upgrade, a business function, or even with a transport. On this basis, it is then possible to map a considerable simplification and streamlining of the test procedures, since only the really relevant business processes then need to be subjected to a test.

In conjunction with business process documentation and change management, the test management component of the
Solution Managers can provide a useful addition to application lifecycle management. Even though it is often difficult to get started, a pragmatic solution can be developed and established in a simple way.