to determine what can actually be recorded and tested with the test tools. The company should further investigate with the vendor what additional benefits over CATT (eCATT) the automated test tools provide. The objective is to get the test tools that will maximize SAP recording.
3. Decentralized test teams
Some projects that I have consulted for, have a decentralized testing approach where 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.
The decentralized method suffers from various drawbacks including redundancy, inconsistency, lack of standards, missing testing metrics, unreported test results, limited managerial visibility, limited test coverage, chaotic defect resolution, no independent verification of test results, etc.
Projects with a decentralized test approach perceive control as a significant advantage of decentralized testing. 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 perceived benefits from decentralized testing do not offset its 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. In addition to the QA team under the centralized model the testing team provides expertise for executing test cases whether manually or with automated test tools. The testing team also provides independent verification for the test results since the testers were not associated with the configuration of the transactions, workflow development, creation of user roles, or the development of the RICE (Reports, Interfaces, Conversions, and Enhancements) objects, etc.
4. Working in Silos: Limited or no access to SMEs, Configuration Team
Since SAP is integrated and a change in one 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.
This concept seems mundane and at first hand easy to grasp. But due to internal politics, deadlines, budget constraints, etc this concept is ignored and 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.
I have been in projects where the testing team members who arrived during the middle of the realization phase have been unable to get support from the SAP configuration team members and SMEs for drafting test cases, peer reviews, and sign offs.. In other projects the QA and testing team are almost considered a “bother”, “nuisance” to the other SAP teams.
The test manager and PM need to foster an environment of cooperation among the testing team and the various other SAP teams for the successful completion of testing artifacts and testing cycles.
5. Missing test bed
Within the SAP client landscape a dedicated QA environment should be allocated to the testing team for the various testing phases. The environment should be production sized, and contain production like data, have a stable baseline, and frozen configuration by the time the testing cycles commence.
What I have seen at many projects is a so-called “dedicated testing environment” that many SAP teams have access to for training, last minute configuration, etc during the middle of a testing cycle. This creates conflict