INDUSTRY

Retail

PROJECT

Performance testing for a retail client using LoadRunner SAP GUI for Materials Management and Sales & Distribution SAP modules

SYNOPSIS

Using LoadRunner SAP GUI

Background

Our most recent SAP engagement covered both Materials Management and Sales & Distribution modules. The prime requirement being within the warehouse to monitor the performance of product picking (RF gun) through to dispatch and from day-to-day levels to the peaks anticipated in the ramp up to Christmas and Black Friday. A 10k VU day LoadRunner license was procured for this engagement.

Challenges

As with any performance test, the challenges were multiple, some of the more notable highlights are detailed below:

  • To send goods out you must have received them in - yes, a very obvious statement, but with significant implications. The initial plan to create and restore a database snapshot of a fully stocked warehouse was not possible due to access to both systems and client personnel. The only option was therefore to script the purchase (Inbound) transactions required to keep the warehouse stock levels high enough to perform the performance test (Outbound) transactions.
  • Customer time was at a premium; ‘walk through’ of the business processes was brief and only covered a single path.
  • Barcode reader (/SCWM/RFUI) is prone to ‘lock’ devices if all of the transactions within a task are not completed.
  • Great care had to be taken to ensure that the virtual users did not attempt to process the same individual item during either the Inbound or Outbound transactions, a user/ data strategy was required.
  • The Performance testers did not have exclusive use of the test system, leading to both missing and unexpected data and alternative process flows.

Solution

  • LoadRunner Professional – SAP GUI Protocol
  • Eight performance test scripts were created. Four to bring stock into the warehouse and four to ship stock out. The Inbound process scripts were run as part of the overall test scenario effectively harvesting data and creating warehouse stock for subsequent executions.
  • Due to the volume of data and datafiles (effectively one per virtual user) excel macros were developed to sanitise and evenly distribute data between virtual users

                                     Inbound Process                                                              Outbound Process

                                    o    Create purchase order                                                                            o    Create sales order (SAP EDI)

                                    o    Create inbound delivery                                                                        o    Picking wave release

                                    o    Goods receipting                                                                                        o    Picking

                                    o    Goods put away                                                                                          o    Packing & close carton.

  • The scripting for each business process had to be extended to cover the multiple path options discovered within each process.
  • Scripting for the Bar code reader (/SCWM/RFUI) was enhanced to detect a ‘locked’ device and intelligently attempt to release it by following one of many pre-determined processes. Any devices that could not be released were removed from the current execution.
  • Custom data handling was created to ensure that only one single virtual user could use one item data at any one time and that the data was not re-used during the current and any subsequent executions. 
  • Scripting for picking and packing was developed to seamlessly manage the five process paths covered within the scope of the performance test. The scripts switching switched their path according to the data presented on the SAP GUI screen. The scripts were also developed to process or reject data created by other users on the test system.

Outcome

  • Executing test scripts for both Inbound and Outbound processes created a more realistic performance test scenario. Test scenarios were created and executed to achieve a peak load of 250 users for 1 & 2 hours.
  • Initial executions highlighted a peak in response times for the stock picking process when the system was processing a stock wave release.
  • The customer tweaked their test systems load balancing algorithm and the peak was not detected in subsequent executions.
  • The algorithm changes were implemented in Production
  • Budget permitting, the customer is looking to extend the performance test to cover additional Outbound warehouse processes.

This example demonstrates 

  • Our ability to understand the customer’s implementation and customisation of the SAP modules and processes. Creating a series of test scripts to execute against SAP GUI is a relatively simple exercise, enabling the scripts to be resilient and intelligent to manage the alternate flows possible within a business process requires both advanced scripting capability and understanding of the SAP module and the customers implementation.
  • Understanding how, what and when data is created and consumed within and between SAP modules is critical to the execution of a meaningful performance test.
  • Over the years, Testing Performance have engaged in many SAP testing projects (functional & performance), employing both SAP eCATT and proprietary test tools, from what was Compuware’s TestPartner (as an alternative to and integrating with eCATT) to most recently Micro Focus’ LoadRunner SAP GUI. We have accrued excellent working knowledge of the core modules, from Financials through to Sales, HR and Product Planning.