- Overview: What's a Mix?
- Real-World Low-Level Technology Stack Test Input and Mixes
- Testing and Tuning for Daily System Loads
- Testing and Tuning for Business Peaks
- Identifying Key Transactions and Business Processes
- Real-World Access Method Limitations
- Best Practices for Assembling Test Packages
- SAP Component and Other Cross-Application Test Mix Challenges
- Tools and Approaches
This chapter is from the book
This chapter is from the book
This chapter is from the book
9.6 Real-World Access Method Limitations
Although I've focused on test mixes from an application or low-level technology stack perspective thus far, another area that needs to be considered relates to the front-end SAP client. SAP offers a number of access methods or alternatives: the classic SAPGUI, which is available for a number of "desktop" platforms is the most prevalent, of course, followed by the HTML-based WebGUI and the newer JavaGUI. Generally speaking, though, the following challenges relevant to input mixes and access methods apply across the board:
-
Not all test tools support all front-end client interfaces. Thus, test input quickly becomes a moot point if your goal is to perform virtual multiuser SAPGUI-driven testing but the available tool does not support the SAPGUI. The same holds true if you wish to leverage the WebGUI, but your preferred tool is incapable of driving Web-based content.
-
Similar to the previous point, the specific development tool and mySAP component-specific SAPGUI snap-in may or may not be supported by a particular testing tool.
-
Not all business transactions are supported by all user interfaces, especially those outside of the classic SAPGUI. This is not nearly the problem today as it has been in the past, where a small percentage of a business's key transactions simply could not be executed via the WebGUI (because of the absence of HTML-based transaction equivalents of the standard RFC-based transactional data and screens).
-
Not all access methods are hosted directly by a client PC or laptop. For instance, a number of my larger SAP accounts have standardized on Citrix MetaFrame solutions for hosting and controlling the SAPGUI. Although the benefits are huge in terms of standardization, lower desktop software upgrade and maintenance costs (it costs an average of $40 for IT just to "touch" a user's PC—that is, to upgrade the SAPGUI), and extending a user community's PC lifecycle, the costs to replicate the necessary Citrix server infrastructure in a test environment can be prohibitive.
-
Not all functionality is available on particular releases of the SAPGUI. For example, only the latest SAPGUI releases support some of the newest business and Basis transactions. And, even previously, the use of OCX controls and other GUI features were only supported on the SAPGUI releases provided after the "EnjoySAP" initiative.
The lesson here should be clear—take the time up front to determine how well your goals and success criteria affect the technology stack that is being tested. And then perform some basic front-end testing to ensure that what you envision is indeed possible with the tools, time, and expertise you have available.
9.6.1 Other Front-End Components and Interfaces
Front-end user interfaces outside of those previously discussed can come into play as well. The SAPGUI snap-ins mentioned earlier may or may not be supported by your favorite virtual testing tool, for instance. In fact, the interface you need to use in support of a specific TU may be completely foreign to SAP. Compuware's TestPartner is a good example of a tool that can prove helpful in these cases—not only is it a great WebGUI test tool but it also allows you to test a variety of user interfaces outside of those dependent on Internet Explorer or similar Web interfaces.
In these cases it is important to look beyond what is perceived as immediate front-end needs, and instead take a quick look at alternatives. Perhaps your testing can be driven without the need for a GUI—SAP eCATT can "talk" directly with SAP behind the scenes; or maybe part of the access-enabling technology that sits in front of your SAP system represents an unnecessary stumbling block, something in the way of your testing goals. If you need to test the online user load your R/3 system can handle, but EP represents the primary access vehicle to R/3, perhaps it's not absolutely necessary to keep EP in the testing loop, so to speak. In other words, to make things simpler you might consider forgoing the inclusion of EP into the solution stack to be tested back in the lab, and use the simpler direct method of access allowed by virtual SAPGUI connections. In this case, you won't be in a position to test the ability that your particular system has to support single sign-on (SSO), nor will you be able to validate any high-availability or other performance or scalability metrics. The same limitations hold true for SAP's older portal product, Workplace, as well as other legacy tools and utilities that help make SAP system access possible. Bottom line, though, if your goals don't require it, you can make your test infrastructure and test runs that much simpler by keeping only the infrastructure and components necessary to meet your test's goals or success criteria in scope.