One of our clients is about to take a significant step in the migration to SAP S/4HANA. The entire weekend has been set aside to ensure the go-live is as successful as possible. One of the topics in the blueprint is the Production Acceptance Test (PAT). I don’t know of a test type with so many possible and varying interpretations. We also refer to this test as a sanity check or a smoke test. That last term comes from the electronics industry: when a prototype was completely finished, the plug was put into the socket. If no smoke came out, the test was successful. At PTWEE, we prefer not to see any explosions, which is why, with this tip on SAP testing, we share a number of basic principles of the PAT.
The Scope
If tests do not run smoothly or give unexpected outcomes, it is often due to the test scope—or rather, a poorly chosen scope. This is no different for the PAT. The PAT is frequently viewed as a complete regression test. This is unnecessarily extensive, and consequently, the PAT takes up too much space in the go-live plan. In a structured testing process, enough testing should have been completed much earlier to manage with less during the Go Live weekend. In many environments, a brief test is more than sufficient. Checking whether all functionalities are present and fundamentally working is fine. Complete process tests, however, are simply ‘too much.’ A product risk analysis should ideally have been done much earlier but can also provide guidance in making the right choices here.
The Timing of Testing
In Agile situations, the PAT takes place just before the environment is released to the users. Due to the repetitive nature of releases, the PAT here is usually a brief check. A sanity check on existing functionality and a quick test of the new or changed software will then suffice.
However, if the PAT occurs before the definitive go-no go decision (not uncommon in Waterfall environments), the PAT must be viewed differently. This is also the case during a migration to SAP S/4HANA. You cannot simply enter an order and process it all the way through invoicing. Suppose a ‘No go’ advice is issued and a roll-back is initiated. In that scenario, you would have already generated new data and financial postings in the new environment.
Stick to (functional) checks on production data as soon as possible. This saves time and limits the risks.
The tester
Here too, different scenarios apply. But in my opinion, the designated tester can be the same in all situations: the test consultant. In a structured testing process, it is not at all necessary to have end-users perform a PAT. If you do opt for end-users, they should be the only ones executing the PAT. A ‘double’ PAT rarely adds any real value. What you sometimes see is that functional application management handles the acceptance on production. This is done in close cooperation with the development team’s testers. The functional manager tests based on the test scripts of the software delivered by the team.
In summary: to stay on the right PAT (Production Acceptance Test), keep it simple. This way, despite the limited time during a well-organized Go Live weekend, you quickly get confirmation that the new environment is functioning correctly. This instils confidence leading up to the Go Live and provides peace of mind for the first steps in the new system on Monday morning.
PTWEE helps SAP-using companies test better and smarter, applying a pragmatic approach. This tip was prepared by Martin, an SAP Test Consultant at PTWEE. If you would like to have a non-committal discussion about your testing challenges, please contact us.
