Best Practices for Implementation Testing

An SAP implementation tends to be a fluid concept with surprising challenges, changing deadlines and moving targets. Many businesses rush through the various steps of an SAP implementation or skip steps in order to cut costs or to meet unreasonable deadlines. The process behind a traditional implementation has been designed, tested and then ratified by SAP as a best practice. To deviate from the path that has been so successful in the past is to invite problems and delays. A project that is plagued by problems and delays fosters contempt and discontent in users and can cause a project to fail.

A woman can make a baby in nine months, but nine women cannot make a baby in one month. -Henry Paterson, mentor and friend

The purpose of testing

The real reason that SAP projects go through multiple testing phases is to learn how to successfully implement SAP relative to a specific project through a series of increasingly comprehensive rehearsals. By identifying problems in each test phase, developing solutions, implementing solutions and then finally demonstrating success the ground work is laid for a successful go-live. The final User Acceptance Test (or "Mock Go-live" or "Dress Rehearsal") is the culmination of all of the solutions developed during the test phases and demonstrates that the team is ready to load the legacy data in the production system with accuracy and confidence.

Prepare for multiple testing phases

Rushing through the individual test phases, skipping a test phase or attempting to run test phases concurrently requires that the processes that occur during the test phases to be rushed or skipped completely. Projects with little data, very simple data or fresh production systems still require extensive testing to ensure that the implementation will be a success. Three consecutive test phases is a realistic minimum and complex international projects implementing into a functioning production system will require more testing than that.

In the same way that a layer in a house of cards is dependent on all of the lower layers each test phase is dependent on the lessons learned and the solutions developed in previous tests. Any shortcuts taken can have catastrophic consequences including the introduction of post-go-live cleansing tasks, omission of mission-critical requirements, delayed go-live date or project failure.

Do not run test phases concurrently

The identification of errors and discrepancies tends to occur during the validation at the end of a test phase and the solutions are then implemented during the subsequent test phases. That ability to implement solutions based on identified problems is lost when test phases are skipped to save time or cut costs.

Many small course corrections applied to the direction of an airplane during a trans-Alantic flight allow it to arrive on-time with a fixed amount of fuel. Many test phases performed during an implementation allow it to be completed on-time and without catastrophic consequences.

The importance of each part of each test is self-evident and is described here solely for the purpose of edification.

System Integration Testing (SIT)

This phase of testing typically occurs in a development system after the initial data mapping has been completed. Tools are developed to extract, transform and load source data from the legacy system(s) into a sandbox or a snapshot of the production system.

It is a common practice to perform multiple SIT phases wherein each subsequent phase encompasses more data with more validation. A typical first SIT phase is no more than simple baseline configuration and the loading of the three major master data objects: Material Master, Vendor Master and Customer Master.

Redundant master data is identified for extension rather than creation. Inconsistencies in the source data are identified and corrected.

User Acceptance Testing (UAT)

The UAT phase(s) are typically performed in a Quality Assurance (or "Q") system after a SIT phase that involves a complete load of all the source data from the legacy system(s). The tools that were developed in the development system are transported to the Q system and then used to load the most recent extracts from the legacy systems.

Users validate the loaded data and identify corrections to be made during subsequent UAT phases. The data conversion team develops solutions to resolve problems and transform data as required and tools are modified accordingly.

Mock Go-Live

The final UAT phase is sometimes referred to as a "Mock Go-Live". A complete migration is completed from beginning to end as a rehearsal for the final go-live. The main purpose of this final UAT is to allay fears and ease concerns by demonstrating to users that the SAP implementation will be successful.

Where minor issues are encountered, a partial UAT phase or "Mini-Mock Go-Live" can be utilized to demonstrate proficiency in individual aspects of the project. Mini-Mock Go-Lives are commonly used to demonstrate that complex transactional data loads can be completed and verified in days without having to perform an entire UAT.