Manage Learn to apply best practices and optimize your operations.

Chapter 5: 'Functional Test Automation'

This book shows how to implement a disciplined, efficient and proven approach for testing SAP R/3 correctly from the beginning of the SAP implementation through post-production support. The book also shows SAP professionals how to efficiently provide testing coverage for all SAP objects before they are moved into a production environment.


Download chapter 5: 'Functional Test Automation'


This chapter is excerpted from the book titled, 'Testing SAP R/3: A Manager's Step-by-Step Guide', authored by Jose Fajardo and Elfriede Dustin, published April, 2007 by Wiley Publishing, ISBN 978-0-470-05573-1, Copyright 2007 Wiley Publishing. For more information, please visit: www.Wiley.com







Chapter Excerpt:


Why Automate?

Business Case for Automation

There are three key benefits to automation:

  1. Expand your test coverage.
  2. Save time and resources.
  3. Retain knowledge.

Expanding your test coverage is one of the most valuable benefits of automation because it translates into higher quality and thus less costs associated with downtime, errors, and rework. Over the life of your SAP deployment you will likely experience an increase in the number of business processes it supports, either through the implementation of additional modules or integration with other systems.

As a result, each successive implementation or modification affects a greater number of business processes, which increases the risk and opportunity for failure. Even a 10 percent increase in total functionality still requires testing of 100 percent of the process inventory due to the risk of unexpected impact. The tightly integrated nature of SAP increases this risk.

As Exhibit 5.1 shows, a manual test process cannot keep pace with this expanding workload because time and resources available for testing are either fixed or even declining. In this exhibit, the lighter arrow indicates the processes that need to be tested and the dark arrow indicates the number of test resources. This combination of increasing processes that need to be tested with a static number of testers leads to increased risk and potential cost of failure.

Under the scenario represented in Exhibit 5.1, automation is the only practical answer. It enables one to capture tests as repeatable assets that can be executed for each successive release or deployment, so that the inventory of tests can keep pace with the inventory of business processes at risk.

This repeatability saves time and resources as well. Instead of requiring repetitive manual effort to reverify processes each time changes are introduced, tests can be automatically executed in an unattended mode. This allows your resources to focus on adding new

tests to support new functionality instead of constantly repeating existing tests.

Ironically, when test time is short, testers will often sacrifice regression testing in favor of testing new features. The irony is that the greatest risk to the user is in the existing features, not the new ones. If a business process that the enterprise depends on stops working— or worse, starts doing the wrong thing—then you could halt operations. The loss of a new feature may be inconvenient or even embarrassing, but it is unlikely to be devastating.

This benefit will be lost if the automated tests are not designed to be maintainable as the application changes. If they either have to be rewritten or require significant modifications to be reused, you will keep starting over instead of building on prior efforts. Therefore, it is essential to adopt an approach to test library design that supports maintainability over the life of the application.

Finally, the process of automating your test cases introduces discipline and formality to testing, which results in the capture of application knowledge in the form of test assets. You cannot automate what is not defined. By defining your business processes and rules as test cases, you are converting the experience of subject matter experts (SMEs) and business analysts (BAs) into an asset that can be preserved and reused over the long term, protecting you from the inevitable loss of expertise due to turnover.

Chapter 5: 'Functional Test Automation'

Visit the Wiley Publishing website for a detailed description and to learn how to purchase this title.

Test automation is not a panacea, but it can make a dramatic difference in the quality and stability of your SAP deployment over the long term. The key is to understand when automation works and when it does not, and how to assure your success.
This was last published in August 2007

Dig Deeper on SAP implementation

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchERP

SearchOracle

SearchDataManagement

SearchAWS

SearchBusinessAnalytics

SearchContentManagement

SearchHRSoftware

Close