SAP-testen uitgelegd: soorten, fasen en eigenaren

SAP-testen is het werk waarmee u aantoont dat een geconfigureerd SAP-systeem uw bedrijfsprocessen correct uitvoert, met uw data en op uw volumes, vóór de go-live en daarna bij elke wijziging. Bij een S/4HANA-programma omvat het zes testsoorten: unittest, systeemintegratietest (SIT), gebruikersacceptatietest (UAT), regressietest, performancetest en cutover-repetitie.

Elke soort beantwoordt een andere vraag, en geen ervan vervangt een andere. In mijn ervaring kost testen ongeveer 35 procent van de programma-inspanning. Daarom verdient het een eigen plan, budget en eigenaren, en niet een paar weken aan het eind van de bouw.

Deze pagina is het overzicht. Elke soort heeft een eigen gids, gelinkt vanuit de secties hieronder.

Een SAP-systeem is configuratie, stamgegevens, maatwerkcode en interfaces die samenwerken. Een wijziging op één plek kan een proces elders breken, vaak in een module die niemand heeft aangeraakt.

Daarom is SAP-testen georganiseerd rond bedrijfsprocessen en niet rond schermen. Order to cash, procure to pay en record to report lopen door meerdere modules, en een test die bij één transactie stopt, bewijst heel weinig.

Testen stopt ook niet bij de go-live. Supportwijzigingen, SAP-releases en nieuwe uitrol veranderen allemaal het systeem, dus dezelfde discipline loopt door in de Run-fase.

Dit zijn de zes soorten die ik inplan bij een S/4HANA-programma. De tabel laat zien wat elke soort bewijst, wanneer die loopt en wie eigenaar moet zijn.

Testsoort	Wat het bewijst	Plek in SAP Activate	Eigenaar
Unittest	Elk configuratie-item, programma of elke enhancement werkt op zichzelf	Realize, binnen elke bouwsprint	Functionele en technische consultants
Systeemintegratietest (SIT)	Volledige processen lopen over modules en interfaces met realistische data	Realize, in rondes zodra de bouw stabiel is	Testlead van het programma, met proceseigenaren
Gebruikersacceptatietest (UAT)	De business kan haar echte scenario's op het systeem uitvoeren	Laat in Realize, vóór Deploy	De business
Regressietest	Wat eerst werkte, werkt na een wijziging nog steeds	Vanaf Realize, daarna bij elke release in Run	Testlead, met automatisering waar het volume dat rechtvaardigt
Performancetest	Het systeem houdt stand met veel gebruikers en productievolumes tegelijk	Realize, afgerond vóór de go-live	Performancelead op programmaniveau, met Basis
Cutover-repetitie	De go-live-volgorde, dataloads en doorlooptijden werken van begin tot eind	Deploy	Cutovermanager

SAP-testen binnen SAP Activate

1. 01

   Prepare

   Richt de testtool, het team en het testlandschap in.

2. 02

   Explore

   Schrijf de teststrategie terwijl de fit-to-standard-beslissingen vallen, zodat eisen testbaar zijn.

3. 03

   Realize

   Unittests in sprints, daarna SIT-rondes, performancetesten en UAT zodra de bouw stabiel is.

4. 04

   Deploy

   Cutover-repetities tegen een afgesproken checklist, daarna het go-livebesluit.

5. 05

   Run

   Regressietesten bij elke supportwijziging, upgrade en release.

Unittest

De unittest wordt gedaan door de mensen die het item hebben gebouwd. Een functioneel consultant controleert een prijsconditie, een ontwikkelaar controleert een enhancement of een interfacemapping.

Het is nodig, maar niet voldoende. Een schone unittest zegt niets over wat er gebeurt als dat item de rest van het proces tegenkomt.

Systeemintegratietest

In de SIT ontdekt het programma of het ontwerp werkt. Een verkooporder moet doorstromen naar levering, facturering, boekhouding en rapportage, en elke interface onderweg moet correct boeken.

Ik plan SIT in rondes, niet als één doorloop. Defecten uit de eerste ronde worden opgelost, en de volgende ronde bewijst dat de oplossingen niets anders hebben gebroken. Hoe de rondes, de instapcriteria en de exitcriteria in elkaar passen, staat in mijn gids voor de S/4HANA-teststrategie.

Gebruikersacceptatietest

UAT is de business die bevestigt dat het systeem de manier van werken na de go-live ondersteunt. Die test hoort bij de business, niet bij de systeemintegrator, want alleen de business kan het systeem accepteren.

UAT heeft minstens 6 tot 8 weken nodig. Knijp het samen om een late bouw op te vangen, en u krijgt een handtekening op papier en problemen in productie. Mijn gids over de SAP-gebruikersacceptatietest behandelt scripts, rollen en sign-off.

Regressietest

De regressietest voert bewezen tests opnieuw uit na een wijziging, om op te vangen wat die wijziging heeft gebroken. Bij een lang programma lopen live supportfixes en projectwijzigingen tegelijk door het systeem.

Mijn aanpak is twee gescheiden landschappen: één voor het project en één voor de lopende bedrijfsvoering (BAU). Live supportwijzigingen en projectwijzigingen worden dan apart getest, en geen van beide verbergt een defect in de andere. Mijn gids over SAP-regressietesten behandelt de aanpak met twee landschappen, upgrades en impactanalyse.

Performancetest

Performancetesten moet vóór de go-live gebeuren. De tests die het meest tellen zijn concurrencytests, met veel gebruikers die op hetzelfde moment transacties uitvoeren.

Een transactie die voor één gebruiker correct is, kan voor tweehonderd gebruikers een time-out geven. Functioneel testen laat u dat nooit zien. Mijn gids voor IT-leiders over SAP-performancetesten behandelt load-, stress- en soaktests en hoe u acceptatiecriteria schrijft.

Cutover-repetitie

De cutover-repetitie test de go-live zelf: de volgorde van technische stappen, dataloads, aansluitingen en sign-offs, met doorlooptijden. Bij een brownfield-conversie plan ik drie mock-conversies vóór de cutover.

Het go-livecriterium waar ik op sta, is een uitgebreide cutoverchecklist die vooraf is afgesproken. Als de checklist tijdens het cutoverweekend wordt geschreven, waren de repetities geen echte repetities.

Testen kost in mijn ervaring ongeveer 35 procent van de programma-inspanning. Dat getal verrast sponsors die testen zien als het korte gat tussen bouw en go-live.

De inspanning is over veel mensen verdeeld. Consultants voeren unittests uit, een testteam bereidt de SIT voor en voert die uit, eindgebruikers uit de business voeren de UAT uit, en Basis- en integratieteams ondersteunen de performancetesten en de cutover-repetities.

Datamigratie loopt ernaast en kost op zichzelf 30 tot 40 procent van de inspanning. De twee overlappen sterk, want elke testronde heeft gemigreerde data nodig die op productie lijkt.

De testfout die ik het vaakst zie, is simpelweg te weinig testen in SIT en UAT. Rondes worden geschrapt als de bouw uitloopt, en de go-livedatum blijft staan. Over de 21 SAP-programma's die ik heb geleid of gered, is de grootste fout nog steeds dat er aan het begin niet goed gepland wordt, en bij het testen wordt dat meestal als eerste zichtbaar.

Tests zijn maar zo goed als de data waarop ze draaien. Mijn regel: gemaskeerde data, maar op productieniveau. Dat betekent volumes op productieschaal en realistische records, met persoonsgegevens en gevoelige velden gemaskeerd.

Kleine, schone testdata verbergt de problemen die ertoe doen. Een rapport dat in seconden draait op een paar duizend records, kan uren draaien op een volledig jaar aan boekingen.

De omgeving is net zo belangrijk als de data. Plan het testlandschap in Prepare, bepaal hoe het tussen de rondes wordt ververst, en houd project- en BAU-wijzigingen gescheiden. Mijn gids over SAP-testdatamanagement behandelt kopieën, maskering en selectieve testdata.

Mijn regel voor automatisering is eenvoudig. Als er een groot aantal testgevallen is dat uitgebreid en herhaald getest moet worden, automatiseer dan. Daaronder is handmatig testen prima.

Bij regressie levert automatisering meestal als eerste iets op, omdat dezelfde tests na elke wijziging draaien. UAT blijft grotendeels handmatig, omdat het doel het oordeel van een gebruiker uit de business is, niet dat van een script.

Er is een praktische reden om vroeg te beslissen. Geautomatiseerde tests kosten tijd om te bouwen en te onderhouden, dus ze verdienen zich alleen terug als ze vaak draaien. Mijn gids voor SAP-testautomatisering behandelt waar u begint en wanneer het zich terugbetaalt.

De tools vallen in drie groepen: testmanagement, functionele automatisering en performancetesten. Teams die ik heb geleid of waarmee ik heb gewerkt, gebruikten Tricentis Tosca, Worksoft, Panaya, SAP Cloud ALM, SAP Solution Manager, UiPath en LoadRunner.

Dit doet elke groep, met de producten erin:

Toolgroep	Wat het doet	Producten die teams vaak gebruiken
Testmanagement	Testplannen, testgevallen, uitvoeringsregistratie, defecten en traceerbaarheid naar eisen	SAP Cloud ALM, SAP Solution Manager, Panaya
Functionele testautomatisering	Voert gescripte of modelgebaseerde tests uit over SAP- en niet-SAP-applicaties	Tricentis Tosca, SAP Test Automation by Tricentis, Worksoft, UiPath
Performancetesten	Simuleert veel gelijktijdige gebruikers en productievolumes	OpenText LoadRunner, nu verkocht als OpenText Professional Performance Engineering

Een paar productfeiten zijn de moeite waard voordat u kiest.

1. SAP Cloud ALM is inbegrepen voor klanten met SAP Enterprise Support of een cloudabonnement dat Enterprise Support, cloud editions bevat (SAP Support). Het testmanagement dekt testvoorbereiding, testplannen en uitvoering, inclusief handmatige testgevallen voor UAT (SAP Learning).
2. SAP Solution Manager 7.2: de mainstream maintenance eindigt eind 2027, met optionele extended maintenance tot eind 2030 voor een deel van de functies, waaronder de testsuite (SAP Support).
3. SAP Test Automation by Tricentis is het automatiseringsproduct dat SAP doorverkoopt, geïntegreerd met SAP Cloud ALM en gebouwd voor SAP- en externe systemen (SAP).
4. LoadRunner is een product van OpenText. LoadRunner Professional heet nu OpenText Professional Performance Engineering en ondersteunt de protocollen SAP GUI en SAP Web (OpenText).

Start u een nieuw programma, plan het testmanagement dan in Cloud ALM en niet in Solution Manager. Voor een diepere vergelijking leest u mijn gids over SAP-testtools.

Op SAP Cloud ERP public edition (S/4HANA Cloud Public Edition) upgradet SAP elke klant volgens een eigen schema. SAP Learning beschrijft upgrades om de zes maanden, momenteel in februari en augustus, met nieuwe functies die daartussen maandelijks worden geleverd (SAP Learning).

U kiest de upgradedatum niet, dus regressietesten wordt een vast punt in de kalender in plaats van een project. Dat is het sterkste argument om regressie op een public-cloudsysteem vroeg te automatiseren.

Bij private cloud en on-premise bepaalt u zelf wanneer u upgradet. Elke upgrade heeft nog steeds een regressiecyclus nodig, afgestemd op de processen die de wijziging raakt.

Zet testen eerst in het plan als workstream met een eigen eigenaar en budget, op ongeveer een derde van de inspanning. Wijs daarna de eigenaar vanuit de business aan voor UAT en blokkeer er nu 6 tot 8 weken voor in de kalender, voordat de bouw die tijd opslokt.

Koppel testresultaten aan uw go/no-go-beslissingen met meetbare exitcriteria. Mijn gids over SAP-quality gates laat zien hoe. Zit uw programma al in de problemen, dan beschrijven mijn notities over herstel van SAP-programma's wat u als eerste oplost.

Wilt u een onafhankelijke blik op een teststrategie of een go-livebesluit, dan help ik organisaties daarbij. U kunt hier contact met mij opnemen.

Wat is SAP-testen?

SAP-testen bewijst dat een geconfigureerd SAP-systeem uw bedrijfsprocessen correct uitvoert, met uw data en op uw volumes. Bij een S/4HANA-programma omvat het unittests, systeemintegratietests, gebruikersacceptatietests, regressietests, performancetests en cutover-repetities. Het gaat na de go-live door bij elke supportwijziging en release.

Welke soorten SAP-testen zijn er?

De zes belangrijkste soorten zijn de unittest, de systeemintegratietest (SIT), de gebruikersacceptatietest (UAT), de regressietest, de performancetest en de cutover-repetitie. Unittests controleren losse items, SIT controleert volledige processen over modules en interfaces, en UAT is de business die het systeem accepteert. Regressie, performance en cutover-repetitie beschermen tegen wijzigingen, belasting en de go-live zelf.

Hoe lang duurt een SAP-gebruikersacceptatietest?

Plan minstens 6 tot 8 weken voor UAT. De business moet eigenaar zijn, haar echte scenario's uitvoeren en de test aftekenen. Te weinig testen in UAT en SIT is de testfout die ik het vaakst zie.

Hoeveel van een SAP-project is testen?

In mijn ervaring kost testen ongeveer 35 procent van de programma-inspanning. Dat omvat het voorbereiden en uitvoeren van unittests, SIT-rondes, UAT, regressie, performancetesten en cutover-repetities. Datamigratie loopt ernaast en heeft voor elke testronde data nodig die op productie lijkt.

Moet SAP-testen worden geautomatiseerd?

Automatiseer als u een groot aantal testgevallen hebt dat uitgebreid en herhaald getest moet worden, en dat betekent meestal regressie. Daaronder is handmatig testen prima. UAT blijft grotendeels handmatig, omdat het doel het oordeel van de business is.

Welke tool wordt gebruikt voor SAP-testen?

De meeste programma's combineren een testmanagementtool met een automatiseringstool en een tool voor performancetesten. Gangbare keuzes zijn SAP Cloud ALM of Solution Manager voor testmanagement, Tricentis Tosca, SAP Test Automation by Tricentis, Worksoft of UiPath voor automatisering, en OpenText LoadRunner voor performance. Nieuwe programma's kunnen het best uitgaan van Cloud ALM, omdat de mainstream maintenance van Solution Manager in 2027 eindigt.