Smart testing

Whoever tests is a coward? Not at all! Those who do not test are not familiar with the Business Process Change Analyzer (BPCA) as a sub-functionality of SolMan - nor with its unbeatable advantages in the context of optimizing the scope of testing.

This benefits process owners, test managers, key users/testers, SAP Basis, all decision-makers, and end users. And thus ultimately the process stability and SAP operation.

After all, if you really want to test smart, you need such a tool. And certainly all of the above-mentioned players with solid process know-how - above all, in order to classify the results of BPCA, especially for the test scope defined by BPCA and thus the defined test cases. This is the heart of the BPCA.

But one after the other:

• Who can use the BPCA?
• How is the path to that goal shaping up?
• What are the BPCA use cases?
• What is the result?
• And what benefit do I derive from this?
• And why an article on BPCA just now, when it has been around for several years?

The latter question first: With SolMan 7.2 a newly organized solution documentation is available. Solution here means: Unit of all systems including process documentation, test cases, executable units ([Z-]transaction, [Z-]report). Solution documentation can be differentiated by maturity level (production vs. maintenance vs. development/sandbox). This enables versioning of the documentation that can be separated by content.

What are the BPCA use cases? What does the result look like? And what benefits do I derive from this? The central question behind all use cases is: Which business-critical processes are affected by a change that has been made? In other words, which processes need to be (re)tested to ensure process stability or SAP operation?

BPCA-relevant changes can be: SP/EhP upgrade, activation of business function, (object in a) transport request, ChaRM change document including transport requests and object lists. All BPCA-relevant changes have one thing in common: They must exist in a transport request in the development system.

The BPCA result is a list of all processes/process steps affected by a change, i.e. the scope to be (re)tested. If no test plans are available for this, they can be generated at the push of a button and stored in the Test Suite.

Faster is not possible! If the test scope initially defined by BPCA is too extensive or cannot be processed in the time available due to the available resources, pragmatic approaches to test scope optimization are available (for example, 75% test coverage: 10 test cases vs. 90% test coverage: 100 test cases).

The benefit is clear: an initial recommendation on the scope to be (re)tested. Often an intellectually unfeasible task. In addition, it is often not possible to map it in terms of resources.

In my opinion, a review of the respective BPCA result by a process expert is essential. After all, anyone who deliberately misunderstands the benefits of BPCA should not embark on the journey in the first place.

And so to the last questions: Who can use the BPCA? How does the path to it work?

SAP Enterprise Support customers can currently benefit from BPCA. The path to BPCA analysis is roughly as follows: Define processes and process steps and store them with executable units, perform the BPCA configuration in the solman_setup and generate so-called "Technical Bill of Materials" (TBOM) per executable unit based on UPL/SCMON data in the production system.

Then pack the change into a transport request, run the BPCA analysis on this transport request, analyze/interpret the result and, if necessary, create a test plan from it - done! This paves the way towards "smart testing".