ECO, Ltd.

Project AIM

Phase 1
Testing Standards
Original Author: John Smith
Owner: Team member Name

Revision History
Revision
Number
Initial

Revision date

Summary of Changes

Updated by

June 25st, 2004

Initial draft

John Smith

Changes
marked
N

Distribution
This document has been distributed to:

Name/Signature

Title

Reviewers
This document should be reviewed by:

Name/Signature

Title

Approvals
This document requires the following approvals.

Name/Signature

Title

Copyright 2004 SAP AG. All rights reserved

ECO, Ltd.

Project AIM
Table of Contents

TESTING STRATEGIES...............................................................................................4
Purpose of the testing strategy:...................................................................................................... 4
Testing Details By Project Phase.................................................................................................. 5
Realization Phase........................................................................................................................... 5
Unit Test....................................................................................................................................... 5
Development Test........................................................................................................................ 5
Scenario Test............................................................................................................................... 5
Integration Test 1 (IT1)................................................................................................................. 6
Integration Test 2 (IT2)................................................................................................................. 7
Final Preparation Phase.................................................................................................................. 7
System Technical Tests................................................................................................................ 7
System Performance Test............................................................................................................ 8
Cutover Test................................................................................................................................. 9

Copyright 2004 SAP AG. All rights reserved

ECO, Ltd.

Project AIM
1 Testing Strategies

1.1

Purpose of the testing strategy:

This testing strategy determines the type of testing to be done, which system elements will be
tested, when the testing is to be performed, and who is responsible for conducting and verifying the
test results. It follows a SAP best practices approach consistent with the recommendations of the
ASAP methodology. This paper will describe how testing should be conducted across all the
Projects in the Program.
The following types of testing will be performed during the project:

Unit Testing
Development Testing
Scenario Testing
Integration Testing (IT1 & IT2)
System Technical Testing
System Performance Testing
Cutover Testing (Mock Go-Live)

Each type of testing has a specific purpose.

The tests specific SAP objects ensure the proper functioning of the following:

Configuration / Individual transactions

Development Objects conversions, interfaces, user exits, reports, forms, and OSS notes
Authorizations / Roles
Integrated Functionality
Technical Components
System Performance
Cutover Sequencing and Timing

Other tests relate to Systems outside of SAP such as:

Integration Testing related to Interfaces to non-SAP Systems

Testing of data from external systems (i.e. conversions)

Copyright 2004 SAP AG. All rights reserved

ECO, Ltd.

Project AIM

Note: This paper will not address the testing tool which will be used since at this time, this is not yet
finalized. However, the concepts described here would be applicable irregardless of the tool
selected.

1.2

Testing Details By Project Phase

1.2.1

Realization Phase

Four of the testing types described above are conducted during the Realization Phase, the others are done in the Final
Preparation phase. The following describes what happens in each test within this phase.

1.2.1.1

1.2.1.2

Unit Test

Purpose: Test proper functioning of individual SAP transactions per configuration

Location: DEV environment (unit test client, R3D, Client 075)
Prerequisites: Configuration and BPP (if relevant for the transaction)
Testing Responsibility: Individual module team member
Signoff Responsibility: Module Team Lead and/or Track Lead
Tracking method: At the discretion of the individual Projects as needed.
Data Requirements: Manually created representative data master and/or relevant
production master data which will be imported. Transactional data will not be imported and
needs to be created, as needed, to support the test.
Documentation Requirements: Unit Test Sign off Sheet (suggested)
Development Test (i.e ABAP)

Purpose: Test proper functioning of Eco Ltd. specific development objects such as
conversions, interfaces, user exits, reports, and forms.
Note:
Conversions will test a limited amount of records only to insure that basic conversion
processing is functioning properly. A more robust conversion test, with higher data
volumes, will be conducted in a client in the QA environment.

Location: DEV environment (unit test client, R3D, Client 075).

Prerequisites: Functional Spec (from Blueprint phase), Technical Spec (from Realization
phase).
Testing Responsibility: Development team member
Signoff Responsibility: Development Lead
Tracking method: Development list / Development plan
Data Requirements: Manually created representative data master and/or production
master data which will be imported. Transactional data will not be imported and needs to
be created, as needed, to support the test.
Documentation Requirements: Technical Spec, Development Test Sign-off Sheet (To be
determined by relevant Project Team)

Copyright 2004 SAP AG. All rights reserved

ECO, Ltd.
1.2.1.3

1.2.1.4

1.2.1.5

Project AIM

Scenario Test

Purpose: Test proper functioning of chains of transactions that logically flow together as
part of an overall business process, e.g., sales order creation through delivery process.
Location: DEV environment (unit test client, R3D, Client 075)
Prerequisites: Configuration and BPP (if relevant for this transaction)
Testing Responsibility: Individual module team member
Signoff Responsibility: Module Team Lead and/or Track Lead
Tracking method: At the discretion of the individual Projects as needed.
Data Requirements: Manually created representative master and/or production master
data which will be imported. Transactional data will not be imported and needs to be
created, as needed, to support the test.
Documentation Requirements: Scenario Test script and sign-off
Comment: Scenario testing is focused primarily on within module transactions. This
test is not meant to be a full blown Integration Test but rather a more comprehensive test
within a module or some limited testing between some modules as needed (e.g. create an
order, deliver it, bill it and apply cash application). Subsequent Integration testing will focus
on a more full blown test to insure the proper functioning of cross module business process
flows.
Integration Test 1 (IT1)

Purpose: IT1 focuses on cross-functional integration points, as well as the most critical
end-to-end business processes within the SAP R/3 system. This would include testing key
SAP transactions, Authorizations / Roles, reports, and any Eco Ltd. specific user exits
which have been developed. It achieves the end-to-end testing of critical business
processes / flows. Interfaces and conversions would not be tested in this cycle. The
purpose of IT1 is to insure that the SAP functionality, as configured in the development
environment, is properly working and also to insure that all transports of this configuration
were properly moved into the Quality Assurance Environment.
Location: Quality Assurance environment (Integration Test client for Cycle 1)
Prerequisites: Completion of unit and scenario testing. The completion of development
of most critical user exits. It also requires the consolidation, release, and transport of
relevant requests.
Testing Responsibility: Cross-functional team. Note: Eco Ltd. may choose to include
power users / extended team members in IT1.
Signoff Responsibility: Integration Team and Module Team leads
Tracking method: IT scripts and IT plan
Data Requirements: Data will be manually entered into this testing cycle as defined in
the various testing scripts. Additionally, there may be the need to import master and
transaction data as well (as needed) as well any manually created objects.
Comment: IT1 builds upon and expands the scope of testing done in Scenario testing.
The Scenario test scripts form the starting point for the Integration test scripts. Metrics will
be put in place prior to starting Integration Testing to indicate when Integration Testing 2
can begin. For example, the project team may eventually decide that if 85% of the
identified tests have been conducted successfully and that all Critical testing issues have
been resolved from IT Cycle 1, work can begin on IT2. Furthermore, that for IT2 to be
deemed successful, the team must reach 100% success with all issues resolved.
Integration Test 2 (IT2)

Copyright 2004 SAP AG. All rights reserved

ECO, Ltd.

Project AIM

Purpose: IT2 takes the objects tested in IT1 and adds all remaining development
objects. Specifically, this includes the testing of all interfaces to external systems, data
conversions from legacy Systems, as well as all remaining development objects not tested
in IT1 (any reports, forms, and other enhancements which were not completed in time for
IT1). Additionally, authorization / role definitions should be completed and tested at this
time. In essence, IT2 becomes the test of the System as it will look in a productive
environment including any data brought in from legacy systems through automated
conversions.
Location: QAS environment (Integration Test client for IT2).
Prerequisites: Successful Completion of IT1 as defined above. Completion of all
development objects.
Testing Responsibility: Cross-functional team. Note: Eco Ltd. may choose to include
power users / extended team members as in IT1.
Signoff Responsibility: Integration Team and Module Team leads
Tracking method: IT scripts and IT plan.
Data Requirements: Scrubbed / converted actual data from legacy systems. These
conversions should had been successfully unit tested previously in the relevant
Development Systems. Ideally a full data conversion into the client where IT2 will be
executed, should occur.
Comment: IT2 builds upon and expands the scope of testing done in IT1. As such, the
Integration test scripts are added to and used to conduct this test.
Regression Testing of changes made to Production
There is also the need to regression test certain critical functions should significant changes
be made to the Production system in any functional area which might affect the processing
of previously tested cases of new functionality to eventually be released into Production.
This may happen in either IT1 or IT2. The need to retest will be determined by the team
lead in the respective areas. It is in this testing cycle that all current production support
changes must have been recreated in the R3D instance, unit tested as needed, and
transported to R3Q so that all of these changes can be tested along with any new
functionality that is a result of this waves efforts. The goal here is to insure that the new
and old functionality work properly together. It is suggested that testing scripts be written
which can be used over and over again for retrofitting purposes. The use of an automated
testing tool should help in this regard.

1.2.2
1.2.2.1

Final Preparation Phase

System Technical Tests

Purpose: The System Technical Tests are intended to validate that the technical
components of the production environment are working properly. These tests may include
some or all of the following specific tests.
o

Failure Test

Cutover Testing

Disaster Recovery Test

Backup and Restore Test

Copyright 2004 SAP AG. All rights reserved

ECO, Ltd.

1.2.2.2

Project AIM

System Administration Test

Printing and Fax Test

Going Live Check

Location: PRD environment (Production client)

Prerequisites: Signoff / completion of the Realization phase
Testing Responsibility: Technical team members
Signoff Responsibility: Technical Team Lead
Tracking method: Technical team project plan
Data Requirements: Minimal. Manually created representative data can be used to
conduct this testing
Documentation Requirements: None
Comment: All of these tests will be conducted at Eco Ltd., however, due to the
compressed nature of the project timeframe; the Disaster Recovery Test may (not be
performed until after the system goes live.) This testing will be conducted on the UPG
instance after creating a copy of the R3Q instance on it.
System Performance Test

Since Eco Ltd. is already live with an R/3 PRD instance the tests below will not take place on PRD,
but any relevant testing will be conducted in the R3Q environment. This will help determine any
areas in the PRD instance that may have to be tuned or adjusted to ensure best response times /
system performance for the additional functionality being brought in.

Purpose: The System Performance Tests are intended to ensure the Production (PRD)
system will meet or exceed the performance requirements outlined by Eco Ltd. in the
Blueprint phase. These tests may include some or all of the following specific tests.
o Volume / Stress Test
o Batch Cycle Test
o Month/Quarter/Year End Processing

1.2.2.3

Location: R3Q Client

Prerequisites: Signoff / completion of the Realization phase
Testing Responsibility: Technical and Module team members
Signoff Responsibility: Technical Team Lead and Functional Team Leads
Tracking method: Technical team project plan
Data Requirements: Extensive transactional data may be required to perform volume
and stress testing. This could require using a testing tool such as the SAP Computer Aided
Test Tool (CATT) or using groups of end users to simultaneously perform transactions
simulating production volumes
Documentation Requirements: None
Cutover Test

Purpose: Test proper functioning of Eco Ltd. automated conversions and any other
cutover activities which will be invoked prior to the Go-Live This is a repeatable process
which normally needs to be tested a few times in order to insure that the data is being
properly converted, that the correct data dependencies are determined as well as to

Copyright 2004 SAP AG. All rights reserved

ECO, Ltd.

Project AIM

determine correct timings and dependencies. The timings are important to determine in
order to finalize the actual shutdown periods prior to the actual Go-Live. The cutover test
may involve multiple interactions or mocks with each mock resulting in improvements of
the cutover tasks. By the time the final cutover or productive mock occurs, the cutover has
become a refined, automated smooth process with proper dependencies defined and
accurate timings determined.
Location: TBD. This can be accomplished in several different environments. Decision
based on availability of acceptable client.
Prerequisites: Successful completion of IT2.
Testing Responsibility: Cross-functional team
Signoff Responsibility: Cross- functional team, Project Management
Tracking method: Cutover project plan
Data Requirements: Executing the conversion programs to automatically load master
and transactional data is part of the Cut over process. No other data is required. It is
assumed that a data cleanup process has occurred prior to the actual final cutover testing
has begun.
Documentation Requirements: Cutover Project Plan.
Comment: The Cutover Test will be run multiple times, updating task dependencies and
timings each iteration until satisfied the cutover plan is complete, can be performed in the
time allotted, and will provide a system which is ready for use by the business. The first
cutover test is actually conducted as a preparation to load the necessary data into the
client used for IT2 testing. The idea is that by the time the Realization Phase is completed,
the cutover plan is mostly finalized to be tested at least once in the Final Prep Phase.

Copyright 2004 SAP AG. All rights reserved