SAP GRC concepts, technology, and best practices

>>continued on page 4

searchthe online knowledgebase

www.GRCexpertOnline.comor www.SAPexperts.com

8Communicate with Customs Using AES in SAP GRC Global Trade Services

18Quick TipHow Enhancement Packages Increase Efficiency When Updating Your SAP System

20Quick TipMitigating (Human) Resource Risk in an SAP Implementation

22Quick Tip5 Considerations for Outsourcing Your IT Systems Audit

>>inside

May 2008Volume 1 | Number 5

Testing in the past was primarily considered a one-time activity, usually a focus of fresh implementations or major upgrade initiatives. Testing was expensive, but because it was usually a one-time activity, companies didn’t emphasize it. Testing is no longer a one-time phenomenon: It’s a day-to-day activity and requires a well-thought-out, repeatable testing strategy. Various business drivers — such as mergers and acquisitions, business reorganiza-tion, or the implementation of new modules and functionality — require sophisticated testing methodologies.

In addition to business and technological drivers, compliance drivers such as Sarbanes-Oxley and FDA regulations also mandate that organizations enact thorough testing strategies. The compliance requirements state that you need to thoroughly test and document any changes to business processes for the purposes of providing an audit trail.

When it comes to designing the most effective testing strategies, such testing methodologies must cater to two critical criteria: testing coverage and test automation. I’ll discuss these first and then move on to the five phases of an effective testing strategy.

Testing Coverage and AutomationOne of the most critical aspects of testing strategies is to make sure that all business processes are entirely covered in the scope of testing. Coverage means that you test various scenarios of

Organizations need to design and develop effective testing strategies to comply with Sarbanes-Oxley and industry-specific requirements. These testing strategies and methodologies need to cover both normal day-to-day maintenance of business scenarios and major initiatives such as upgrades, fresh implementations, and more. See how to build and follow a five-phase plan to perform testing on your system and ensure compliance.

Build Bullet-Proof Testing Strategies to Comply with Legal and Industry Regulations

by Mitresh Kundalia, Director, SAP Practice, Quality Systems & Software

extended Computer Aided Test Tool (eCATT) provides automated testing of a variety of SAP transactions. It can test across multiple systems on multi-ple formats for many users. It uses test scripts, the updated version of Computer Aided Test Tool (CATT)’s test cases. You can build these test scripts to be flexible and reusable for end-to-end processes.

Key Concept>>

� © 2008 GRC Expert Reproduction prohibited. All rights reserved.

>>continued from cover

each process. It is common to find that though a company tested business pro-cesses, it missed an exceptional situation.

For example, the process of creating a customer could have different scenarios for creating customers with different partner functions, such as sold-to cus-tomer, ship-to customer, bill-to customer, and payer customer. In this example, the scope of testing methodology should not only include the process of testing the cus-tomer but should also cover these multiple scenarios for partner functions.

Automation is another critical aspect of an effective testing strategy. Rather than manually repeating the tests, you can use automated testing tools, such as Computer Aided Test Tool (CATT) or extended Computer Aided Test Tool (eCATT) to automate these tests. The approach of automated testing requires additional efforts in the beginning for example, to design and build the eCATT test scripts. After you build these scripts, though, you can execute them multiple times, saving significant time.

Figure 1 shows a comparison of efforts associated with manual versus automated testing. Efforts associated with the manual testing remain essentially the same every time you perform testing during multiple test cycles. Using automated testing, the efforts may be higher in the beginning, especially to build the library of test scripts. Next time, when you want to do testing, you only need to put forth effort for processes that changed. You reduce overall testing efforts over multiple test cycles with automated testing.

Now that I’ve discussed these components of testing, I’ll move on to the methodology.

Testing MethodologyBased on my experience implementing the testing strategies for different customers, I’ve developed an effective testing strat-egy for SAP business processes. The

testing methodology covers the two criti-cal aspects of coverage and automation and consists of the following five phases:

PlanDesignBuildTestMaintain

These phases of the testing methodology are similar to ASAP methodology phases (project preparation, blueprint, realization, go-live, and post-go-live support).

The key activities associated with the plan phase are to scope all the possible testing

•••••

scenarios in the organization. At the end of the plan phase, you deliver the scope document. The scope document lists all the key business processes along with the possible scenarios that you’ll test. I described the phases, activities, and deliverables in Table 1.

Now I’ll explain a bit more about each phase.

Plan PhaseThe purpose of this phase is to provide initial planning and scoping of the key business processes for testing. The key task in this phase is to identify the scope

ManualTe

st cy

cles

Efforts fortesting

Efforts fortesting

Efforts forcreating

automatedtest scripts

Automated

Test cy

cles

Testing approaches — manual or automated testingFigure 1

Phase Activities Deliverable

Plan Scoping the testing processes Scope document, which lists all the key processes, subprocesses, and scenarios

Design Preparation for designing the test cases and test scripts

Design document, which lists the testing designs for processes

Build Developing the test scripts Test scripts using an automated testing tool

Test Executing the test scripts Test logs of the test scripts

Maintain Supporting and maintenance activities

Documentation and how-to training manuals

Phases, activities, and deliverables for testing methodologyTable 1

May 2008 • www.SAPexperts.com

For group rates on electronic access, call 1-781-751-8799 �

of the testing. As mentioned earlier, the scope of the testing should be exhaustive. Every company has its own unique and customized processes. Therefore, scoping the processes must also include the cus-tomized business processes.

In the plan phase, you should perform these activities.

Establish standard baseline processesAdd customized processesDetermine key metricsDetermine possible scenariosFine-tune testing scope

Establish Standard Baseline ProcessesTo begin the scoping for testing scenarios, start with the standard baseline processes. For example, for an order-to-cash (OTC) initiative, the key baseline processes could be:

Standard quotationsStandard order management

•••••

••

Pricing

Available-to-Promise (ATP)

Credit management

Delivery process

Invoicing or AR

Cash application

For each key process, you can identify the subprocesses and functions. For example, for the quotations process, you can list the subprocesses of inquiry, quotations, subsequent follow-up actions, and more. Using OTC as an example, you can see some sample baseline processes as shown in Figure 2. There would be similar lists of processes for other initiatives, such as purchase-to-pay.

Add Customized ProcessesUse the baseline scope for testing. You can then augment the testing scope by adding customized processes, such as custom sales order types or custom item categories.

•

•

•

•

•

•

Determine Key MetricsDetermine key enterprise structural and organizational elements. The enterprise structure elements could be various sales organizations, distribution channels, divi-sions, and more. Other organizational elements could be sales offices, sales districts, customer groups, and more. In addition, different order types, item cate-gories, and material types also could play an important role.

The idea is to list the critical key metrics for which you need to test the key pro-cesses. For example, if you have three sales organizations in your company, you may need to test the create sales order process three times one for each sales organization.

Determine Possible ScenariosIn this activity, determine all possible combinations of scenarios for the key processes. Each of the key processes might have multiple combinations or variations. For example, creating a

Customer service

Master records

Quotations PricingOrdermanagement

Creditmanagement

Cashapplication

ProfitabilityAnalysis

Delivery/Shipment

Invoicing/Accounting

Availability-to-promise (ATP)

Sample baseline processes for OTC initiative (Source: QS&S)Figure 2

� © 2008 GRC Expert Reproduction prohibited. All rights reserved.

standard sales order can vary:

Standard order for various sales organizations (North America, Europe, Asia)

Standard order for different distri- bution channels

Standard order for various divisions

Standard order for top N customers

Determine all possible testing scenarios for all the processes. The list of processes and all the possible scenarios forms the basis for the scope document.

Fine-Tune the Testing ScopeIn this activity, you can fine-tune the scope of the testing by determining whether you can automate the testing of the process and scenario or whether you have to do it manually. For example, if the process is too complex, or if it requires too much time and too many resources for you to automate it, you may choose to test it manually. After you complete this activ-ity, the scope document is ready, including the exhaustive list of processes and sce-narios to be tested.

•

•

•

•

Design PhaseAfter you’ve finalized the scope, you begin the design phase and focus on the automation tool, such as eCATT.

Rather than directly jumping to build and create the test scripts, the idea is to plan and design the common building blocks of the test components so that they are reus-able. For example, build the common eCATT components, such as test scripts and test data containers, so they are reus-able across multiple test scenarios. Master data management functions or AP functions could use a create vendor test script, and then purchase-to-pay functions could reuse the script.

Follow these best practices to design the test scripts. A good test script does more than test a transaction, it:

Is reusable across other processes, especially end-to-end processes

Verifies the results are as expected

Is flexible and uses parameters (import and export parameters)

Checks database tables to confirm the transaction was successful

If you’re using eCATT, you should design various eCATT components as shown in Figure 3.

•

•

•

•

Test script

Test data containers

System data containers

Test configurations

Build PhaseDuring the build phase, you build the eCATT test scripts. For each of the key processes and subprocesses identified in the plan phase, create a set of test configurations and build multiple scenarios as test cases, scripts, or data containers. Based on the test scripts, you then design and build end-to-end test configurations. The test scripts and configurations are unit-tested in the devel-opment environment and migrated to the quality assurance system for final testing.

Note that you create the test scripts for all the possible scenarios of the key process. For example, for the create customer process, considering sold-to and ship-to partner functions, you can see possible combinations of scenarios as shown in Figure 4.

Similarly, for the key process of creating a sales order, you can see possible multiple combinations of scenarios in Figure 5.

At the conclusion of the build phase, create the test scripts for all the possible combinations of scenarios scoped in the plan phase.

•

•

•

•

Test Configuration

Test data container(s)

What data to use

System data container

Where to do it

Test script

What to do

eCATT componentsFigure 3

In this article, I refer to eCATT as an example automated testing tool. You can use any other automated testing tool suitable for your organization. For more on eCATT, see Jayesh Nar-waney’s article, “Speed Up Security Testing Using eCATT” (Volume 5, Number 1) in the Financials Expert knowledgebase at www.Finan-cialsexpertOnline.com.

Note>>

In CATT, what eCATT calls test scripts were known as test cases, so you may see the terms used similarly. I’ll use test scripts in this article because I’m dealing mainly with eCATT as an example.

Note>>

May 2008 • www.SAPexperts.com

For group rates on electronic access, call 1-781-751-8799 �

Test Phase

In this phase, you execute test scripts and configuration for all the key processes and combinations and the system logs the test results. You can then review the testing results to assess for success or failure.

eCATT saves the test logs and you can retrieve them later for review and analysis. The test logs provide useful information on the parameters used during the execu-tion, test results, exceptions and error situations, system messages, and more. In the environment where compliance has

Variations

Sold-to

Ship-to

Combinations

Government customers

Trade customers

Wholesale dealers

Direct ship-tos

Third-party ship-tos

Ship-tos

Key process

Createcustomermaster

Possible scenarios for the create customer processFigure �

taken the major focus, the testing results and logs could provide sufficient assur-ance, if required.

It is common that you have to adapt the scripts for changes you’ve made to con-figurations. Typically, the situations are when you’ve changed configuration after creating the test scripts. For any such corrections or bug fixes, you then modify or recreate the scripts and retest the test scripts.

Maintain PhaseThe maintain phase covers the post-go-live support activities. After successful completion of testing and acceptance of the testing results, you can perform support activities such as maintenance, documentation, and routine support. You can also prepare detailed documentation, for example, how-to documents for main-tenance or step-by-step guides for creating and changing the test scripts. n

Standard

Returns

Americas

Full pricesTrade

Non-trade

Quantity

Returns

Short

Over

Promotions

Taxes

Rebates

Scale discount

100% discount

Discounts

Full prices

Discounts

RGAs

Free-of-charge

Europe

Americas

Europe

Variations CombinationsKey process

Salesorder

Possible scenarios for creating a sales orderFigure �

Mitresh Kundalia heads the SAP practice division at Quality Systems & Soft-ware (www.QSandS.com). QS&S helps companies achieve world-class perfor-

mance by realizing their latent business and technological potential with emphasis on SAP systems. QS&S uses industry-wide best practices and proven implementation tools to integrate complex business pro-cesses with the SAP system. With an MBA degree in finance, Mitresh manages imple-mentations of Financials and logistics applications with a special focus on man-agement reporting, Profitability Analysis, the new G/L, GRC, and Business Intelli-gence. He is a technical advisor for Financials Expert. You may reach him via e-mail at Mitresh@QSandS.com.