Een van onze opdrachtgevers gaat een belangrijke stap zetten in de migratie naar SAP S/4HANA. Het hele weekend is uitgetrokken om de live-gang zo succesvol mogelijk te laten verlopen. Een van de topics in het draaiboek is de Productie Acceptatie Test (PAT). Een testsoort met zoveel mogelijke en verschillende invullingen ken ik niet. We noemen de test ook wel een sanity check of smoke test. Die laatste komt uit de elektronica-industrie. Als een prototype helemaal af was, stak men de stekker in het stopcontact. Als er geen rook uit kwam, was de test geslaagd. Bij PTWEE zien we liever geen ontploffingen en daarom delen we met deze tip over SAP testen een aantal basisprincipes van de PAT.
De scope
Als testen niet goed lopen of andere uitkomsten geven dan verwacht, ligt dat vaak aan de scope van de test. Of beter gezegd: een verkeerd gekozen scope. Bij de PAT is dat niet anders. Regelmatig wordt de PAT als een complete regressietest gezien. Dat is onnodig omvangrijk en de PAT neemt daardoor een te grote plek in het draaiboek van de livegang in. In een gestructureerd testproces is er genoeg getest om in het Go Live weekend met minder uit de voeten te kunnen. In veel omgevingen is een korte test meer dan voldoende. Kijken of alle functionaliteiten aanwezig zijn en in basis werken is prima. Complete procestesten zijn daarentegen gewoon ‘too much’. Een productrisico analyse is als het goed is al veel eerder gedaan, maar kan ook uitkomst bieden in het maken van de juiste keuzes.
Het moment van testen
In agile situaties vindt de PAT plaats vlak voordat de omgeving wordt vrijgegeven aan de gebruikers. Door het repeterende karakter van releasen is de PAT hier doorgaans een korte check. Een sanity check op bestaande functionaliteit en een snelle test van de nieuwe of gewijzigde software volstaat dan. Maar als de PAT plaatsvindt voor de definitieve go-no go beslissing (niet ongebruikelijk in waterval), moet er anders naar de PAT gekeken worden. Ook bij een migratie naar SAP S/4HANA is dat het geval. Je kan dan niet zomaar een order inboeken en tot en met facturering afhandelen. Stel dat er een ‘No go’ advies komt en een roll-back plaats gaat vinden. Dan heb je in de nieuwe omgeving al nieuwe data en financiële boekingen gegenereerd. Hou het bij (functionele) checks op productie zodra dat kan. Dat levert tijdswinst op en beperkt de risico’s.
De tester
Ook hier geldt dat er verschillende scenario’s zijn. Maar wat mij betreft kan dat in alle situaties dezelfde zijn: de test consultant is de aangewezen tester. Bij een gestructureerd testproces is het helemaal niet nodig om eindgebruikers een PAT uit te laten voeren. Als je daar toch voor kiest, zijn zij de enigen die de PAT uitvoeren. Een ‘dubbele’ PAT voegt zelden écht iets toe. Wat je soms ziet, is dat functioneel beheer de acceptatie op productie doet. Dat is dan in nauwe samenwerking met de testers van het ontwikkelteam. De beheerder test aan de hand van de testscripts van de door het team opgeleverde software.
Samengevat: om op het juiste PAT te blijven, hou je het simpel. Zo krijg je, ondanks de beperkte tijd in een goed georganiseerd Go Live weekend, in korte tijd bevestiging dat de nieuwe omgeving goed functioneert. Dit geeft vertrouwen richting Go Live en rust richting de eerste stappen in het nieuwe systeem op maandagochtend.
PTWEE helpt SAP gebruikende bedrijven beter en slimmer te testen en hanteert daarbij een pragmatische aanpak. Deze tip is opgesteld door Martin, SAP Testconsultant bij PTWEE. Heb je behoefte om vrijblijvend van gedachten te wisselen over uw testuitdagingen? Neem dan contact met ons op.
