Consider using SAP's Computer-Aided Test Tool (CATT) when you are implementing a new system or upgrading. The author uses the example of the order-to-cash process to demonstrate its capabilities.

Key Concept

SAP's Computer-Aided Test Tool (CATT) helps you test R/3 transactions using test cases. You record a transaction, set parameters for the field values, create a variant for the set of parameters, and execute the test case to verify the results. eCATT is an extended CATT that allows you to test business processes across multiple systems, such as R/3, APO, CRM, and BW. Although the Computer-Aided Test Tool (CATT) has been part of standard SAP since Release 3.0, many companies do not fully utilize it. This might be due to several misconceptions — that you need strong technical skills to use it, that CATT cannot verify test results, or that testing in a production environment may cause data issues. None of these are true. I'm going to demonstrate how to use CATT to test end-to-end processes, which is essential when you are implementing a new system or upgrading an existing one. I'll also show how to pass the results of one test case to another using import parameters, export parameters, and local variables. The SAP help documentation does not elaborately cover testing such end-to-end processes. This may be another reason that CATT is not used extensively. My example will be the testing of one of the most common end-to-end processes — order-to-cash. You test four individual transactions — create sales order, create delivery, create an invoice, and receive cash — and then link them together. You could also use CATT for other processes such as purchase-to-pay, which consists of create purchase order, create goods receipt, post invoice receipt, and post payment. Both of these end-to-end processes are depicted in Figure 1.  

Business Case

Let's start with the end-to-end process of order-to-cash. As shown in Figure 1, it may consist of four SAP transactions: VA01 (create sales order), VL01 (create delivery), VF01 (create invoice), and F-28 (receive cash). Usually, you would create four different test cases to test these four R/3 transactions. To test the end- to-end process, you need to create one "parent" test case, which in turn calls these four test cases. To accomplish this, you need to pass the results of one test case to the subsequent test case. For example, for the create delivery transaction, you pass the sales order number created in the previous create sales order transaction. Properly setting up the individual transaction test cases with import and export parameters is the crux of the solution. Using local variables, you can pass the values between individual test cases, thus creating a flow of test transactions. If you need more information on parameters, see the sidebar, "Pass Values to Fields via Parameters."

Business Solution

Let's look at the first two transactions, create sales order and create delivery. I'll create a parent test case in which the value of the sales order number from the first test case is passed on to the subsequent test case. Once you understand the basics of linking two transactions, you can extend the logic to other transactions and create a test case for any end-to-end process. The solution consists of three steps:

Step 1. Create a test case for creating a sales order Step 2. Create a test case for creating a delivery Step 3. Create an end-to-end test case

Step 1. Create a test case for creating a sales order. Use transaction code SCAT to create a test case Z_FIAR_CREATE_SORDER. Use the record transaction icon to record transaction VA01. Follow the R/3 screens and enter appropriate values. When you save the sales order transaction, stop the recording. The system then generates the recording and a basic test case is created (Figure 2).   Double-click on the rows to review the fields (Figure 3). Note that the field values are the same ones you entered during the recording.   Instead of working with hard-coded values of fields (e.g., hard-coded sales order type OR), you should assign parameters to make the values flexible. To assign a parameter for the sales order type, replace the value of OR with &AUART. Using this method you can assign the name yourself. Alternatively, you can double-click on the field, as shown in Figure 4. The system usually uses technical name of the field and prefixes it with "&" to make it a parameter.   Because the user enters the order type field as an input, the system automatically makes this parameter (&AUART) an import parameter as shown in Figure 5.   Similarly, assign parameters to all other input values for all the screens of the recording. At this stage, the transaction recording includes the import parameters. When the sales order is saved, the system generates the sales order number. Usually, the system displays a message, StandardOrder 1000123 has been saved, where StandardOrder is the description of order type and 1000123 is the order number. This sales order number (second system message variable — M02) needs to be saved in an export parameter (&E_SO, where "E" represents the export parameter for easy identification).

Note M01, M02, M03, and M04 represent the system message variables. You use message variables to read the variable contents of system messages. System messages contain variables to, for example, display the order number generated. System messages contain up to four variables, so there are four message variables in test cases.

Once the CATT test case has its parameters, it is ready to be tested. It is a good idea to document the test case and include comments for easy reference, as shown in Figure 6.   Step 2. Create a test case for creating a delivery. Create a test case with transaction VL01 and parameterize the field's values as shown in Figure 7. The process is similar to the process for creating a test case for create sales order.   When the delivery document is saved, the system generates the delivery document number. Store this delivery number in an export parameter &E_DLVY and the test case will look like what you see in Figure 8.   Step 3. Create an end-to-end test case. Now, you will create a third test case, a parent test case, which calls these two test cases for two transactions. Note that you must save the sales order number generated in the first test case and pass the value to the second test case. I will use the local variable &L_SO (with the letter "L" representing the local variable for easy identification) to temporarily store and pass the value. Use transaction SCAT to create a referenced test case Z_FIAR_SORDER_DELIVERY and refer to the two test cases — Z_FIAR_CREATE_SORDER and Z_FIAR_CREATE_DELIVERY (Figure 9).   Double-click on row 1 and assign the export parameter &E_SO to local variable &L_SO (Figure 10).   Now, the sales order number generated in first test case is stored in local variable &L_SO. The second test case has an import parameter &VBELN_VLA for the sales order number. Before you call the second test case, assign the value of the local variable to the import parameter. Document the test case and the test case will look like what you see in Figure 11. This test case now can test the end-to-end process of order-to-delivery.   When you execute the test case Z_FIAR_SORDER_DELIVERY, it first calls the test case Z_FIAR_CREATE_SORDER. The system generates the sales order number and assigns it to the export parameter &E_SO, which in turn is stored in local variable &L_SO. Within the main test case, this local variable is assigned to import parameter &VBELN_VLA (SETVAR &VBELN_VLA = &L_SO). The system calls the second test case Z_FIAR_CREATE_DELIVERY for the specific sales order generated in the previous test case. An overview of the flow is shown in Figure 12. Extending the basic concept explained here, you can include test cases such as create invoice and receive cash to test the whole order-to-cash process.   Follow these best practices to design test cases to maximize the benefits of CATT.

• Use parameters and variables to make CATT test cases flexible Instead of hard-coding and using default values, parameterize the test cases to make these flexible. Similarly, instead of using fixed and hard-coded dates, use system variables like &JHR (year), &DAT (date).
• Use variants to make test cases manageable Using variants with different sets of parameter values can also give more flexibility to the test cases. For example, you can use different sets of variants to test different scenarios for the same business transaction.
• CATT test cases should be reusable Try to design test cases so that the test cases can be reused in other test scenarios. For example, the create customer transaction is used in FI as a part of a master data test. The same test case can be used in SD as a part of an order-to-cash scenario test.
• Test cases should verify the test results A good test case also verifies whether the test case was successful. Using various check functions, test cases should validate and verify the results of a business transaction.
• Document test cases A good test case not only tests a transaction. It is well documented for easy reference and modifications, if required. Documenting the test case helps in maintaining the test cases for full use.

 

---