Testing strategy for RISE conversion.

Testing is the workstream where most RISE conversions get into trouble too late to recover gracefully. The design and build phases consume the visible programme attention. The testing phase is treated as a finishing step. When testing begins in earnest the programme discovers defects that should have been prevented during design, performance issues that should have been identified earlier, and integration failures that should have been resolved months before. The testing window is then compressed because the cutover date is fixed, and the compression produces a go live that is unstable. The remedy is to treat testing as a primary workstream from the beginning of the programme, with the same governance, the same funding, and the same senior attention as the design and build workstreams.

01.Test strategy as a foundational document

The test strategy should be written at the start of the programme, not at the start of the test phase. The strategy defines the scope of testing, the test phases, the entry and exit criteria for each phase, the responsibilities, the tools, the environments, and the defect management process. The strategy informs the programme plan and the resource model. Programmes that write the test strategy late discover that the plan and the resource model do not support the necessary testing depth.

The strategy should be approved by the programme sponsor and by the business process owners. The business owners are the consumers of the testing output and their requirements should shape the test scope. The sponsor is the funder of the testing work and should understand what the strategy commits to.

The strategy should also be living. It should be reviewed at each phase gate and revised if the actual testing experience diverges from the planned approach. Many programmes write the strategy once and then never revisit it, with the result that the strategy and the reality drift apart and the strategy becomes a document of historical interest rather than a working tool.

02.Unit and string testing. Where defects are cheapest to fix

Unit testing covers individual technical objects, including custom code, configuration changes, and small integration components. String testing chains these objects together to verify that simple sequences work. Both types of testing happen during build and are typically owned by the build team.

The economics of defect discovery favour early testing. A defect found in unit testing costs a fraction of the same defect found in user acceptance testing, which costs a fraction of the same defect found in production. The programme should invest heavily in unit testing discipline so that the later test phases can focus on integration, performance, and business validation rather than on basic code defects.

The unit test coverage should be measured and reported. The standard target is high coverage for custom code and lower coverage for standard configuration. The metric should be reviewed weekly during the build phase. Programmes that do not measure coverage tend to discover during integration testing that the unit testing was incomplete, and the integration phase then absorbs work that should have been done earlier.

03.Integration testing. The phase that matters most

Integration testing verifies that the converted system works with the systems around it. The phase includes inbound and outbound interfaces, master data feeds, transactional integrations, and any third party integrations. Integration testing is the phase where the largest number of programme defects are typically discovered, and where the largest schedule risk usually sits.

The integration test scope should be defined explicitly. Every interface in the integration architecture should be tested, with end to end test scenarios that cover normal flow, error handling, data validation, and performance under realistic load. The scope definition should be done with the integration architect and the system owners on both sides of each interface.

Integration testing requires test environments that match the production topology closely. A common cause of late stage defect discovery is that the integration test environment did not include all the systems in production scope, did not have realistic data volumes, or did not have realistic configuration. The cost of building a more realistic test environment is repaid many times over by the defects that are found and fixed before user acceptance testing begins.

04.Performance testing. Often neglected, sometimes fatal

Performance testing verifies that the converted system can handle the production workload at acceptable response times. The testing should cover normal load, peak load, and stress conditions beyond peak. It should also cover specific operational scenarios such as month end close, quarter end reporting, and seasonal peaks.

Performance testing is frequently neglected because the test cost is high and the defect risk is perceived as low. The perception is wrong. Performance issues are common in RISE conversions, particularly where the legacy environment was tuned over many years to handle the workload and the new environment has not yet been tuned. Performance issues discovered after go live are expensive to fix and damage user confidence in the converted system.

The performance test should produce specific evidence that the system meets the service level commitments and the business requirements. Generic statements about acceptable performance are not sufficient. The test report should include response time distributions for each tested transaction, throughput data, resource utilisation, and identified bottlenecks with remediation plans.

05.Security testing. The phase that protects the next seven years

Security testing verifies that the converted environment is configured securely, that access controls are correctly implemented, that data is protected at rest and in transit, and that the environment is resilient to common attack patterns. The testing should be performed by a specialist team, ideally independent of the build team.

The security test scope should include the application configuration, the integration security, the operating model controls, the data protection controls, and the incident response procedures. Each of these should be tested against a defined standard and the results should be documented with evidence.

Security testing should also include a review of the shared responsibility model with SAP. RISE is a managed service and SAP is responsible for some aspects of security while the buyer is responsible for others. The boundary should be clearly understood and the buyer side responsibilities should be verified through testing. Many programmes assume that the SAP side of the model is bulletproof and focus all testing on the buyer side. The assumption is dangerous and should be replaced with explicit verification through third party assurance reports and through direct testing where contractually permitted.

06.User acceptance testing. The business sign off that matters

User acceptance testing is the phase where business users verify that the converted system supports the business processes correctly. The testing is typically organised by process area, with named business testers running defined scenarios against the system. The output is a documented sign off that the business accepts the system for go live.

User acceptance testing has two failure modes. The first is that the business does not engage seriously, treats the testing as a tick the box exercise, and signs off on a system that is not fit for purpose. The second is that the business engages seriously but discovers issues so late that the cutover date is at risk. Both failure modes are common and both are avoidable.

The remedy for shallow engagement is to define the user acceptance testing as a real workstream with dedicated business testers, named test leads from the business side, defined success criteria, and explicit consequences for incomplete testing. The remedy for late discovery is to begin user acceptance testing as early as feasible, ideally with parallel running during integration testing for high risk processes, and to maintain ongoing business engagement throughout the programme rather than concentrating it in the final weeks.

Testing is not the verification of a system already built. Testing is the system being built right. The discipline applied during testing determines what users experience after cutover.

07.Conclusion

A strong testing strategy for a RISE conversion treats testing as a primary workstream throughout the programme. The strategy defines explicit unit, string, integration, performance, security, and user acceptance phases with clear entry and exit criteria. Each phase is funded, staffed, and governed at the same level as the build workstreams. Test environments are built to match production topology and data volumes. Defect management is rigorous and timely. Business engagement is sustained throughout, not concentrated at the end. The result is a converted system that performs from day one, that the business has confidence in, and that does not absorb hypercare attention on issues that should have been resolved before cutover. The programmes that invest in this discipline land cleanly. The programmes that treat testing as a finishing step deliver systems that the business spends the next year repairing.