Automated Software Tests in the SAP Environment

SAP Automation Test, Automated test in SAP, ERP automation test, Testing SAP with automation tools, SAP automation tools, tools for automating SAP, software automation test in SAP, ERP automations tools, automation test tools for SAP, SAP test tools, SAP software testing tools.

Automated Software Tests in the SAP Environment

Highly integrated enterprise software such as SAP is subject to continuous changes in its life cycle – due to company mergers, changed legal requirements, new technologies, or simply upgrades and service packages. Of course, adjustments to the system have to be tested. Ideally, at the touch of a button. But is this type of automation possible and desirable?

 Due to regular release cycles, regression tests are one of the most important types of testing in the SAP environment. They can help establish whether a function that worked perfectly in a previous version continues to work in the new release. In addition, automation can speed up the testing and evaluation processes overall, because regression test cycles are not linked to the availability of user departments, who can then be relieved of recurring – and time-consuming – routine testing.

Before automation

Many people are mistaken in thinking that automated testing makes the impossible possible. However, experience has shown that most difficulties arise before the automated testing itself gets underway – when the correct test cases and test data have to be defined. These test cases must be manually executable and have a defined goal.

To find out which parts of a software solution must be tested repeatedly, the test management team can adopt various approaches:

• Risk analyses detect mission-critical scenarios that must be checked at all costs, if an update, patch, or SAP transport is pending.
• Upgrade/change impact analyses, on the other hand, support testers in localizing and quantifying the expected technical impact of changes.

A fundamental challenge at the actual automation stage involves identifying software objects using certain internal attributes, so that they can be found again during the automation process. In SAP systems, automating tests is relatively straightforward, because SAP objects can usually be identified by their type and certain attributes, such as internal names.

Alternative test tools

Remember… test automation

•Requires the test processes to have a certain level of maturity
•Is a long-term investment and does not generate a rapid return on investment
•Is software development and must be treated as such
•Should be structured in an evolutionary way
•Is primarily based on suitable methods, and then on the tools used

With non-SAP tools such as HP QuickTest Professional or Compuware TestPartner, the automation team can easily access these internal object attributes, even though they are not visible from the graphical user interface (GUI). Aside from these, eCATT (Extended Computer-Aided Test Tool) from SAP can, of course, be deployed. What’s more, various tools can read blueprints from SAP solutions to locate the dynpro or transaction in which changes have been made.

Regardless of the type of software test, test data and executable test scripts must always be strictly separated. The testers create the test scripts. In addition, the test cases should be driven by business cases and be modularized accordingly. 

To ease cooperation between the professional test engineers and the business experts, a keyword-driven automation strategy is also recommended. Using this strategy, the automation activities on the GUI are reduced to just a few key words that are intelligible to all.