Project Detail and Context
This is in context to an implementation of Enhancement Pack 4 and Support Pack 8, where the client had current level of Enhancement Pack 3 and Support Pack 4, thus having quite a lag.
In such a scenario, It is prudent to integrate both the Enhancement Pack and Support Pack implementation together. This will significantly save the Testing efforts since the nature of a Regression and Integration Testing will be same for both. In other words, the same kind of end-to-end Integration and Regression testing to confirm other business processes are not impacted will have to be carried out twice if Enhancement Pack and Support Pack were implemented separately.
Combining them as a single project makes considerable saving on Costs and Project Timelines by saving on Common Resources (Functional and Technical as well as Testing team) and Quality and Regressing Testing Timelines.
Challenges and Strategy
q The level of SP upgrade from 4 to 8 necessitates a high level of testing to ensure all existing functionalities worked as it was and not being impacted by the new upgrade, as well as ensuring new functionality worked as intended. The Enhancement Pack new functionality activation also required similar testing strategy.
q Strategies to keep costs down and shorter timelines are the major considerations in Project Planning for such implementations. Other SAP and Non-SAP interface projects that were simultaneously going on should not have major impact in terms of timeline due to the Support Pack project. This also means less dependency on Business Users/Business Analysts since there are bound to be shortages of them and bandwidth issues since they will be involved in multiple projects within the client.
q To meet these challenges and requirements, new strategies have to be worked out where the following areas are core of the Project Execution-
Ø Leveraging existing Documents Repository for similar projects executed earlier. If there was any fullscale Upgrade project done earlier, then it should be leveraged fully since the Business Processes and Test scripts will be comprehensive and detailed for such projects. Such repositories can be utilized during the Project initiation stage to shortlist Business Processes to be tested during the Support Pack implementation.
Ø Utilizing the prior ECC upgrade repository was to re-use the Test Scripts, thus saving effort on creating Test Scripts
Ø Utilize the SAP Client where the Prior projects such as an ECC upgrade testing was executed so that the results can be compared with the new SAP client where the current project will be executed.
Ø Leveraging Support Team for Business Process Knowledge wherever needed rather than Business Users/Analysts
Ø A detailed and comprehensive Unit Testing Plan and Methodology to make the other project phases a seamless affair
Leveraging earlier ECC Upgrade Repository
The current client had a recent ECC upgrade successfully executed. This repository was utilized to the maximum during the project planning phase. The first step was to identify business processes to be tested during the SP8 implementation. For this, the Business Processes Scenarios that was mapped and segregated module wise during the prior ECC upgrade was taken as a base. This resulted in considerable saving of time and effort since you do not need Client Business Analysts/Users to recreate them.
The list was further shortlisted by applying certain criteria such as-
Remove business processes that were similar and repetitive in nature
Identify processes that were classified as High and Medium based on importance
This short listing was required since the current EP/SP implementation not being on the category of full scale ECC upgrade. Wherein the ECC upgrade Business Process was a comprehensive and more minute in detail wherein every business processes were listed and tested even if they were similar in nature.
Since the repository already had information on the 2nd criteria listed above (segregation on importance wise), you only needed to study the process descriptions etc to check the similar nature ones and identify them. As a result of this exercise, only 60% of the original Business processes were identified to be tested during the current project and sent to Business Analysts for Validation. This approach helped take the project in a high steam forward with ready business processes list to be tested and kept the involvement of Client Business Analysts at a minimum and only during the Validation step. Thus bringing Client delight and confidence in the project team.
The next step was to re-use the Test Scripts of the prior ECC upgrade, which was comprehensive in nature and being prepared and validated with full and active participation from client business Analysts and users during the upgrade, it was a ready reckoner and material to be reused without any changes.
It is also important to analyze and add any new Test Scripts or Business scenarios that were added after the prior ECC upgrade and the current project since they will not be in the upgrade repository. A separate excercise to collate and shortlist these new additions need to be carried out and included as part of the Support pack/Enhancement pack testing. Here again, the Test Scripts that was used for the new processes can be utilized and compared with new results, similar to the strategy earlier thus saving considerable time and effort.
Utilizing the SAP Client of Prior ECC upgrade
Another Strategy was to utilize the SAP Client where the Prior ECC upgrade testing was executed so that the results can be compared with the new SAP client where the current project will be executed.
The new SAP client was made as a Copy of this earlier ECC upgrade client. Since the documents and Master Data created and listed in the Test Scripts still existed in the prior upgrade client, the effort to create new Master Data was eliminated in the new client.
Another advantage was that the results in the new client can be compared to the results in the earlier client since the same Test Scripts and same master data were used, and that basically means the results should be the same in both systems (meaning the results should be as it was mentioned in the Test Script). Any deviation on this can be identified as potential Support Pack related issue and analyzed further.
For example, if we execute a Test Script named ‘P.O. Process for Wal-Mart’ where the results and documents that were created during the prior ECC upgrade was already available in the script. Now as part of the new project, we will execute the same Testscript and generate new document numbers using the same master data mentioned in the Test script. But if one of the desired result in the script is an idoc to be triggered when you save the P.O., and if this was not observed in the new document that was created, then the result is not as desired and a technical analysis is required.
Similar strategy for Print Outputs were followed where the layout and print preview were compared with the earlier document mentioned in the Test Script. The approach that was followed was to first start with the Output Types that are most frequently used, and to check for two most prominent things-
Data printouts such as Sales Org/Sold-to/Payer/Material number, Qty, Unit & Amount
Layout changes such as number of pages/additional data appearing or missing/Misplacement in alignment etc.
Issue Resolution Approach and Examples
It was during one of such result comparison with prior ECC Test Script results, that a major SP8 related issue was identified. A Blank page was observed in one of the print outputs and though it looked normal, was not present in the prior document output layout that was created in the earlier test document mentioned in the Test Script. On further analysis it was found that the Support Pack8 had a flaw where logic around Zero value for SapScript was not working. Thus the print program was printing Net Values that were Zero values whereas it should not be printing. This resulted in the number of lines being printed increasing and pushing an extra page down. This shows that even a simple harmless observation such as a blank page can turn out to be a major issue and should not be ignored.
During the Customs Reports testing phase, few reports were found to cause ABAP errors and was found to be due to changes by Support Pack. One example is that a report gave an ABAP dump and it was found that it was calling an include ‘MGVTC_SAPMM61R’ which was not present in the new system.
When such issues were identified, the first approach was to have a technical analysis before approaching the Support Team or Business Analysts. Normally issues such as Outputs not being triggered or Idocs in error status were noticed and rectified as Support Pack related.
There were also other issues where results differed or the testing team could not proceed on the steps where the Support Team were utilized to give insight into the business processes and proceed further. These issues relate to correct master data setups such as entries being maintained in Custom Tables or a small change in the processes itself.
The approaches mentioned above resulted in keeping the Business Analyst and business user’s involvement at a minimum and not always involved during validation of results, thus freeing up resources to be available in other projects, resulting in timelines of other simultaneous projects not being adversely impacted due to a Single project.
Unit Testing Phases
In order to have a flawless and foolproof Testing Strategy, the Unit Testing Phase was broken down into four different sub-phases as mentioned below, with each phase being detailed and exhaustive enough with timelines.
Detailed Unit Testing Plan
The 1st Phase was focused on checking the basic transactions after the technical upgrade and SPAU/SPDD activities were completed. This means that the technical objects that were fixed as part of the SPAU/SPDD activities were working as expected and that the basic SAP system was working. The best way here is to shortlist some 20 most common used transactions for each module and execute them. It may involve creating a basic Sales Order or PO cycle and posting simple FI document without going into data verification. The focus during this phase is to lookout for any technical issues such as Screen displacement or ABAP dumps being encountered.
If any of these issues are encountered, then a technical analysis should be done to root cause and fix the program. These might be result of issues during SPAU/SPDD activity or any Notes that were needed to be applied as a follow on to the Enhancement or Support Pack.
After these transactions are run and issues fixed, the SAP system is working in the new upgraded system and is ready for further detail testing.
The 2nd phase involves executing all basic end to end business processes across all modules to check if the business processes are running as expected and is not impacted by the new upgrade system. You should avoid interface scenarios and focus more on the core SAP end to end business processes.
After the 1st phase and 2nd phase being successfully completed, it can be interpreted as the Core SAP system and processes are stable.
The 3rd phase involves executing interface scenarios. This can be both string testing and full end to end business process that has interface components. For example, web orders can be sent in to SAP and Idocs inducted, and invoiced till data is sent to other systems such as BW. This phase will identify any issues related to interface failures such as due to Idoc segments being increased in the new upgrade system. Technical solutions such as idoc re-generation will need to be done and should be identified for Cutover activity.
The 4th and final phase involved executing Custom Reports and other T.codes that were not part of the main business processes that were tested in the Test Scripts. Since the list of Custom Reports will be huge in numbers in any client, the strategy here is to break down the list into Categories on Importance wise. Here also, earlier similar projects repository or the prior ECC upgrade list can be utilized. In addition, new t.codes that was added afterwards were listed out and included in the testing plan. The important ones were executed first, focusing more on technical observations such as ABAP dumps or any other Errors, than on actual validation of results of the report output. The list being exhaustive and in hundreds, it is practically not feasible to incorporate a testing plan of result validation of such custom reports. Rather the focus should be to remove any erros in report execution as part of the Support Pack implementation.
It was during such a test that errors mentioned in earlier section, was found to be due to changes by Support Pack.
A second step in Custom Reports testing is to segregate the ones that generated no outputs even with multiple input parameter and combinations. These need to be rechecked in Quality system and if still no outputs are determined, then a technical analysis should be done to root cause. Even at this stage no business user interference is required since a technical analysis will be able to bring out the reason for no data being fetched by the program.
This multi-step approach will ensure that all Custom Programs will run and produce outputs without any technical errors post Go-Live. Business user validations can be done for a shortlisted list of Reports based on how critical the reports are from Business perspective.
Major Issues of Support Pack 8 implementation-
Below is a list of few shortlisted issues during the Support Pack Implementation that can be used as reference for similar implementation projects:
Issue Category | Description | Remedy or Suggested Steps |
Program RV80HGEN | Due to SP8, changes were included in program LV45C400, and need to be activated | Execute the Program RV80HGEN in all landscape |
Idoc New Segments | there are 13 additional fields in each segment E1BPCATS1 and E1BPCATS2 | regenerate Idoc |
Basic type ORDERS05 Idoc | segment E1EDP19 has maximum number of entries increased | As per OSS note 370021 execute the program ZE1EDP19 to increase the number of entries in segment E1EDP19 |
Include | The include ‘MGVTC_SAPMM61R’ of the program ‘SAPMYPMRD_M61R’ is not present. | Comment the include |
Change Pointers | Changes in change pointers to table BDCP2 from BDCPV | As per SAP Note 1165059, run program RBDCPMIG_ALL_WITHOUT_MIG_FLAG for all message types to replace table BDCPV to BDCP2 |
EP4 T&E module | If you are using Offline T&E, some issues likely to be encountered such as file download giving ABAP dump | Program fixes may be needed |
SAPScript | SAPScript having logic failure for 'Zero' value, resulting in printing of Zero values in the output | Implement OSS notes 1491259 |
Pricing routine | PO number is no longer available in KOMP (AUBEL) for intercompany STOs. | Logic change in pricing routine needed |
WBS elements Master data | WBS elements Master data have the fields Priority (field PRPS_PSPRI) and User Defined Field EPM/PM (field PRPS_USR00) defaulted to’ X’ values | This is due to a code change introduced as part of SAP note - 1333564. Apply correction note - 1467435. |
COPA Values | COPA reports and documents may not get generated (for STOs). This is because the approach is being changed from code-driven approach to a table-driven approach for updating the COPA tables during Goods movement. | You will need to maintain entries in table TKE_BUS_TRANS |
Customer Master | Multiple email addresses cannot be entered in Customer Master field for Clerk’s Internet address (field KNB1- INTAD) which is in the Company Code -> Correspondence tab | If you are using this field, change of logic is required or email addresses can be separated by space |
- SAP Managed Tags:
