Choosing the SAP automation strategy

SAP automation strategy, Automation test strategy in SAP, ERP automation strategy, Automation test strategy in ERP, test automation in SAP, SAP automation testing strategy, SAP automation test plan, planning SAP automation testing, automation test plan in SAP, How to write automation test plan for SAP, SAP automation test plan

Choosing the SAP automation strategy.

HP Quality Center (QC) is an example of a tool that connects the modular business process method and the keyword-driven approach. With the help of the QC module BPT (Business Process Testing), business processes can be joined up like building blocks to form a chain. The test data can then be attached to the individual links in the chain (the business components).

Each chain forms a business transaction, with the relevant user department providing the input for each individual business component. The business experts are responsible for verbally describing the links in the chain, while the engineers translate the descriptions into test scripts.

This gives the testers who assemble the new chains – or test cases – the advantage of being able to build on links that already exist. Test cases do not necessarily have to be fundamentally different from one another. If, for example, a chain for a business process comprises 100 test links, it is highly probable that many individual links can be used from other chains.

An example of this is the process of logging on to SAP systems, which does not have to be described and defined a new once SAP logon has been specified for the first time. This link in the chain would also weather an upgrade. And, with such a description and automated testing, there’s a pleasant side effect for the company doing the testing: It receives an overview of the brainware in its user departments, displayed and clearly structured in test scripts.

SAP or non-SAP tools?

Non-SAP test tools pass muster particularly in test automation that entails testing integrated business processes with systems from third-party providers as well as from SAP, such as for customer relationship management (CRM) or content management (CM). 

eCATT from SAP immediately registers if a certain test script no longer runs on a certain software transaction due to changes – and in such cases provides the relevant analyses and evaluations. It is, however, quite possible that a function that has been changed in the SAP application has no impact whatsoever on the test case for a business process that works by using integrated systems from several providers. 

In such instances, an external tool such as HP QuickTest Professional has the advantage of only examining those parts of the system that are actually involved in the business process to be tested. The test case can therefore still be executed – despite a change in the SAP application.

SAP or non-SAP tools?

Non-SAP test tools pass muster particularly in test automation that entails testing integrated business processes with systems from third-party providers as well as from SAP, such as for customer relationship management (CRM) or content management (CM). 

eCATT from SAP immediately registers if a certain test script no longer runs on a certain software transaction due to changes – and in such cases provides the relevant analyses and evaluations. It is, however, quite possible that a function that has been changed in the SAP application has no impact whatsoever on the test case for a business process that works by using integrated systems from several providers. 

In such instances, an external tool such as HP QuickTest Professional has the advantage of only examining those parts of the system that are actually involved in the business process to be tested. The test case can therefore still be executed – despite a change in the SAP application.

Be methodical

But tools alone are no guarantee of success. Regardless of the tools, a methodical procedure model should form the basis of every test automation. This involves:

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.