Overcoming Testing Challenges in SAP Upgrade Projects - Page 2

Deepak Kumar

Testing in SAP Development System

In the upgraded and unicoded SAP development system, no major testing activities are planned as it does not have the robust data to support the testing and is not fully linked to the legacy systems. In most of the organization, the SAP development system is not or is infrequently refreshed from the SAP production system. The technical testing of the custom tools that are used by the development and the authorization team is performed. This is because these tools are present only in the SAP development system.

Testing in SAP Quality System

The bulk of the testing activities in an upgrade project are performed in the SAP quality system in the 'realization phase' of the project. The upgraded and unicoded SAP Quality System is created from a copy of the SAP Production system and corrections so far from the upgraded and unicoded SAP development system are applied to it through transports.

The testing scope preparation poses the challenge to limit it to a manageable scope that should be completed in the allocated time and within planned effort. The 'Risk Based Testing Approach' should be applied to meet this challenge.

Risk-Based Testing Approach

The SAP upgrade project objective is to deliver the stable system to the business. One way to achieve this is to test the complete set of business processes and the underlying test scripts. This would mean increase in effort, cost and duration to finish the testing. Limited functional resources in the organization complicate the situation, as the current SAP Production system (old version) would also require support from them.

Another approach is to test the reduced or limited scope and still deliver a stable system to the business with the additional benefit of reducing the overall total cost of the project. This is called the 'Risk-based Testing Approach." This means that the focus should be on prioritizing and testing the tasks and functions that are important to the functioning of the business solution. The following form the important points to prepare the scope:

  • Frequently used business process steps and underlying transactions
  • Critical rated business transactions where failure is unacceptable
  • Technically complex transaction or business process steps
  • Regulatory requirements
  • All interfaces
  • Important printouts sent to outside entities including customers
  • Authorization testing
  • Include impacted developments (functional changes in existing objects due to upgrade)
  • Other priorities that may differ from organization to organization -- GxP scripts, etc.

The testing scope is based on the prioritization factors as listed above and brings the benefits of manageable scope, streamlines functional efforts and reduced project timeline. It is possible that new risks may emerge during the testing. Project management and functional teams should address the same and stay on the course to finish the testing as per plan.

It is assumed in the 'Risk-based Testing Approach' that since critical features would be tested, the upgraded SAP system would be stable enough to enable the functioning of the organization with low or minimum impact. The rest of the issues (low risk) would be dealt with by the project team either before go-live or in the post go-live support / hypercare phase and would be solved in a short span of time.

Additionally, during the quality testing of the project, it is beneficial to invite the business users for 2-3 days and request them to perform day-to-day business transactions. Any issues reported would be fixed by the project team in this duration. This will further reinforce the fact that day-to-day transactions are working as expected in the new upgraded and unicoded SAP system. This not only helps to get the business feedback early in the project cycle about the new system when there is sufficient time to react to the feedback in terms of corrective actions, it also helps to smooth the buy-in of the new system.

Another way to manage the testing scope in the SAP Quality system is to distribute some of the scope to be executed in Screening mode -- without documenting the test results formally in the test scripts. Such scope is managed and tracked through Excel lists. It gives more time to functional teams to focus on testing and making sure that scenarios and transactions are working successfully without spending too much time on documentation. 

  • Tip: Prepare the complete list of interfaces and printouts early in the blueprint phase. This helps to have the sufficient time to establish the connectivity of partner systems with the upgraded and unicoded SAP quality system.
  • Tip: Prepare the scope of testing by the end of the blueprint phase. This is a time-consuming activity and follows iterative steps. Revise it based on the result of sandbox testing, if required. Testing scope check should be done with respect to the planned testing duration.

Performance Testing

The stress or performance testing may not be required as the new upgraded SAP system will be of the same hardware specifications as the non-upgraded one. The user base and the system usage by the business would stay the same as it was before the upgrade. It is recommended to size the new hardware for the new upgraded SAP system with more (say 25 percent) processing power to offset any upgrade-induced slowness and subsequent deployment of new functionalities that the new system may bring in. Performance testing is a time-consuming activity and its necessity should be evaluated by project management.

Connectivity Testing

Since the new production SAP system would be based on the new hardware, it is beneficial to test the Interface connectivity for the few selected interfaces. Connectivity testing is performed by the project team and highlights any potential issues that might be there when interface connectivity is maintained on the upgraded and unicoded SAP Production system. This helps to change the IP address, host name, etc. to the one corresponding to new hardware. It is advisable to use the alias name in the connectivity setting details of the interfaces, which makes it independent of the IP addresses of the hardware.

 User Acceptance Testing

User Acceptance Testing will be performed in the SAP quality system after the completion of the quality testing and corresponding issue resolutions by the project team. At this point, all interfaces are connected and critical business processes are tested to be working as expected. Business users perform their day-to-day tasks and activities in the SAP system. Issues reported are fixed by the project team. Since this activity is one or two weeks before go-live, certain low-risk issues may be marked to be fixed in the post go-live phase. This helps the project team to focus on cutover and go-live activities.


It is important that testing of the upgraded and unicoded SAP system is planned diligently, and relevant measures are taken to manage the scope, functional effort and project timeline. Representative sandbox testing indicates the quantum nature of upgrade issues and provides early information on upgraded and unicoded SAP system behavior. It also gives the project team enough reaction time for relevant corrective actions. The test approach should be suitably modified in light of the results from the sandbox testing, as initially the impact of upgrade and unicode may not be known in definite terms on the SAP system. The testing scope and effort in the upgraded and unicoded SAP Quality system can be effectively managed using the 'Risk Based Testing Approach.' This will help project management to deliver a stable SAP Production system within the budget and timeline.

Add Comment      Leave a comment on this blog post

Post a comment





(Maximum characters: 1200). You have 1200 characters left.




Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.