The Testing Phases: From Development to Live Operations

A successful system launch is based on multiple successive testing phases. Each phase pursues a clear objective and contributes to progressively reducing technical as well as organizational risks.

Figure: Testing phases in the implementation of logistics IT

Functional Tests at the Software Vendor

The starting point consists of functional tests in the software vendor’s development environment. Here, it is verified whether programming and configuration meet the requirements defined in the functional specification and detailed specification documents (Lasten- und Pflichtenheft). In addition to testing individual functions (module tests), the interaction of all modules should be validated particularly through integration and process tests.

The four-eyes principle has proven effective here: a second, independent person from the software vendor reviews the test results before the software is handed over to the client. This allows defects to be recognized and resolved at an early project phase.

Interface Tests

In parallel, all interfaces to existing systems are verified—for instance, to ERP systems, conveyor technology, automation components, or a WMS, provided it is part of the system landscape.

A distinction is made between two levels of verification:

Syntax verification: Are data fields, formats, and value ranges structured correctly?

Semantic verification: Is the transmitted information also substantively correct and logical? For example, it must be verified whether a transmitted order number or item number actually exists in the target system.

Particularly in complex logistics IT projects, close collaboration between the software vendor and the client’s IT managers is a critical success factor.

Factory Acceptance Test (FAT)

The conclusion of the development phase is formed by the Factory Acceptance Test (FAT). Here, the software vendor proves that the agreed functions and processes have been implemented completely. In a manual warehouse environment, this test phase often lasts around four weeks.

Site Acceptance Test (SAT) and User Acceptance Test (UAT)

Following a successful FAT, the Site Acceptance Test (SAT) is conducted in the client’s real system environment. The software is tested for the first time under production-like conditions using genuine hardware, real master data, and typical business processes.

In many projects, the SAT is simultaneously used as the User Acceptance Test (UAT). The future users verify whether the software reliably supports their daily operational procedures and subsequently sign off on the system officially.

A frequently underestimated element of this phase is stress and load testing. Many performance issues arise only under high workload—for example, when numerous mobile devices transmit data simultaneously or multiple processes run in parallel. If such scenarios are tested prior to go-live, subsequent operational disruptions can be significantly reduced.

Structured Defect Management Establishes Transparency

A professional testing process begins well before the first test run. All standard and special cases from the functional and detailed specifications should be documented in a structured test catalog. During test execution, test results, defect descriptions, priorities, responsibilities, and processing statuses are recorded traceably.

The more precisely a defect is documented, the faster it can be resolved. A complete defect report therefore consistently answers four central questions:

1. What defect occurred?
2. Where did the defect occur?
3. What inputs or system states triggered the defect?
4. What impact does the defect have on the business process?

In addition to functional defects, usability, performance, response times, and system behavior under exceptional circumstances should also be evaluated.

Acceptance Testing and Warranty

The final acceptance test takes place during go-live and the subsequent ramp-up phase. Because system behavior in live operations often differs from the test environment, the start of the warranty should not be automatically linked to the production launch.

A joint classification of open issues into defect categories creates transparency and avoids future conflicts. Critical and major defects should be resolved prior to acceptance, whereas minor deficiencies can be reworked within the scope of a bindingly agreed action plan.

Figure: Defect categories in software testing

Successful Logistics IT Projects Emerge Through Collaboration

The implementation of new logistics IT does not end with go-live. Rather, it marks the beginning of a long-term collaboration between client and software vendor. Therefore, testing procedures, acceptance criteria, responsibilities, and deadlines should be clearly defined right at the start of the project.

Those who treat testing phases as a strategic component of the implementation rather than merely a mandatory routine establish the foundation for stable live operations, high user acceptance, and the sustainable digitalization of logistical processes.

More information on the topic can be found in our whitepaper: »Guide for Successful Software Testing in Intralogistics«