Types of Testing

There are different types of testing that occur during the project, and each plays a critical role
in the project’s ultimate success. The testing strategy includes:

» Unit testing
» Scenario testing
» Integration testing
» System testing
» Technical tests
» Performance tests
» User acceptance testing

Unit Testing

Definition
This is the lowest level of testing where the program or transaction is tested and evaluated for
errors. Unit testing is normally the first test that is completed during the configuration effort,
and is focused towards the program’s inner functions, rather than towards the integration.

Testing focus:

» Master data
» Business processes
Examples: You can test master data by creating a Customer . Creating a standard sales order is
an example of a basic business transaction in the Sales and Distribution module.

Besides application testing unit testing is also performed during development and even during
technical system testing (please refer to Development Testing and System Testing).
Roles
Consultants configure the system during Baseline configuration and perform unit testing for
Baseline. During Final Scope configuration customer team members learn transactions and
configuration settings, and perform some unit testing.

System
Unit testing is performed in the development system, using a different testing client. Therefore
the configuration settings have to be copied to the other client before testing.

Make sure that the systems you select for testing are consistent with your overall system and
client landscape.

Scenario Testing

Definition
During the configuration there is a need to test chains of transactions that flow together and
which reflect important business processes and scenarios.

Testing focus:

» Multiple transactions within one enterprise area

» Workflow
» Business processes which cross enterprise areas
Examples: (of small scenarios)

» Standard sales order to a delivery to invoicing

» Invoicing to account document and posting
During subsequent integration testing these small scenarios can be used to build larger end-to-
end scenarios.
Roles
The business process owner is involved in creating baseline scenarios along with the application
consultant. Normally, the application consultant conducts the presentation to get the baseline
confirmed. For the subsequent scenario testing and confirmation for each cycle during Final
Configuration the business process owner should take on more responsibilities (i.e. defining the
test scenarios).

System
For scenario testing and especially for running the confirmation scenarios it is recommended to
use a special test client in the development system.
Integration Testing

Definition
Final integration testing is accomplished through the execution of predefined business flows, or
scenarios, that emulate how the system will run your business. These business flows, using
migrated data from the pre-existing systems, will be performed in a multifaceted computing
environment comprised of SAP , third-party software, system interfaces and various hardware
and software components. It is this environment that builds the necessary level of confidence
that the solution is complete and will perform in your business.

Final integration tests need to be an evolutionary process that is driven from your previous
testing efforts. The test cases and scenarios that were used for Baseline and Final Configuration
need to be reviewed and enhanced for the integrated test. These selected cases can be
combined to represent a business process flow such as a revenue cycle or a material acquisition
cycle. Problems encountered during these efforts also need to be tested under an integrated
environment. Final Integration test cannot be viewed as an independent, but as a capstone
effort that brings together and builds upon all previous testing efforts.

Integration testing should be allotted approximately twenty-five percent (25%) of the total time
used during the Realization Phase for configuration and testing.

Final Integration testing focuses on cross-functional integration points, as well as end-to-end

business processes. A well defined Final Integration test plan starts with the testing of the
cross-functional integration points (touch points) and ends with the end-to-end testing of
critical business processes identified within the Business Blueprint.

Integration test should also include testing the organizational flow, i.e. how the several
organizational units are involved in one process, how they communicate, how the information
and document transfer is handled.

Integration Test 1 and 2

Final Integration testing is recommended to be done in two iterations. The first iteration
(Integration Test 1) concentrates on testing all important business processes inside the SAP
System, starting with touch point scenarios and ending with end-to-end-scenarios.

If customer specific development like user-exits and transactions is already finalized and unit
tested, it should be included in the first iteration. Authorizations and user roles should be also
tested in the Integration Test 1.
Integration Test 2, as a second iteration, focuses on the most important cross-enterprise
scenarios with touch points to external components, including testing of conversions,
interfaces, reports, forms (SAPScript), EDI, ALE, and the necessary authorizations.

Roles
As the knowledge transfer from the SAP business process experts to the project team
approaches an apex, responsibility for the integration test becomes that of the business process
users and power users. This also instills a sense of ownership with the business process users
and should make it easier to get acceptance at the end of the phase.

There is a change in the make up of the testing teams between the configuration cycles and
integration testing. As the test becomes more integrated, the test team should include team
members from every enterprise area being tested. This will ensure that all processes are
properly tested. Involve extended teams members to ensure you meet the company’s business
requirements.

System
Quality Assurance System is needed for Integration testing. Master data from legacy systems
should be converted onto the Q/A system. All configurations should be frozen on the
Development system and transported onto the QA system.

System Testing

Definition
System testing consists of technical tests and performance related tests. The technical tests
aim to validate that the technical components of the production environment are working
properly. These tests include validating the system administration procedures, failure recovery,
and disaster recovery. The performance related tests include volume and stress testing of
business transactions and business transaction input / output using printer and fax devices.
Technical Test

» Failure Test
» Disaster Recovery Test
» Backup and Restore Test
» System Administration Test
» Printing and Fax Test
» Going Live Check

Roles
Technical Team Lead (along with application team members).

System
Testing can be prepared in the Quality Assurance system, but must run on the Production
system.

User Acceptance Testing

Definition
Normally there is no special need for a User Acceptance Test, because the system should have
been accepted by the confirmation of the Final Integration Testing. This is the reason why it is
not included in the ASAP Roadmap. If you need to perform a separate User Acceptance Test,
you can choose some of the Integration Test Scenarios.

Phase and Work package

Final Preparation (optional, no Roadmap work package)
Roles
Power User, End Users.

System
Quality Assurance system and Production system