We’ve heard the same story over and over. Companies are using HP UFT for testing and they’re tired of spending countless hours updating and maintaining test scripts. On top of that, they’re not even getting high levels of automation coverage. Regardless of the time and money you’ve dumped into UFT, you can get out now! Let us explain. Automated testing script languages require specialized programming skills, and the more code that is created, the greater the time and effort needed to keep pace with changes.
It can of course be argued that being code‐based doesn’t matter if you never see the code. The problem here is that no two SAP implementations are the same, no two SAP versions are identical, and any time changes are introduced, either by a user or SAP, the script code itself must also be changed.
If you’re writing programs to test programs, you can end up with defects. In this case, you can end up constantly chasing and fixing those scripts to get the coverage you need.
Case 1 – SAP Customizations
In the most obvious case, an SAP customer may implement customizations in the form of Z‐ transactions to accommodate special requirements. Because there are no predeveloped business components, they must be developed from scratch. While it may seem that the keyword interface to UFT simplifies this task, the code that is generated is strictly limited to linear, simplistic actions. Any sophisticated decision‐making or error‐handling functionality must be created as code by a programmer, in the expert view. And, naturally, this code must be tested and debugged, just as any other code must be before it can be made available as a reusable business component.
Case 2 – Configuration Changes to Standard Business Processes
Case 2 arises when the SAP customer introduces any configuration changes that modify the standard business process procedures in any way. Many enterprises deliver competitive differentiation through specialized business processes. It is even possible to patent unique processes, such as the Amazon One‐Click ordering technique. No doubt that a large degree of SAP’s success can be traced to their ability to enable customization of business processes without the development of custom code.
Since this very flexibility is a strength of SAP’s design, it is not only common, but is expected. With HP UFT, the predeveloped script code must be modified by a programmer to reflect any configuration changes, and these changes also must be tested and debugged.
Case 3 – SAP Feature Updates
The third case, which is not only inevitable but is often the driver for most test efforts, is that SAP will introduce new capabilities in the form of new releases or modules. When this occurs, it may require not only new components to be developed from scratch, but also any existing components to be modified, tested, and debugged.
Case 4 – Non-SAP Application Integrations
Case 4 is perhaps the most severe case. It occurs when any non‐SAP application is integrated into an end-to-end process flow. Because the predeveloped content is specific to SAP, any additional applications must be implemented completely from scratch. Further, these applications may span other platforms that are not supported by the UFT scripting language, thus requiring the introduction and integration of yet another tool and skill set.
In other words, from the moment a script-based solution is implemented, the underlying code shifts from being an asset that accelerates testing to a liability. The requirement of programming resources to develop, debug, test, and maintain potentially tens of thousands of lines of code inevitably slows things down.
There is a Better Way
With Worksoft, we think that there’s a much better way to approach testing. You don’t have to be a developer and write tests to get the quality you need. Anyone should be able to create a test. We want to democratize testing, letting business analysts and end users contribute to the process. The business friendliness and ease of use is what sets our solutions apart. Tests are built using simple narratives that explain the activity.
All test assets are stored in a central relational repository, so they are very easy to leverage and change. If you have a reusable sub-process you can see how many people are leveraging the test assets, and find those assets with ease; Worksoft tests are easy to work with when compared to HP UFT tests.
Learn how you can “Escape the Scripts of HP UFT” download the eBook today!