Testing SAP Business Processes

After our SAP developers have coded solutions that address our company’s discrete business processes, testing beyond simple unit testing becomes necessary. That is, the months of work involved in translating, upgrading, or creating an organization’s business processes into SAP best practices must culminate in a comprehensive testing phase. No implementation is complete in the absence of testing. Indeed, no project will succeed without it. This brief chapter focuses on a number of types of business-process–specific testing that must occur, when each must occur or is appropriate, and how each type helps to ensure a smooth transition from an old way of doing things to an integrated mySAP.com-based approach.

Thus, the focus here is exclusively on business process testing, which verifies that processes actually execute as expected and create output as expected. Business process testing is not surprisingly resource-intensive, especially when you consider the amount of time consumed in recoding and retesting your business processes after you’ve gone through the first wave of testing. Testing teams must be assembled and given direction, and everyone must understand that they are engaged in an iterative and very detailed process, not a one-time exercise.

Other types of testing focus more on system-level performance and overall mySAP.com load or stress testing (the terms are used interchangeably), tasked with ensuring that these same business processes execute as rapidly as possible under loads similar to what the production environment will eventually endure. And somewhere between integration testing and stress testing lies volume testing, the purpose of which is to understand the capacity requirements (including elapsed time) of a system. For example, prior to Go-Live many companies execute a large volume of transactions such as might occur during month-end closing; in this way, performance limitations are better understood. Both volume and stress testing lead to improved planning and scheduling of resource-intensive system events as well, allowing an organization to set expectations with the system’s end-user community. Volume and stress testing are covered in detail throughout Chapter 16.

Introduction to CATT and eCATT

SAP components include test organizer capabilities that let you plan for and manage the various types of testing that take place throughout a deployment. Instead of relying solely on the test organizer, I prefer to leverage a detailed master project plan that allows for managing the big picture. In this way, the test organizer is relegated to simply organizing and managing test cases, which are basically documented business processes complete with input, processing, and expected output.

The test organizer historically leveraged in SAP implementations is referred to as the Computer-Aided Test Tool (CATT). CATT supports recording and documenting test cases, generating input data, and executing these test cases, even to the point of doing so in an automated fashion. CATT provides for capturing and creating output data as well, in the form of straightforward log reports that facilitate low-level test results examination. CATT has been around since R/3 Release 3.0 and is not only free, but also has the advantage of being tightly integrated with the system. And it’s fast—by using Batch Input technology, test cases are executed directly on the application server rather than relying on the ability to drive the SAPGUI interface. Furthermore, CATT allows testers to incorporate extensive behind-the scenes checks into their test cases, based on access to data simply not available to the SAPGUI (like verifying the contents of a database table, or performing a field check to verify customizing settings). CATT has its limitations though, including

• Limited support for external applications that might play a role in an organization’s extended enterprise solution; CATT cannot support user interfaces outside of the SAPGUI for Windows or the JavaGUI.

• Limited support for distributed mySAP.com system landscapes, resulting in the need to use RFC destinations in your scripts (or to build multiple test cases across your mySAP enterprise to simulate an end-to-end business process).

• Limited function module support; calendar functions are available, for example, but there is no function module support for tabular parameters.

• Controls and other technology (like tree controls and list viewers) found in more recent releases of mySAP.com and the EnjoySAP SAPGUI are not supported, thereby severely limiting the “testability” of certain business processes.

• Limited ability to execute testing remotely; it’s possible (again, through RFC calls to SAP systems, or multiple test cases otherwise) but represents a lot of work in terms of script development and management.

To address these shortcomings, SAP developed an even more powerful and capable integrated testing tool, as you see in Figure 15.1. Referred to as eCATT, or extended CATT, this highly refined tool was introduced with Web Application Server 6.20, and supports testing any mySAP.com solution running on basis layer 4.6C or greater (refer to SAP Note 519858 for current details regarding any support packages that might be required). Support for older basis releases is planned as well.

Throughout this chapter, I will be referring to eCATT unless another tool or approach is explicitly noted. And again, keep in mind that when a business process executes over and over again flawlessly, a different type of testing is called for—stress testing. In this case, testing is taken to the next level, and specific business processes are executed concurrently by many users, in what is also referred to as a stress test or load test (a close relative to Capacity Planning). In this way, the unit-level activities tested to this point are further refined and proven to ensure that the Production system is truly capable of hosting the number and diversity of users and business processes required by the business.

Before we examine how to approach and actually execute various types of testing, let’s step back and take a closer look at the three broad types of business process testing first.