Test levels mapped to SAP delivery

A test level is a group of test activities organized around a stage of development, each with its own objectives, test basis and owners. The ISTQB Foundation syllabus (v4.0) names five: component testing, component integration testing, system testing, system integration testing and acceptance testing. SAP programs use their own words for similar ideas. Knowing how they line up stops a lot of arguments about who tested what.

Unit (component) testing

A unit test checks one piece. For configuration, that might be a new pricing condition: create an order and check that the condition appears with the right value. For custom code, developers test their enhancement, often with automated ABAP Unit tests that SAP provides in the ABAP development tools. Unit tests usually run in the development system, are informal, and are owned by the builder. SAP's own S/4HANA implementation guidance describes them that way: informal, done as configuration is completed.

String and integration testing

A string test chains several units together, for example order, delivery and goods issue for Contoso in plant 1710. It maps roughly to component integration testing. Integration testing (often called SIT) then exercises whole processes across modules and interfaces: a sales order that triggers availability checking, picking in the warehouse, billing, an EDI invoice to Great Lakes Fleet Services and the journal entry in finance. End-to-end testing strings processes into scenarios, such as procure, produce, sell and close the period. These are formal: documented in a test management tool, run in the quality system with realistic data, with defects tracked.

System testing in an SAP world

Generic models place system testing between integration and acceptance: test the whole system against its specification. On SAP programs this rarely appears as a separately named phase. Its job is shared by integration and end-to-end testing (functional behavior of the whole solution) and by non-functional tests such as performance, security and authorization testing. When someone asks "where is system testing in our plan?", the honest answer is usually: inside SIT and the non-functional cycles.

User acceptance testing

UAT asks a different question: does this solution let the business do its job? It is performed by business people, ideally those who took part in Fit-to-Standard and know the requirements. At Contoso, Maria runs order-to-cash acceptance and Dan's finance team runs period-end close. Acceptance testing can also include operational acceptance (can IT support and operate it?) and contractual or regulatory acceptance.

Who owns which level

In a typical program a system integrator configures and builds, while the customer owns the business outcome. The integrator usually owns unit and string testing and executes much of integration testing. The customer's process owners own acceptance and should not delegate it to the people who built the solution. That separation matters: someone who wrote the configuration tends to test that it does what they built, not what the business needs.

Regression testing is not a level of its own. It reuses tests from every level after a change. At Contoso, the regression pack will start as a selection of integration and end-to-end cases from Realize, and after go-live it passes to the support organization, which runs it before support packages, upgrades and larger transports reach production.