Lessons Learned from Testing SAP R/3

[article]
Member Submitted

newly hired resources in a bind to comprehend how legacy processes, or new customizations derived from gap analysis will be executed within SAP. SAP testers and end users participating in the user’s acceptance test should have access to diagrams depicting how business processes flow within SAP. The absence of such diagrams puts undue burden on the testing team and places the end users in a position of disadvantage.

The SAP business analysts in conjunction with the SAP configuration team, and possibly the SMEs (Subject Matter Experts) can develop diagrams in tools such as Visio, or the ARIS modeling tool that integrates and links with SAP’s Q&adb (Question and answer database) for those SAP implementations following the ASAP methodology. Alternatively, with Rational’s tools one can develop UML (Unified Modeling Language) diagrams to illustrate processes with interaction diagrams (sequence and activity diagrams).

11. No integration testing with external components
SAP integrates with many legacy systems via interfaces, IDOCs, conversions, BAPIs, connectors, or even middle ware such as Mercator. SAP can even be integrated with other commercial ERP systems, forecasting/planning systems, and CRM applications.

Although, the integration of SAP with other systems is critical to the successful implementation and deployment of SAP, many companies merely test during the integration test the interaction of SAP among its various modules and add-ons. Although the aforementioned type of integration testing is necessary it is also critically important to test the integration of SAP with non-SAP systems.

Some examples of integration testing that I have conducted between SAP and non-SAP systems are: SAP integrating via IDOCs to bar coding software, SAP properly sending outbound data to legacy system and the legacy system processing the data correctly, end to end financial reconciliations between SAP and data warehouses, integration between SAP and planning systems for MRP runs, etc.

12. Limited security access
I have seen SAP testing efforts come to a halt because the testers did not have the necessary privileges and permissions to execute certain SAP transactions or the necessary roles to submit electronic approvals. This problem is exacerbated when testers are executing test cases at odd hours or during weekend hours and there is no Basis support to augment the tester’s security role.

Successful execution of certain test cases in SAP whether manually or with automated test tools will require the test team members to have super user access. This is of utmost importance when conducting positive and negative testing for security roles. The testing team should coordinate and plan with the Basis team the necessary roles and permissions for developing test cases and for executing test cases in the designated QA environment or test bed.

Conclusion: Document these lessons learned as part of your test plan to mitigate the risk of repeating these blunders in your SAP installations.

User Comments

1 comment
Michael Bolton's picture
Michael Bolton

Thank you for the comment, David. And I agree with yours.

Cheers,

---Michael B.

February 1, 2013 - 12:37pm

About the author

Jose Fajardo's picture Jose Fajardo

Jose Fajardo (PMP, M.S., and SAP certified) has worked as a test manager for various companies utilizing automated testing tools. He has written and published numerous articles on testing SAP and authored the book titled Testing SAP R/3: A Manager's Step by Step Guide. Throughout his career Jose has helped to create testing standards and test plans, mentor junior programmers, audit testing results, implement automated testing strategies, and managed test teams. Jose can be contacted at josefajardo@hotmail.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!