Lessons Learned from Testing SAP R/3

[article]
Member Submitted
Summary:
Are you in the midst of an SAP R/3 upgrade or implementing SAP R/3 from scratch? Are you prepared to perform all the activities and tasks that are concomitant with the various SAP testing phases? The author identifies testing risks and shares lessons learned from testing SAP R/3. The author provides insights and recommendations for avoiding these testing risks that could halt SAP testing efforts and consequently delay the expected deployment of SAP into a live production environment. The insights range from documenting test cases to working with testing artifacts from the ASAP methodology.

SAP R/3 is the market leader in ERP installations and ERP sales. SAP has thousands of tables, multiple industry specific solutions, thousands of transactions, and connectivity to an unlimited number of legacy systems. Furthermore SAP can be configured differently from one company to another which creates a myriad of permutations for executing an SAP transaction. Installing and customizing SAP is a daunting challenge. Testing SAP R/3 is in and of itself another intractable challenge.

Many projects fail to test SAP correctly and consequently suffer staggering financial loses after deploying SAP into a live environment. The key to maximizing the value and ROI of SAP is to install and customize SAP correctly based on the documented requirements and to test it extensively based on the documented test cases and end-to-end business scenarios. Below some lessons learned are offered and identified to help organizations test SAP.

1. Not following methodology or No methodology at all
Some companies implementing SAP adhere to the ASAP methodology. Other companies have ad-hoc or ASAP-like methodologies for implementing SAP.

Even companies that are supposedly implementing SAP based on the ASAP methodology are not very strict and stringent in adhering to all the activities, deliverables, and tasks associated with ASAP. Consequently, but not surprisingly these companies have much confusion, obfuscation, befuddlement when they attempt to implement SAP. Compounding this problem is the fact that many large companies implementing SAP hire two or more implementation partners and multiple subcontractors that have incompatible approaches, methodologies, and lessons learned for implementing SAP.

The project manager and the steering committee should specify within the project charter how SAP will be implemented and what deliverables will be produced based on either ASAP or some other proprietary methodology. The objective is to have defined, proven, and repeatable processes for implementing SAP and that the project members have the knowledge or know-how for adhering to the methodology. The creation of an audit team or standards team would be helpful in enforcing compliance with the chosen methodology.

2. Inadequate test tools
SAP R/3 comes with an internal recording tool known as CATT (eCATT). One of the advantages of CATT (eCATT) is that since it is part of the standard SAP system it's free of charge. However CATT does have some limitations which impel many companies to procure other test tools.

There are many vendors offering commercial automated test tools and test management tools for testing SAP. Companies purchasing automated test tools expect and erroneously believe that the test tools will be the panacea to their entire SAP recording and testing needs. Unfortunately, this is not the case, since no two SAP implementations are exactly the same across two or more companies or at times even within different divisions of the same company. Consequently, a company implementing SAP might need to procure test tools from more than one vendor in addition to the CATT (eCATT) tool.

An SAP implementation could be implementing SAP add-ons such as BW (Business Warehouse), APO (Advanced Planning Optimization), SEM (Strategic Enterprise Management) or even modules such as PS (Project Systems) that generate graphs and charts that a recording tool does not recognize. Furthermore, a company may move its SAP GUI from the desktop (fat client) to running SAP as web-based (thin client) or through an emulated Citrix session which could render the existing test tools useless.

Companies that wish to move to an automated testing strategy should articulate and document what SAP modules and SAP add-ons they are installing in addition to any legacy applications integrating with SAP. This information should be provided to the vendors of automated test tools in order

Pages

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!

Upcoming Events

May 04
May 04
May 04
Jun 01