After the headquarters or reference location goes live in your SAP system, you must plan the rollout to other locations. The rollout location usually copies about 80% to 85% of the functionality of the reference implementation. The remaining functionality meets local legal requirements and you cannot copy it. You need to plan for the testing of any functionality specific to those rollout locations.

Rollout location implementations follow the same ASAP roadmap as the reference implementation project. You can download the Web-based roadmap from SAP Service Marketplace (SMP login required). The system-based roadmap is available in SAP Solution Manager’s RMMAIN transaction. The ASAP roadmap phases are:

• Phase I:  Local project preparation
• Phase II: Local business blueprint
• Phase III: Local realization
• Phase IV: Local final preparation
• Phase V: Local go-live and support

In this article, I concentrate on the first three phases in detail.

Phase I: Local Project Preparation

The local project can continue with the testing model of the template project. If the template project was implemented using transaction SOLAR_PROJECT_ADMIN in SAP Solution Manager, then you copy the same template for the local project as well. In my example, I created a project of the type Implementation and selected the template of the reference implementation as shown in Figure 1.

Figure 1

Local implementation project showing reference template selection

Phase II: Local Business Blueprint

The majority of the functionality for the local Business Blueprint is copied from the template implementation project. Copying the template ensures uniformity of business practices across locations. In this phase, the local implementation requirements of the project (based on location) are determined as an additional scope. You make any needed changes to the template project processes and add any new processes using the Business Blueprint transaction SOLAR01. The new scope becomes part of system integration testing.

Phase III: Local Realization and Testing

In the Realization phase you carry out the configuration and necessary development, including the reference template functionalities and local requirements. You can use transaction SOLAR02 to access the reusable configuration and test cases and to attach the local location configuration objects, test cases, and documents. You can reuse Business Configuration Sets (BC Sets), which are bundles of configuration steps, to configure scenarios that are the same as the scenarios of the template project (if you used them in the original project).

From a testing perspective, this phase involves the identification of an additional automation scope (if any). Once you complete the creation of the manual unit test cases, you carry out the unit testing in the development server. The transports are manually moved to a quality server and then system integration testing takes place in the quality server.

The end-to-end integration test cases related to the local project are attached in transaction SOLAR02 (Figure 2). It shows the addition of an extended Computer-Aided Test Tool (eCATT) script. eCATT is an SAP test automation tool and eCATT test cases are linked if the tool is used for automation.

Figure 2

Realization transaction SOLAR02

The test coordinator or the business process expert adds the specific local test cases in transaction SOLAR02, where there is already a list of the test cases that are present (Figure 3). After these test cases are added, the project is ready for test management in SAP Solution Manager, including text execution, bug fixing, and reporting.

Figure 3

Local project-related eCATT scripts

System Integration Testing Phase

System integration testing for a local rollout location is quite fast if the completely automated model was selected during the template implementation. You use the same automated test scripts with local implementation-specific test data. Additional automation is required for local scenarios and you can execute it along with the common functionalities. For example, in sales order creation under pricing, taxation is location specific. Therefore, the sales order creation steps would be common in the template except for taxation. You would add taxation steps in the rolling out location, and create a set of data specific to the local location during test execution. For system integration testing, I recommend you create new test plans for the local location from the current SAP Solution Manager project. This helps allocate the work for the testing teams by checking resource availability. The rest of the management of system integration testing is the same as in the template project.

Regression Testing Phase

In regression testing, all the test cases of the template implementation should be executed to ensure the current project has not affected live business. If every new location that goes live is on the same central SAP production server, then the extent of the testing effort increases with every new location. In most cases, there is a central production server. Therefore, test management planning is critical and involves parallel test package execution and quick bug fixing. Along with effective test management, the quality server should be locked for all the users except the testing team. This enables you to use all the resources of the quality server only for testing purposes. 

In this regression test, you execute all the functionalities across all these locations with a given set of data relevant to them. The aim is to ensure that all cases execute successfully so you can verify that the current rollout project has not affected any existing production functionality. For example, if a company has a large volume of data, complex scenarios, and multiple vendors or resources working on the same server, a rollout in Paris could affect a previous rollout in London.

For regression testing, create new test plans for the template location from the template project in SAP Solution Manager using transaction STWB_2. If the project management functionality is not being used, copy the test catalog of the template project for this current location, especially for regression testing, using transaction STWB_1 and then create test plans and test packages.

If you are not using project management functionality, use transaction STWB_1 to copy the test catalog of the template project for this current location, especially for regression, and then create test plans and test packages. If you are using project management functionality, create new test plans for the local location from the template project in SAP Solution Manager using transaction STWB_2. To do so, search for the test plan of the template project using transaction STWB_2 (Figure 4). Click the enter icon to see the test plans of this template project (Figure 5). Note that project management functionality is mandatory for using standard reports available in transaction SOLAR_EVAL. You cannot use the reports if you use the test catalog feature.

Figure 4

Test plan search help showing search by template project name

Figure 5

Test plan search results

Select the test plan from Figure 5 (Asset Liability Management Demo in this case) and return to transaction STWB_2 (Figure 6). This is the test plan you can copy with a different name for regression testing. Copy this test plan (including test packages) by clicking the copy icon highlighted in Figure 6. Use a new name that has the current rollout location name (e.g., Location 1 in my example) at the end (Figure 7). Once the test plan is copied, the system returns to transaction STWB_2 (Figure 8).

Figure 6

Selected test plan

Figure 7

Copy of test plan with new name

Figure 8

Transaction STWB_2 with the newly created test plan

You can copy all the test plans from the template project as required for the regression test execution. Once all the test plans are copied for the current project, create the test packages. Then create test data for the regression-related test cases. Prepare the test data specific to the earlier live location of the production server, with a minimum of one set of data for each test data variant. For example, for you can test sales order creation in transaction VA01 for order type ZXY with one quotation number rather than series of quotation numbers to avoid multiple sets of data. The aim is to verify that the functionality works. With these test data variants, the system executes the script automatically.

For the first location, only one set of test data (i.e., of the reference template) is used. For the second location, two sets of test data (i.e., from the reference template and the first rollout location) are used. For the third rollout location, the first two locations’ test data is used for testing. In this way, test data variants are created in rolling out regression testing.

If any of these integration test cases fail, you must determine if the test data is incorrect or if the local implementation caused changes in existing production scenarios. If the assessment shows the test data is correct and the scenario is still failing, then the current implementation project has affected the successful execution of a live scenario in production. You should make any necessary changes in the current implementation project related to configuration, master data, or development. Once the changes are done, execute the specific regression test cases again. At the end of this regression testing, all the earlier location tests should be verified with successful results.

Sapna N. Modi

Sapna N. Modi has 13+ years of experience in the software industry including SAP software in the areas of solution architecture, consulting, presales, and project management. Sapna has multiple SAP and non-SAP certifications. She is an integral part of the team in setting up the SAP Solution Manager practice at L&T Infotech (www.lntinfotech.com) and has participated in consulting and advisory roles for multiple projects. She has global exposure with experience in the US, Canada, Denmark, Sweden, Germany, the Netherlands, and Kuwait. She is instrumental in and is dedicated to an extreme automation initiative of SAP projects across verticals at L&T Infotech (LTI). Her goal is to accomplish automation-driven efficient operations and to formulate an automation platform for optimized TCO for customers as well as for her organization. Her focus is on innovation to leverage SAP products and non-SAP products involving Robotic Process Automation (RPA), Artificial Intelligence (AI), and Machine Learning (ML) to help customers standardize their portfolio so that it is simplified, automation ready, and able to easily migrate to the SAP S/4HANA platform.

You may contact the author at sapna.modi@lntinfotech.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.