SAP-gebruikersacceptatietest: eigenaarschap en uitvoering

De SAP-gebruikersacceptatietest (UAT) is de fase waarin gebruikers uit de business hun eigen processen in het geconfigureerde systeem uitvoeren en het vóór de go-live formeel accepteren. De business is eigenaar, IT en de implementatiepartner ondersteunen, en bij een S/4HANA-programma plan ik er minstens 6 tot 8 weken voor.

De testfout die ik het vaakst zie, is eenvoudig: te weinig testen in UAT en in de systeemintegratietest (SIT). Loopt een planning uit, dan worden die twee fasen samengeperst, en de gaten komen pas na de go-live boven.

Hieronder: wie wat doet, voorbereiding, scripts, defecttriage en een sign-off die iets betekent. Waar UAT tussen de andere testsoorten staat, leest u in mijn overzicht SAP-testen uitgelegd.

De business is eigenaar van de gebruikersacceptatietest. Dat is mijn standpunt, en dat hoort niet te schuiven als de planning krap wordt.

De reden zit in de naam. Acceptatie is een zakelijk besluit over de vraag of het systeem de business draagt, dus alleen de mensen die de business runnen, kunnen het nemen. Als IT of de partner de UAT aftekent, heeft niemand iets geaccepteerd.

De eigen methodologie van SAP zegt hetzelfde. De richtlijnen voor de teststrategie van S/4HANA Cloud Private Edition plaatsen UAT in de Realize-fase. Configuratie-experts van de partner zetten de handmatige testgevallen op, en experts van de klant uit de business voeren ze uit en documenteren de resultaten.

Een werkbare verdeling van het werk ziet er zo uit:

Rol	Eigenaar in UAT van	Niet eigenaar van
Proceseigenaren uit de business	Scope van de scenario's, acceptatiecriteria, definitieve sign-off voor hun proces	Configuratie of code repareren
Key users en testers	Scripts uitvoeren, resultaten en bewijs vastleggen, bevindingen melden	In hun eentje beslissen dat een defect "geen defect" is
UAT-lead (vanuit de business)	Dagplanning, voortgang, voorzitter van de triage, gereedheidsrapportages aan de sponsor	Technische fixes
Implementatiepartner	Scripts opstellen, gereedheid van het testsysteem, defecten oplossen, ondersteuning bij hertesten	Acceptatie
Interne IT	Omgevingen, toegang, interfaces met andere systemen, transporten	Acceptatie
Datateam	Testdata laden en verversen, ondersteuning bij aansluitingen	Ontwerp van bedrijfsscenario's

De UAT-lead moet uit de business komen, niet van de partner. Een UAT onder leiding van de partner schuift op naar bewijzen dat de bouw werkt, en dat is een andere vraag dan of de business erop kan draaien.

UAT heeft minstens 6 tot 8 weken nodig. Met minder test de business het ideale pad één keer, heeft ze geen tijd om fixes opnieuw te testen en komt ze nooit bij de uitzonderingen waar de echte problemen zitten.

Die weken werken alleen als UAT begint op een stabiel systeem. De richtlijn van SAP is dat bedrijfsprocessen worden getest zodra de integraties zijn ingericht en de data voor het proces is gemigreerd. Dat betekent dat de SIT eerst moet zijn afgerond, tegen afgesproken exitcriteria. Mijn gids over de S/4HANA-teststrategie laat zien hoe die cycli op elkaar aansluiten.

Voordat de eerste tester inlogt, moet dit geregeld zijn:

1. Afgetekende procesontwerpen. De scripts worden daarop gebaseerd, dus niet-afgetekende ontwerpen betekenen scripts die nog niet vastliggen.
2. Instapcriteria gehaald en vastgelegd. SIT compleet, geen open kritieke defecten, en het testsysteem bevroren op gecontroleerde fixes na.
3. Een testsysteem dat op productie lijkt. Configuratie, interfaces, rollen en autorisaties zoals ze bij de go-live zullen zijn.
4. Realistische testdata. Gemaskeerd, op productieniveau, geladen en aangesloten voordat het testen begint. Mijn gids over SAP-testdatamanagement beschrijft hoe.
5. Testers vrijgemaakt van hun dagelijkse werk. Benoem ze, spreek hun uren af met hun leidinggevenden en leg dat schriftelijk vast.
6. Testers getraind op het nieuwe systeem. Een korte rondleiding door de Fiori-apps en transacties die ze gaan gebruiken, vóór UAT en niet tijdens.
7. Eén testmanagementtool. Scripts, resultaten, bewijs en defecten op één plek, niet in parallelle spreadsheets.

Bij punt 5 faalt UAT meestal in stilte. Testers die UAT moeten inpassen rond de maandafsluiting, zetten de maandafsluiting op de eerste plaats, en daar hebben ze gelijk in.

Een UAT-script is een bedrijfsscenario, geen lijst van transacties. "Maak een verkooporder aan" test een scherm. "Neem een order aan van een nieuwe klant met een kredietblokkade, geef die vrij, lever en factureer" test de business.

Bouw scripts op basis van de afgetekende procesontwerpen en geef elk script een duidelijk verwacht resultaat in zakelijke termen. De tester moet zonder een consultant te raadplegen kunnen zeggen of het geslaagd of mislukt is.

Dek vier soorten scenario's af:

1. Kernprocessen. De dagelijkse processen die de business draaiende houden, zoals order to cash, procure to pay en record to report.
2. Uitzonderingen. Retouren, kredietblokkades, deelleveringen, prijswijzigingen, stornering en goedkeuringen die worden afgewezen.
3. Periodeafsluiting. De stappen voor maand- en jaarafsluiting die het financiële team echt uitvoert, in de volgorde waarin het ze uitvoert.
4. Rolcontroles. Elke tester werkt onder de rol die hij of zij bij de go-live krijgt, zodat ontbrekende autorisaties nu zichtbaar worden.

Laat de partner de scripts opstellen en laat de key users ze daarna herschrijven in hun eigen taal. Kan de business een script niet zonder hulp volgen, dan is het geschreven voor het bouwteam.

In SAP Cloud ALM beginnen handmatige testgevallen bij een proces, en testplannen groeperen ze in cycli. Testers zetten elke stap op geslaagd of mislukt, leggen het werkelijke resultaat vast en melden een defect vanuit de testuitvoering, zodat de koppeling tussen script en defect blijft bestaan.

Bij programma's die SAP Solution Manager 7.2 nog gebruiken voor testmanagement: de mainstream maintenance eindigt eind 2027 (SAP Support). Plan nieuwe programma's op Cloud ALM.

Niet elke UAT-bevinding is een defect. Behandelt u ze allemaal als defect, dan raakt de partner overspoeld; behandelt u ze allemaal als wijzigingsverzoek, dan verbergt u echte fouten.

Houd elke dag van de UAT een triageoverleg. De UAT-lead uit de business zit het voor, met de functionele leads van de partner en een vertegenwoordiger van IT, en elke nieuwe bevinding verlaat de ruimte met een type, een ernst en een eigenaar.

Een eenvoudige indeling dekt de meeste bevindingen:

Type bevinding	Wat het betekent	Wie handelt	Effect op de sign-off
Defect	Het systeem doet niet wat het afgetekende ontwerp zegt	Partner lost op, tester test opnieuw	Kritieke en hoge defecten blokkeren de sign-off
Wijzigingsverzoek	Aan het ontwerp is voldaan, maar de business wil nu iets anders	De design authority beslist, met kosten en planning	Blokkeert niet, tenzij de business zegt dat het proces zonder niet kan draaien
Dataprobleem	Onjuiste of ontbrekende stamgegevens of transactiedata	Datateam corrigeert, tester test opnieuw	Blokkeert als dezelfde data live gaat
Trainings- of gebruiksprobleem	Het systeem werkt, maar de tester wist niet hoe hij het moest gebruiken	Trainingslead past het materiaal aan	Blokkeert niet, maar voedt het trainingsplan
Autorisatieprobleem	De rol mist toegang of heeft te veel	Securityteam past de rol aan	Blokkeert voor de betreffende rol

Spreek de definities van ernst af voordat UAT begint, in zakelijke termen. Een kritiek defect legt een proces stil zonder workaround. Een hoog defect heeft een workaround die de business bij volume niet kan volhouden.

Let op de kolom met wijzigingsverzoeken. Een lange lijst wijzigingsverzoeken in UAT betekent meestal dat de business niet goed bij het ontwerp betrokken was, en dat moet u oplossen vóór de volgende golf.

De Activate-training van SAP stelt dat de Realize-fase compleet is zodra de gebruikersacceptatietest is afgerond en afgetekend. Maak van die sign-off een document, geen e-mailthread.

Elke proceseigenaar uit de business tekent voor zijn of haar eigen proces. De sign-off moet vastleggen:

1. Wat er is getest. Uitgevoerde, geslaagde en mislukte scenario's, met het bewijs in de testtool.
2. Wat er nog openstaat. Elk open defect, met ernst, eigenaar en streefdatum.
3. Wat er met een workaround is geaccepteerd. Elk geval bij naam, met de workaround die de business heeft afgesproken.
4. Wie heeft getekend en wanneer. Eén persoon met naam per proces, geen commissie.

Schrijf de exitcriteria voordat UAT begint en verander ze niet als de resultaten binnenkomen. Wil de business toch live met gaten, leg dat dan vast als ondertekend besluit. Mijn gids over SAP-quality gates beschrijft hoe deze gate in de faseovergangen past.

De UAT-sign-off is niet het go-livebesluit. Ze voedt dat besluit.

Het go-livecriterium waar ik op sta, is een uitgebreide cutoverchecklist die vooraf is afgesproken. De UAT-sign-off is daar één regel op, naast de aansluiting van data, training en de cutover-repetitie.

Bescherm na de sign-off wat is geaccepteerd. Elke fix en elk transport tussen nu en de go-live moet opnieuw worden getest, en mijn gids over SAP-regressietesten legt uit hoe u dat beheersbaar houdt.

U hebt geen lang document nodig. U hebt één plan nodig dat elke keer dezelfde vragen beantwoordt, geschreven voordat UAT begint en ondertekend door de business.

Een eenvoudige opzet volstaat:

Sectie	Wat erin staat	Eigenaar
Scope	Processen, organisatie-eenheden en rollen in scope, en wat expliciet buiten scope valt	Proceseigenaren uit de business
Planning	Begin- en einddata, cycli, vensters voor hertesten, runs voor periodeafsluiting	UAT-lead
Team	Testers per proces, hun vrijstelling van dagelijks werk, contactpersonen voor ondersteuning bij partner en IT	UAT-lead en lijnmanagers
Instapcriteria	Exit van SIT gehaald, testsysteem bevroren, data geladen en aangesloten, testers getraind	UAT-lead met programmamanager
Omgeving en data	Testsysteem, interfaces in scope, gemaskeerde data op productieniveau, verversingsplan	IT en datateam
Scripts	Lijst van scenario's per proces, verwachte resultaten, koppeling naar het procesontwerp	Partner stelt op, key users keuren goed
Defectproces	Typen bevindingen, definities van ernst, dagelijkse triage, regels voor hertesten	UAT-lead zit de triage voor
Rapportage	Dagelijkse voortgang, open defecten per ernst, blokkades richting de sponsor	UAT-lead
Exitcriteria	Drempels voor open defecten per ernst, geslaagde scenario's, afgesproken workarounds	Proceseigenaren uit de business
Sign-off	Handtekeningblok per proceseigenaar, lijst van geaccepteerde workarounds	Proceseigenaren uit de business en sponsor

Houd het sjabloon gelijk over de golven heen. De tweede uitrol moet de scripts en lessen van de eerste golf hergebruiken, niet opnieuw beginnen.

Benoem deze maand uw UAT-lead uit de business en vraag elke proceseigenaar om testers voor te dragen die tijd vrijgemaakt krijgen. Zet daarna 6 tot 8 weken voor UAT na de SIT in het plan, en verdedig die als de planning krap wordt.

Wordt uw UAT door de partner uitgevoerd, of wordt hij steeds samengeperst, dan help ik programma's dit goed in te richten. U kunt hier contact met mij opnemen.

Wat is een gebruikersacceptatietest in SAP?

Het is de fase waarin gebruikers uit de business het geconfigureerde SAP-systeem testen tegen hun echte processen en het vóór de go-live formeel accepteren. In SAP Activate gebeurt dat in de Realize-fase, na de integratietest. Key users voeren scenarioscripts uit, leggen resultaten vast en melden bevindingen, en proceseigenaren tekenen af.

Wie is verantwoordelijk voor UAT in een SAP-project?

De business: proceseigenaren bepalen de scope en tekenen af, en key users voeren de tests uit. De implementatiepartner stelt scripts op en lost defecten op, en interne IT levert omgevingen, toegang en interfaces. Noch IT noch de partner hoort het systeem namens de business te accepteren.

Hoe lang moet SAP-UAT duren?

Plan minstens 6 tot 8 weken bij een S/4HANA-programma. Dat laat tijd om kernprocessen, uitzonderingen en stappen voor periodeafsluiting uit te voeren en daarna fixes opnieuw te testen. Een kortere UAT test meestal het ideale pad één keer en vindt de rest na de go-live.

Wat is het verschil tussen SIT en UAT in SAP?

De systeemintegratietest (SIT) controleert of processen en interfaces samenwerken over modules en systemen, en wordt vooral door het projectteam uitgevoerd. UAT controleert of de business haar processen op het systeem kan uitvoeren, en wordt door gebruikers uit de business uitgevoerd. De SIT moet klaar zijn voordat UAT begint.

Wat moet een UAT-sign-off bevatten?

De geteste scenario's en hun resultaten, elk open defect met eigenaar en datum, alle workarounds die de business heeft geaccepteerd, en een handtekening met naam per proceseigenaar. Spreek de exitcriteria af voordat UAT begint. Een sign-off met gaten moet een vastgelegd zakelijk besluit zijn.

Kan SAP Cloud ALM worden gebruikt voor UAT?

Ja. SAP Cloud ALM ondersteunt handmatige testgevallen die op processen zijn gebaseerd, testplannen per cyclus, het per stap vastleggen van geslaagd of mislukt en defecten die vanuit de testuitvoering worden gemeld. Volgens de richtlijnen van SAP zetten experts van de partner de testgevallen op, en voeren experts van de klant uit de business ze uit en documenteren ze de resultaten daar.