SAP Central Finance Test Strategy
In any projects, testing is one of the key component and quality of testing defines the success rate during and post go live largely. In this blog, the discussion is focussed on how to plan the test strategy in Central Finance project.
It is important to understand that Central Finance projects are different from traditional ERP projects. In ERP projects we create configure a scenario and execute test scripts related to the same like we test P2P process, Q2C process etc.
However, in Central Finance Projects it is more than testing the scenarios rather testing the data. CFIN projects are more focussed on data and transformation of existing data into mew data model based on future design of the organization. In CFIN projects the test should be focussed on data which is coming in the form of Initial Load and replication.
Initial Load is a foundation of the transformation and set the base of the system so it’s important to give due importance to Load but Replication is something which is ongoing so it should be focussed more. In summary looking at the efforts and value below would be right approach:
Now coming to overall CFIN test strategy, it is important to note that source systems are the heart to the entire testing and success as they hold the data on which the success is measured. Moving away from tradition the production systems in CFIN should also participate in testing. From test system you can test the static data and can be successful with initial load but for data replication it may not be practical to post the volume of data in source system to ensure that all relevant scenarios are covered. In that case it would be wise to use the source productive system and connect it with CFIN Quality system and enable replication to see all documents posted by business in real time are getting replicated and all test scenarios are covered. Its is important to cover at least one Month End Close with this approach.Also, as stated above the data is important, so in any CFIN project you also need to plan for Quality systems refresh during the projects when test phase begins so that the quality systems reflects the latest data and that can be used to test.
This strategy is also recommended by SAP. CLICK HERE
In summary, the test strategy should look like this:
*SLT/MDG etc is not displayed here
*In case of 3 Tier Landscape QAS can be replace by ACC or vice versa
Let’s understand the overall test approach in detail
- Functional Unit Test – Here we test the system in terms of
- Basic data flow from source & target system
- RFC users
- Test Cycle 1 – Here the focus should be
- All enhancements should be working with flavor of data
- End to end connectivity including any application connectivity
- Since we load the latest data so most of the data errors should be resolved
- Configuration errors should be resolved
- User access should be aligned for production
- Minimal performance test
- Minimal data replication
- Regression Test – Regression test ensures that the changes brought by new implementation does not harm or affect the source system negatively. So it important to run the processes on source system to see all works as it was. Since in the next cycle the usage of source productive system is planned
- Mock Cut-over – this is the final run before production so it is assumed that most of the technical issues are closed before hand and here the focus should be on:
- Data replication
- Testing all kinds of scenarios and documents replication
- Full performance testing on both sides (source/target)
- Preview of error handling procedure and how it will be managed after Go Live
- Resource estimation for future management of systems and processes
- After exiting this test there is no room to go back and the next step is to move to production systems.
Initial Load should be part of all test cycles to create the foundation of financials but focus should be changing as project progresses.
I don’t intend to explain Production Cut-over here as we know when source production will be connected to target production system and project goes live the data replication starts in real business world
Based on above explanation it is evident that Central Finance testing is far different from ERP implementation projects so it is wise to say that unlearn the traditional method and then apply the new practices in testing rather just using old knowledge of testing. Of course the concept remains same but the way of planning & execution is different.
Since you are using production system in testing so be prepared for questions related to Data privacy, confidentiality etc. there are ways to mitigate and control this but this should not be the hindrance in the path of success.
I am hoping this short blog gives fair view of how to manage testing in CFIN project and as the saying goes the more you test the better it is so if in your project planning you have more space to add additional test(s) it is good to do that but what here I have shared is minimum recommended.
- SLT – SAP Landscape Transformation
- MDG – Master Data Governance
- ERP – Enterprise Resource Planning (any systems)
- CFIN – S/4HANA Central Finance
- DEV – Development System
- QAS – Quality System
- ACC – Acceptance System
- PRD – Production System
- P2P – Procure to Pay business process
- Q2C – Quote to Cash business process
Great article, Nitin Gupta , thanks for sharing.
I agree with your strategy and I would add that I've seen several projects starting that started with millions of errors in SLT. Don't forget that in most cases, your Central Finance system will be empty. Configuration you might expect like currency, country, unit of measure, etc might be missing.
My recommendation is: start small and build upon it. For instance:
An iterative process is more effective with Central Finance than with traditional projects.