on BPPs which makes it difficult to discern whether a BPP is finalized, completed, peer-reviewed or still undergoing changes.
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 for tasks such as filling out CI (Customer Input) templates, drafting test cases, creating functional design specs, development of business process flow diagrams, documenting BPPs, code walk-through, etc.
Inexplicably many SAP projects do not engage in the practice of peer reviews or have any templates or forms for documenting peer review feedback. The end result is that often times the end users have complaints about the quality of test cases during the UAT (User’s Acceptance Test) and about how a particular process was customized in SAP versus how the process was previously executed in the end user’s legacy systems.
Test managers should solicit the feedback, input and even the sign-off from the SMEs for the various testing artifacts as soon as possible or as the testing artifacts are produced. It is in the best interests of the test team to identify problems with the testing artifacts as soon as possible as opposed to weeks before the SAP cut-over or SAP go-live dates.
9. Problems obtaining valid test data
Arguably, the 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.
When dealing with SAP data invariable one or more of the questions below will arise before a testing cycle ensues:
Where will the test data come from? How will one produce new data for transactions that require unique data? How will the data be loaded into a new SAP client and instance? What happens when an interface or conversion needs to send data into core SAP R/3 from a legacy system and the interface or conversion is not executing properly or has yet to be developed? What happens when the transactional data has not been created?
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. Diagrams and flow processes can illustrate the lifecycle, stages, sequences, activities, states and events associated with a particular business process. Unfortunately, many projects undergoing an SAP implementation or SAP upgrade fail to diagram their business processes leaving testers or