Introduction
Before starting into the first cycle of integrative testing one of the many challenges a project faces is to ensure that the test system is "ready to test". In this article I want to elaborate on this particular challenge and showcase a simple yet effective tool to tackle it. My observations were made particularly in S/4 Hana Greenfield Implementation projects from a Test/Cutover Management point of view, but I recon this article may be applicable to a broader scope of IT projects as well.
Observations / Challenges
When it comes to your test system being "ready to test" there is oftentimes a very strong focus on having all the necessary transports in the test system. However usually the deployment of the transports onto the test landscape is just the first step of a long list. It is more appropriate to think of the initial test system setup as a mini-cutover, as it involves tasks from different teams/persons which are dependent on each other and need to be performed in a specific order.
While there usually the teams (or sub-projects, commonly representing classic functional areas) are aware of what settings need to be made for their area of expertise. The dependencies to other teams' settings and the order of execution are most of the time less transparent. Having to figure out the dependencies and thus ultimately the order of steps in a trial-and-error fashion can prove to be a very frustrating and time consuming endeavor for everybody involved.
Worst Case Scenario: While struggling with the aforementioned challenges the project is probably already burning valuable time that should have gone to test execution instead.
Proposed Approach:
In order to avoid these obstacles and have a test system that actually is "ready-to-test", the idea is to build awareness for these non-transportable settings and their interdependencies. This is best achieved by creating a list. Creating such a list is an iterative process. The relevant knowledge is usually in the teams/sub-projects but establishing transparency regarding the cross-task/cross-team dependencies requires collecting feedback from each team several times.
Example Screenshot of a List of Non-Transportable Settings as a Spreadsheet
Such a list of Non-Transportable Settings for test system setup can also be reused as template for the cutover plan for the go-live. Most likely involving the project's cutover manager is a very good idea as this lets you maximize the potential for reuse of the list.
(Depending on the project the Cutover Management may also assume ownership of this list and drive the process by themselves.)
Key Takeaways
- Having Transparency about Non-Transportable Settings for initial test system setup can save your project team a lot of time and frustration.
- Establishing this transparency in form of list is an iterative process requiring input from all project teams/functional areas.
- A list of non-transportable settings can later be reused as basis for a cutover plan.
- SAP Managed Tags:
