Some SAP Retail customers worldwide run warehouse software solutions in different countries with similar processes, but also country-specific settings and interfaces. A solution is usually rolled out successively, starting with one country and then ideally for other countries.
If, for some reason, a separate productive (SAP) system landscape is required for each country (warehouse), this means a very complex system landscape with advantages and disadvantages for SAP testings. During maintenance, further developments, and tests, this leads to an increasing effort if a separate client landscape including interfaces must be set up, maintained, and tested for each country and/or project. This applies to both maintenance and, if available, the release stacks. System maintenance, test data, test user creation, and, above all, tests are time-consuming, tedious, and expensive.
Simplification or standardization could be useful here, referred to as standard warehouses in the following.
The default warehouse is a hypothetical warehouse in which all processes that are not mutually exclusive are implemented. Processes, systems, and interfaces that are used in most countries are then also mapped in the standard warehouse. Special processes of individual countries are not included in the standard warehouse, especially if they are used as an alternative to a standard process and cannot be implemented within the same warehouse. This also provides incentives for the countries to insist less on country-specific specifications and to stay closer to the "standard" due to the resulting additional effort.
The standard warehouse serves as a central platform for testing in releases and for new developments in general. This means that it is not a statically fixed system, but is constantly being developed and enhanced like the global system landscapes.
In a 4-system landscape - Dev-Quality-Country- Q-Production, Dev and Q would be realized in the standard warehouse client, then as before, it goes to the country systems (country Q) and production).
The standard warehouse then forms the integrative platform for all future developments and the corresponding test types and phases. Instead of having to test in many different country clients (with corresponding interfaces and dependencies), tests can be performed in the hypothetical standard client, whereby further delivery is then carried out as usual using independent country systems, for example.
Up to the country tests, therefore, only the processes of the standard warehouse are tested in an integrative and regressive manner.
If a country wants/has to implement its own country-specific processes that are not mapped in the standard warehouse (or cannot be mapped), developments of other countries that have already been implemented must be used if possible. Otherwise, this must be implemented project-specifically (possibly via a separate project landscape) and/or can only be tested in Dev and then the Q-country tests. Developments that are not relevant for standard warehousing should/must be continuously tested by the country on Q in an integrative and regressive manner.
The clients of the country itself can remain in place to ensure the transport tracks. Customizing or country-specific settings can still be implemented if required. Basically, however, they should be closed for testing.
The test scope up to the country tests then only includes the standard warehouse processes, country-specific processes that are not included in the standard warehouse are not included in the scope.
In addition to the normal requirements, some additional conditions should be met.
Test automation (then set up in the Q system) only needs to be set up in one client (landscape) instead of specific to all country clients. Among other things, this leads to the following:
The mapping of clearly defined business processes with maximum (feasible and not mutually exclusive) coverage of processes and countries in one country client rather than in more and more country clients will greatly simplify the test preparation and execution. In addition to the advantages, however, there are also some disadvantages that must be taken into account.
In practice, however, the disadvantages are likely to be smaller, unless the settings and processes in the individual countries really are very different.
If, for some reason, a separate productive (SAP) system landscape is required for each country (warehouse), this means a very complex system landscape with advantages and disadvantages for SAP testings. During maintenance, further developments, and tests, this leads to an increasing effort if a separate client landscape including interfaces must be set up, maintained, and tested for each country and/or project. This applies to both maintenance and, if available, the release stacks. System maintenance, test data, test user creation, and, above all, tests are time-consuming, tedious, and expensive.
Simplification or standardization could be useful here, referred to as standard warehouses in the following.
What is meant by a default warehouse?
The default warehouse is a hypothetical warehouse in which all processes that are not mutually exclusive are implemented. Processes, systems, and interfaces that are used in most countries are then also mapped in the standard warehouse. Special processes of individual countries are not included in the standard warehouse, especially if they are used as an alternative to a standard process and cannot be implemented within the same warehouse. This also provides incentives for the countries to insist less on country-specific specifications and to stay closer to the "standard" due to the resulting additional effort.
The standard warehouse serves as a central platform for testing in releases and for new developments in general. This means that it is not a statically fixed system, but is constantly being developed and enhanced like the global system landscapes.
In a 4-system landscape - Dev-Quality-Country- Q-Production, Dev and Q would be realized in the standard warehouse client, then as before, it goes to the country systems (country Q) and production).
Integrative platform for all future developments and tests
The standard warehouse then forms the integrative platform for all future developments and the corresponding test types and phases. Instead of having to test in many different country clients (with corresponding interfaces and dependencies), tests can be performed in the hypothetical standard client, whereby further delivery is then carried out as usual using independent country systems, for example.
Up to the country tests, therefore, only the processes of the standard warehouse are tested in an integrative and regressive manner.
If a country wants/has to implement its own country-specific processes that are not mapped in the standard warehouse (or cannot be mapped), developments of other countries that have already been implemented must be used if possible. Otherwise, this must be implemented project-specifically (possibly via a separate project landscape) and/or can only be tested in Dev and then the Q-country tests. Developments that are not relevant for standard warehousing should/must be continuously tested by the country on Q in an integrative and regressive manner.
The clients of the country itself can remain in place to ensure the transport tracks. Customizing or country-specific settings can still be implemented if required. Basically, however, they should be closed for testing.
Standard Warehouse Test Scope
The test scope up to the country tests then only includes the standard warehouse processes, country-specific processes that are not included in the standard warehouse are not included in the scope.
- For projects, that are carried out using the standard warehouse procedure, only the new developments that are to be included in the standard warehouse are tested until the country tests.
- Country-specific processes or settings can only be additionally tested by the country in the country system.
- The country-specific overall solution is also only tested by the country on the country system.
Requirement for the test scope and test cases
In addition to the normal requirements, some additional conditions should be met.
- The definition and implementation of the standard warehouse processes must be performed by the teams that are coordinated with the countries and up-to-date.
- Evaluation, scripting, and prioritization of the test cases must be performed by the individual teams.
- Country-specific test cases must be defined and scripted by teams and countries.
- Test cases must cover all mapped and to be tested business processes.
- The tests cover all business requirements (processes) defined in the functional specifications.
- Testing confirms that the agreed business processes meet the defined requirements
- Test cases should be reusable for different test phases and test types.
- Test cases can then be used for different phases and test types without major adjustments and can be automated if necessary.
Benefits of Test Automation
Test automation (then set up in the Q system) only needs to be set up in one client (landscape) instead of specific to all country clients. Among other things, this leads to the following:
- Reduction of test effort
- Reduce workload
- Increased comparability of test results
What does this mean for test management?
The mapping of clearly defined business processes with maximum (feasible and not mutually exclusive) coverage of processes and countries in one country client rather than in more and more country clients will greatly simplify the test preparation and execution. In addition to the advantages, however, there are also some disadvantages that must be taken into account.
Benefits
- Only one test system (client) with always current data/users
- Test data and landscape can be more easily provisioned and maintained/cleaned up in one system.
- Fewer interfaces.
- Reduce the effort involved in preparing and carrying out individual test phases.
- Increased reusability in the context of different project types
- Stronger standardization of test phases.
- Efficiency gain through the use of standard storage functionalities.
- Check the preactivated or preassembled solution in the standard warehouse.
- Drive adoption of SAP standard warehouse processes.
- Country-specific developments can be tested in the dev and then country
- Where gaps are necessary, existing developments in other countries should be used where possible.
- Developments that are not relevant for standard warehousing should/must be continuously tested by the country on Q in an integrative and regressive manner.
Disadvantages
- Setting up and operation of the standard warehouse is an additional effort that is not to be underestimated.
- Dependencies between project and release developments cannot be completely excluded.
- There may be greater differences in the existing countries in the processes, it is difficult to define an intersection.
- Some settings and interfaces/external systems exclude each other.
- Decide which requirement can be implemented in the standard warehouse bears risks.
- In the future, changes cannot be mapped in a standard warehouse or can only be mapped with a delay.
- Several standard warehouses may have to be set up (different system landscapes and interfaces).
- Country-specific developments and settings can only be tested in a later test phase, which entails increased risk for the go-live, since less time is available for testing/fixing.
- Developments that are not relevant for standard warehousing must be permanently tested by the country for Q integrative and regressive.
- If the default warehouse “does not work”, you cannot switch to other clients.
- Possibly higher need for coordination and knowledge.
In practice, however, the disadvantages are likely to be smaller, unless the settings and processes in the individual countries really are very different.
- SAP Managed Tags:
