SAP R/3 Testing

September 22, 2007 RENU

SAP R/3 is the market leader in ERP installations & ERP sales. SAP has 1000’s of tables, multiple industry specific solutions, 1000’s of transactions, & connectivity to an unlimited no of legacy systems. Furthermore, SAP can be configured differently from 1 company to another, which creates a myriad of permutations for executing an SAP transaction. Installing & customizing SAP is a daunting challenge. Testing SAP R/3 is in & of itself another intractable challenge. Many projects fail to test SAP correctly & consequently suffer staggering financial loses after deploying SAP into a live envt. The key to maximizing the value & ROI of SAP is to install & customize SAP correctly based on documented reqt’s & to test it extensively based on documented test cases & end-to-end business scenarios.
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. 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.
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. 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 to determine what can actually be recorded and tested with the test tools.
3. Decentralized test teams. Each individual business process team, technical team (ABAP/4), and Basis (security) team conduct their own testing in the absence of a QA/testing team.With decentralized testing each team has the independence and control as to how their particular area will be tested based on their own defined test procedures. The decentralized method suffers from various drawbacks. A more robust approach for testing an ERP system is centralized testing where there is a QA team for defining the standards and procedures for the various testing cycles and documenting the test plan, lessons learned, UAT plan and the test strategy. The test procedures and test strategy include what test case templates will be used, how and what metrics will be reported, how peer reviews will be conducted, ensuring that all test requirements have been met, etc.
4. Working in Silos: Limited or no access to SMEs, Configuration Team. The test manager & PM need to foster an envt of cooperation among testing team & various other SAP teams for successful completion of testing. Since SAP is integrated & a change in 1 of its components can have a cascading effect on other aspects of the software it is often the case where the various SAP teams need to collaborate with one another. But due to internal politics, deadlines, budget constraints, etc this concept is ignored & overlooked. When collaboration falls through the cracks the various SAP teams (configuration, RICE, Basis, testing, infrastructure, data, etc) start working independently in isolation or in a silo.
5. Missing test bed. The test manager should insist on a test environment where the testing team has complete control (for instance control over the accounting periods, running payroll, etc) and where the environment is not shared with other entities in particular during the test execution phase.
6. No ctrls for promoting/transporting objects into production(PTP). To mitigate the risk of transporting objects it is necessary to include approvals and set up a system of workflow where stakeholders from the testing team, Basis team, and configuration leads have input into objects that will be transported into production. A project should set priorities for transporting objects based on their criticality, document and approve objects that get transported after having been tested, and establish the frequency in which objects will be transported (i.e. every Friday at 4:00 pm) to avoid impacting end users as much as possible. Whether a commercial tool is purchased or a home grown application is developed the main objective is to place stringent controls for moving objects into production with the necessary approvals while maintaining a history log.
7. Flaws with BPPs. For those projects adhering to the ASAP SAP methodology BPPs (Business Process Procedures) are artifacts or outputs from the realization phase. BPPs are documented based on stand alone or for single SAP transactions. The BPP provides detailed information in the form of instructions with screen shot print outs for how to execute a given SAP transaction. BPPs can assist a tester or end user on how to execute a given SAP transaction based on the project’s specific customizations. Poorly documented BPPs or outdated BPPs have a propagating effect on the creation of test cases and test scripts. Since BPPs are documented per stand alone SAP transaction, the testing team will need to link multiple BPPs for end to end SAP test cases (i.e. Hire–to–Fire test case) that involve multiple SAP transactions with pre and post conditions. A single poorly written BPP or outdated BPP can inhibit the creation of a test case containing several SAP transactions.
8. Missing peer reviews. Peer reviews help refine work-products and deliverables. Peer reviews also provide independent verification and give the end customers or SMEs an opportunity to provide feedback during the early stages of the SAP implementation. Peer reviews can occur at many junctures during the implementation of SAP
9. Problems obtaining valid test. Most prevalent risk to conducting an SAP test whether it is integration, functional, string, volume, smoke, or security test is obtaining valid SAP test data. Assuming that the testing team has a dedicated test bed or QA box the test manager will need to ensure that all the necessary data (master, transactional, test, etc) is properly loaded as part of the assessment for the test readiness review. Ideally an SAP test will be conducted within a test bed containing data that closely mirrors production data and where the testing environment is production-sized. The test manager should prioritize the test cases that will be executed and determine and document any work-around for test cases that cannot be executed due to missing test data. 10. Missing flow processes, diagrams. Diagramming or modeling how a business scenario will flow within SAP provides invaluable insights to the testing team and the configuration team. 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
11. No integration testing with external . 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 is also critically important to test the integration of SAP with non-SAP systems.
12. Limited security access. 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 imp when conducting +ve & -ve testing for security roles. The testing team shd coordinate & plan with Basis team the necessary roles & permissions for developing test cases & for executing test cases in the designated QA envt or test bed.


Entry Filed under: Computer

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Trackback this post  |  Subscribe to comments via RSS Feed




September 2007
« Aug   Oct »

Most Recent Posts

%d bloggers like this: