Fortunately, Solution Manager provides an alternative solution to this problem. It helps you organize tests after you’ve defined the business scenarios in the Business Blueprint phase and made initial configurations in the realization phase. Solution Manager not only manages a project’s life cycle, but you can also use it for ongoing maintenance.

At a high level, the test cases are grouped to become the test plan. Test cases are basically steps that the tester needs to execute in a test script to verify that the designed solution meets business requirements. These steps are grouped as test packages. The test cases are grouped together on the basis of the testers who are responsible for executing these steps. The following sections explain how these various tasks are carried out .

First I will explain the configuration setup, and then I will go over test planning. In the configuration setup section, I focus on some of the basic configuration activities that you need to set up in Solution Manager to execute testing. In the test planning and execution section, I show how you can manage, execute, and monitor tests in Solution Manager. To execute testing in Solution Manager you need to carry out basic configuration activities, such as the number of cycles of testing and testing statuses.

Figure 1 shows how Solution Manager is set up for testing and how testing is executed.

Figure 1

Solution Manager testing

Configuration Setup

Before beginning the configuration setup, you must have finished all required Solution Manager Project setups, including standard configuration of basic settings and satellite system connections — either SAP NetWeaver Business Intelligence (SAP NetWeaver BI) or Advanced Planning and Optimization (APO). The project setup includes the system landscape setup, project team members, and project documentation types. The SAP documentation explains what the definitions are, but doesn’t tell what values you need. I will show you exactly what needs to go in each of those steps.

Step 1. Prepare the test cases. First, you need to identify the test cases. This happens when the implementation team gathers the business requirements from the business users. For example, as the project team defines the requirements for purchase requisition approvals, you can see what variations of the approval processes you need to test. One variation could be that when the requisition value exceeds $100,000 the vice-president has to approve the requisition. Another variation could be that if the requisition value is $50,000 the director has to approve the requisition. These variations become the basis for creating test cases. These test cases become clearer at the time of configuration when you configure and unit test the various transactions. You can then identify the transaction and its variations as test cases (Figure 2).

It is important that you, or the person responsible, have already set up the business processes as part of blueprinting. Blueprinting identifies the structure for each track, such as order-to-cash or procure-to-pay. Procure-to-pay business processes are shown in Figure 3.

Each block, in turn, has a set of sub blocks. For example, the sub blocks for the test cases in the procure-to-pay process would include:

• Requisitions PTP-01
  • Create and process requisitions
    • Expense requisitions creation (ME51N)
    • MRP requisitions change (ME52N)

• Approve requisitions
  • Approvals for network department (ME54N)
  • Approvals for application infrastructure department (ME54N)

You can associate test cases transaction codes and URL links. For example, the test cases can represent a link to a Web site.

Next, specify the test case variations based on the business requirements (as described in the procure-to-pay example. Follow menu path Business Scenarios > PTP: <process> > Business Processes > Process Requisitions > Create Requisitions, Approve Requisitions. Select Business Process, switch to the Structure tab, and then add the Process Requisitions and any other structures as required (Figure 4).

You can use the same transaction code for multiple test cases, and you can use these test cases as the basis of your test plan. For example, approval of requisitions for the network department could have a requisition with a $5,000 value, whereas in the infrastructure department the dollar amount might be $10,000. In both situations, you can associate these test variations with the transaction code ME54N (with the test case for network department valued at $5,000 and infrastructure department at $10,000).

Once you have the test cases prepared, you need to enter them in the system so the testers can access them. Follow menu pathTools > SAP Solution Manager > Configuration > Business Scenarios (Figure 2).

Step 2. Configure Central Test Workbench settings. Use transaction STWB_SET and select Status Definition to set up the testing statuses (Figure 5). You can also use IMG menu path SAP Solution Manager > Configuration > Scenario Specific Settings > Implementation > Testing > Central Setting for Testing > Define Values for Testing > Select Status Definition.

Click the Display button so you can specify the settings that identify the various test results statuses, such as OK, Test Execution Error, or Untested (Figure 6).

Each status has a traffic signal and shows whether or not you can select it when executing a test.

Step 3. Define the testing stages using a test sequence. The testing cycles are standard irrespective of the methodology used. The most commonly used sequence is the ASAP methodology that SAP recommends. Different system integrators enhance ASAP methodology and use their own customized version of ASAP. All projects have unit testing, followed by different cycles of integration testing, and finally user acceptance testing. You define the different cycles of testing by using transaction STWB_SET and following IMG menu path SAP Solution Manager > Configuration > Scenario Specific Settings > Implementation > Testing > Central Setting for Testing > Define Values for Testing > Select Test Set (Figure 7). In the next step, specify the test case variations.

Step 4. Create the test plan. The test plan is the sequence of steps by which you test a business process. Using the end-to-end process model from Figure 5 as a basis, I identified the test case variations for requisitions. You can string these test cases together to create an end-to-end process script.

For example, an end-to-end process script for an infrastructure department identified as test cases can have the following steps:

• Expense requisitions creation (ME51N)
• Infrastructure department approvals for dollar value of $5,000 (ME54N)
• Assign a source for the requisition (ME57)
• Create a purchase order from the requisition (ME21N)

Similarly for the network department an end-to-end process script can have the following steps:

• Expense requisitions creation (ME51N)
• Network department approvals for dollar value of $10,000 (ME54N)
• Assign a source for the requisition (ME57)
• Create a purchase order from the requisition (ME21N)

To set up an end-to-end process script, follow menu path Tools > SAP Solution Manager > Test Plan Management. Associate each test plan with a test set to identify whether the test plan belongs to integration test cycle 1 or integration test cycle 2 and so on. Integration testing cycles refer to the testing of test cases belonging to more than one module. For example, when you create a purchase order, the goods receipt belongs to procurement and invoice payables belong to the finance department. These three test cases are tied together to create a test plan. Typically, integration testing cycle 1 tests the SAP system’s functionality and integration testing cycle test 2 tests the SAP system’s functionality and custom development, such as interfaces or user exits (Figure 8).

The sequence of steps identifies how the test plan is executed (Figure 9). The user executes the steps based on the number identified: PTP_01_01 Create Online Purchase requisition first followed by PTP_01_02_Review Purchase requisition, and so on.

Step 5. Create test packages. You can group the steps by the role performing them. This grouping of the steps is called a test package.

For example, recall the steps for the network department’s end-to-end process script:

1. Expense requisitions creation (ME51N)
2. Network department approvals for dollar value of $10,000 (ME54N)
3. Assign a source for the requisition (ME57)
4. Create a purchase order from the requisition (ME21N)

If the same business user performs steps 3 and 4, you can group these steps together as one test package. To group steps, follow menu path Tools > Solution Manager > Test Plan Management > Test Plan Title. Enter the test plan title and then select the Create Test Package tab.

For example, in a requisition process once the requisition is created, the buyer selects a supplier for the requisition and then converts it to a purchase order. Because the same business user performs both steps, you can group them into the same test package. To do this, select the business process Select supplier for the Requisition and Create Purchase order from the requisition. These two business steps are now grouped under the same test package. Assign a name to the test package.

Step 6. Assign test roles to the test plan. After you identify the various scenarios, the next step is to associate each test step with the person responsible (role) for testing the scenario. Figure 10 shows how each step in the test plan is associated with a security role. This is done by following menu path Tools > Solution Manager > Test Plan Management > Test Plan Title.

Figure 10

Test roles associated with testers

As you did in step 5, enter the test plan title and then select the Test Package tab. The test plan shows the various test packages associated with the test plan. Select the Assign Tester tab. Each tester has a sequence of steps to execute based on the role assigned to him for each test plan.

Step 7.Document the test results. You can document the test execution results by attaching test scripts to the test plan. Follow menu path Tools > Solution Manager > Test Plan Management > Test Plan Title. Enter the test plan title and then select the Attributes tab. In the Test Plan Attributes screen, switch to the Attachments tab, and then select Create. Attach the test document script (Figure 11).

Figure 11

Document the test results

The test script is a Word document that contains each step’s details. Each step shows the transaction code being executed, test script description, security role, and expected and actual results. Once a step is executed, the results of the transaction are documented in the Actual Results. The system then marks the step as passed.

Now that you know how to set up the test center, it’s time to begin testing.

Test Execution

Step 1. Execute the assigned test case.The tester logs in to Solution Manager with the appropriate role. The system shows all the test packages assigned to him. The tester looks at the steps and starts executing the tests. Figure 12 shows the test cases assigned to a tester. The tester executes all the steps in the test package.

Figure 12

Test cases assigned to tester

Step 2. Execute the test steps. To see the list of test packages assigned to the tester, the tester enters STWB_WORK in the field at the top of the screen. The step number identifies the sequence in which to execute the steps (e.g., IT2_PTP_01 Expense Purchase). Start with the first test case and click the test object. The test object can be a transaction code, URL, or an ABAP program (Figure 13).

Figure 13

Test case execution

Once you click the test object, you view the test object screen. For example, if you need to change a purchase requisition, Solution Manager automatically logs you into SAP ECC and takes you directly to transaction ME52N, the Change Purchase requisition screen. There, you can execute the transaction by entering the relevant data — such as material description, quantity, and price — on the requisition. The system automatically saves the requisition and notes the requisition number that the system generated automatically. You can then mark the step as OK or Failed by switching to the Status tab on the test case after executing it.

The tester then executes each test. Once the transaction associated with the step is executed, the tester documents the results by clicking the Attachments button (Figure 13). The traffic lights to the right of each step indicate the test results. In this case, the test passed. PTP_01_05 and PTP_01_07 indicate the steps that the tester needs to execute.

Step 3. Document test results in the test script. After executing each step, you can document each step’s test results execution in Solution Manager. Use transaction STB_WORK, select the test plan, and then select the Attachments tab. The tester records the execution results, whether the step passed or failed. The executed steps can fail for several reasons. For example, the configuration was set up incorrectly or the master data was incorrect. This documentation of the test result is a manual step required for every step.

Figure 14

Test case result documentations

Step 4. Test analysis and monitoring.Solution Manager automatically keeps track of the testing results. You can monitor test results for each test plan or for the entire testing cycle. To display the monitoring of test results for a specific test plan, follow menu path Tools > SAP Solution Manager > Project Analysis > Test > Test Plan Analysis. Solution Manager keeps track of the total number of steps passed or failed, but you have to manually document the test results in the attachment (Figure 14). You need to enter the project, test set, and the test plan, as shown in Figure 15, so you can to review the test status of the test plan.

Figure 15

Reporting on test results

Upon execution, the test results of the specific test plan are displayed. Figure 16 represents the test results for a test case. The test results are captured automatically for each test case. The test shows the following:

• Test plan: IT2_PTP_01_Expense_Purchase Requisition
• Errors (%): 0 (all steps were executed successfully)
• OK (%): 100 (all steps passed)
• Errors: 0 (no errors)
• OK: 13 (all 13 steps of the test plan executed successfully)

Figure 16

Test results monitoring