For someone new to SAP testing, there are often questions about the best approach to take, and from which industry best practices the tester should take their cues. As it turns out, there is no panacea in the arena of SAP testing. Depending on the nature of the project and the preference of the individual testers, there are multiple ways to tackle SAP testing. This article seeks to provide two examples by describing the experiences of a pair of our testers working on a large SAP project, and on-boarding testers who are new to SAP testing with our clients in BC.
Paul’s Experience:
I’ve been working on a project for a client involving an application on Windows and Android. The application guides the user through business-specific workflows as part of a larger process. Both the start and the end of the workflow involve many instances of interfacing with SAP. The challenge my team has recently had to address was having multiple new members join the team in a short time, all with no SAP experience whatsoever. I only had minimal experience on the client’s SAP system myself.
There is no getting around the fact that, for a new user, SAP is not intuitive. On top of that, this version was heavily customized to meet particular business needs. With testing already in full swing, we didn’t have the luxury of a ramp-up period for training. To ensure the new testers could contribute effectively, and as quickly as possible, we began by identifying the systems and processes that they would use most frequently.
Once these areas were identified, SAP experts from the client transferred their knowledge through hands-on training sessions. Rather than just reading documentation, the new testers worked through examples on their computers. This practical experience gave them the chance to see the system in action, with access to immediate help for any questions. In between training sessions, the testers were given exercises to help keep the material fresh and encourage learning through practice and repetition.
With so much of the business knowledge undocumented and in the heads of various long-time employees, I’m finding it very helpful to have testers who are not afraid to ask questions. The learning curve of SAP is fairly steep; gaining the required knowledge won’t come from keeping your head down at your desk. It is crucial to not only ask questions about SAP, but also about how it fits into the business as a whole. Asking questions about this bigger picture will ensure that as tests are developed and executed, the test data will reflect the real-world scenarios in which the software is used.
Jackson’s Experience:
System Interfaces Diagram
When I was facing the plethora of data combinations in SAP, I took a different testing path. My ‘structural’ approach emphasizes an early understanding of the framework of the SAP environment, and the associated application domains, in preparation for detailed component/system testing. This encompasses several steps. Using the client system as an example, I first gathered information from documents and training material provided by in-house SAP staff on the relationships among the three main components: SAP, a browser application, and a Windows/Android application. Then, I drew an overall schematic diagram of the key subsystems and components, including the interactions/dependencies between them (see Figure 1). Next, I prepared a generic workflow diagram of the lifecycle of a work order (see Figure 2). Based on that diagram, I indicated the most typical user scenarios to optimize test coverage (see Figure 3).
Workflow Diagram User Scenarios Diagram
With the above procedure established, I focused on the SAP part of the system. I identified the interfaces of SAP with the other two applications, especially where data is first created and stored in SAP, and where it passes to the applications for subsequent usage. Then, I confirmed the data destination (various fields in SAP) where data on the return path (created by either application) is relayed back to SAP after a work order is processed.
Common SAP Codes Diagram
In the course of traversing between the SAP and application worlds, I documented the usage of a handful of commonly used transaction (command) codes (see Figure 4). The transaction codes are based on particular input criteria (e.g. work order number), and bring up the desired screen where target information is located. My artifacts in this journey include a “How-To” Guide and diagram(s) to help the user prepare and check data for testing purposes. An example of inclusion of a transaction code diagram is an SAP standard transaction code IW33, which, with the work order number as input, displays a screen showing details of the work order. The “How-To” Guide depicts, to appropriate granularity, the procedures on how a user can navigate the layers of screens to get to the desired value.
With the overall infrastructure in mind, as well as the above-mentioned ‘self-made tools’ at my disposal, I was then able to execute individual test cases, dive into related details, and explore specific scenarios that involve different workflows and data preparation or manipulation.
Conclusion:
It may seem that these two testers’ accounts are separate approaches, but they are, in fact, quite complementary to each other. The ‘Structural’ method gives the tester a sound background of the overall system, while the ‘User scenario’ route focuses on verifying specific test scenarios. The tester can use, as they deem appropriate, a hybrid of the two depending on various factors; among them are the tester’s familiarity with the application and the stage of the project i.e. whether the tester is testing at the beginning, middle or end of the project. From the training perspective, gaining a good idea of where SAP fits in the full picture, followed by zooming in on a particular test objective, allows the tester to learn to test SAP systems effectively and efficiently, as they march along with the project.