S/4HANA-teststrategie: cycli, criteria en rollen

Een S/4HANA-teststrategie bepaalt welke testcycli u draait, in welke volgorde, wie eigenaar is van elke cyclus en welk bewijs u nodig hebt om van de ene naar de volgende te gaan. In mijn programma's omvat ze de systeemintegratietest (SIT) in rondes, de gebruikersacceptatietest (UAT) in rondes en regressietesten, elk met schriftelijke instap- en exitcriteria en een benoemde sign-off.

Testen kost ongeveer 35 procent van de programma-inspanning in de S/4HANA-programma's die ik plan, dus de strategie verdient evenveel zorg als het bouwplan.

De testsoorten zelf behandel ik in mijn gids SAP-testen uitgelegd. Dit artikel is de strategielaag: cycli, criteria, rollen en de opzet van het document.

SAP Activate legt het meeste testwerk in Realize. Het eigen materiaal over de teststrategie voor S/4HANA Cloud Private Edition van SAP behandelt unit- en stringtests als informeel. Volledige tests van bedrijfsprocessen, integratie, datamigratie en gebruikersacceptatie zijn formeel en moeten worden gedocumenteerd.

Dit is de volgorde die ik plan bij een S/4HANA-programma:

S/4HANA-testcycli

1. 01

   Unit en string

   Consultants testen elke geconfigureerde functie en korte ketens terwijl ze bouwen.

2. 02

   SIT-rondes

   Volledige procesketens over modules, interfaces en gemigreerde data.

3. 03

   UAT-rondes

   Gebruikers uit de business bewijzen ronde voor ronde dat het systeem hun processen uitvoert.

4. 04

   Regressie

   Test opnieuw wat al geslaagd was, na fixes, transporten en releases.

5. 05

   Mock-conversies en repetitie

   Voer de cutover uit zoals die op de avond zelf loopt, tegen de checklist.

6. 06

   Go-live

   Ga alleen live als de afgesproken cutoverchecklist compleet is.

Unit- en stringtesten

Consultants en ontwikkelaars testen elk configuratie-item en elke ontwikkeling terwijl ze die bouwen. Stringtests koppelen een paar stappen aan elkaar, zoals een verkooporder tot en met de levering.

Informeel in de termen van SAP, maar niet optioneel.

Systeemintegratietest in rondes

De SIT test volledige bedrijfsprocessen over modules, interfaces en geconverteerde of geladen data. Ik plan die in rondes en niet als één gebeurtenis, zodat defecten die na een ronde zijn opgelost in de volgende opnieuw worden getest.

Ik heb geen vast aantal SIT-rondes. Het aantal hangt af van het aantal processen, interfaces en entiteiten in scope, en de strategie moet zeggen hoeveel rondes het worden en waarom.

Gebruikersacceptatietest in rondes

In de UAT bevestigt de business dat het systeem haar processen uitvoert, met haar eigen mensen en realistische data. Net als de SIT plan ik die in rondes, zodat fixes uit de ene ronde in de volgende opnieuw worden getest.

UAT heeft minstens 6 tot 8 weken nodig. Testers uit de business doen dit naast hun gewone werk, en ze hebben tijd nodig voor meer dan één ronde. Mijn gids over de SAP-gebruikersacceptatietest behandelt scripts, rondes en sign-off in detail.

Regressietesten

Elke fix, elk transport en elke release kan iets breken dat al geslaagd was. Regressietesten voert na elke wijziging de processen die ertoe doen opnieuw uit, tijdens het programma en na de go-live.

Het materiaal van SAP plaatst regressie vooral in Run, na release-upgrades, maar een programma heeft het ook eerder nodig. De aanpak, de impactanalyse en de inrichting van de omgeving staan in mijn gids over SAP-regressietesten.

Mock-conversies en cutover-repetitie

Bij een brownfield-conversie plan ik drie mock-conversies vóór de cutover. Elke conversie test de conversie zelf, de doorlooptijden en de aansluiting, niet alleen de processen.

De laatste repetitie moet lopen zoals de echte avond: dezelfde volgorde, dezelfde mensen, dezelfde checklist. Mijn tijdlijn en projectplan voor de S/4HANA-migratie laat zien waar deze runs in het plan vallen.

De belangrijkste beslissing over eigenaarschap: de business is eigenaar van de gebruikersacceptatietest. Niet de systeemintegrator en niet IT.

Een integrator kan scripts voorbereiden en defecten oplossen. Alleen de mensen die uw financiële afsluiting, uw order-to-cash of uw fabriek runnen, kunnen bevestigen dat die processen werken.

De eigen richtlijnen van SAP wijzen dezelfde kant op. Configuratie-experts van de partner maken de testgevallen, en experts van de klant uit de business voeren de UAT uit en leggen de resultaten vast.

Zo zou ik het eigenaarschap over de cycli verdelen:

Cyclus	Eigenaar	Voert uit	Tekent af
Unit en string	Lead van het bouwteam	Consultants en ontwikkelaars	Functionele en technische leads
SIT-rondes	Testmanager	Consultants, met key users die in latere rondes aansluiten	Testmanager en proceseigenaren
UAT-rondes	De business, via benoemde proceseigenaren	Key users en testers uit de business	Proceseigenaren, daarna de sponsor
Regressie	Testmanager	Testteam, geautomatiseerd waar het volume dat rechtvaardigt	Testmanager en wijzigingsraad
Mock-conversies en repetitie	Cutoverlead	Technische, data- en functionele teams	Cutoverlead, datalead en sponsor

Schrijf namen in de strategie, geen rollen. "Proceseigenaar financiën" is een rol; een persoon met een naam die heeft toegezegd te tekenen, is een eigenaar.

Instapcriteria voorkomen dat een cyclus begint voordat hij kan slagen. Exitcriteria voorkomen dat hij eindigt omdat de kalender dat zegt.

Schrijf beide voordat Realize begint, terwijl niemand onder deadlinedruk staat. Mijn gids over SAP-quality gates legt uit hoe deze criteria formele gates worden met een eigenaar die kan zeggen: "niet klaar".

De tabel hieronder is een richtlijn om aan te passen, geen standaard om over te nemen. Stel de percentages en defectgrenzen vast met uw sponsor en leg ze vast in de strategie:

Cyclus	Instapcriteria	Exitcriteria
Unit en string	Ontwerp afgetekend; configuratie en ontwikkeling compleet voor de geteste items	Alle items getest en gedocumenteerd; defecten opgelost of geregistreerd voor de SIT
SIT-ronde	Unittesten compleet voor de processen in scope; testomgeving gebouwd en interfaces gekoppeld; testdata geladen; scripts beoordeeld	Afgesproken aandeel van de scripts uitgevoerd en geslaagd; geen open kritieke defecten; lagere open defecten hebben elk een eigenaar en een fixdatum
UAT-ronde	Exitcriteria van de SIT gehaald; testers uit de business benoemd en vrijgemaakt van hun dagelijkse werk; scripts beoordeeld door proceseigenaren; training op het testsysteem gegeven	Elk proces in scope uitgevoerd door gebruikers uit de business; geen open kritieke defecten; proceseigenaren hebben hun processen afgetekend
Regressie	Een wijziging, een batch fixes of een release klaar om door te gaan; regressiepakket afgesproken voor de geraakte processen	Regressiepakket geslaagd; elke fout opgelost en opnieuw getest voordat de wijziging verder gaat
Mock-conversie of repetitie	Productiekopie beschikbaar; cutoverchecklist en runbook opgesteld; aansluitregels afgesproken	Conversie of load afgerond binnen het geplande venster; aansluiting afgetekend door de datalead; checklist bijgewerkt met lessen
Go-live	Alle eerdere exitcriteria gehaald; cutoverchecklist vooraf afgesproken	Elk item op de checklist compleet en afgetekend; go of no-go vastgelegd door de sponsor

Twee regels laten de tabel werken. Elk criterium geeft een antwoord met ja of nee, en elke exit heeft een benoemde ondertekenaar.

Haalt een cyclus zijn exitcriteria niet en wil de business toch door, maak er dan een schriftelijk besluit van. Noem de persoon die het risico heeft geaccepteerd en de defecten die worden meegenomen.

De testmanager schrijft het in Prepare of vroeg in Explore, en de sponsor keurt het goed. Houd het kort genoeg dat proceseigenaren het lezen.

Dit zijn de secties die ik verwacht te zien:

1. Scope en doelen. Welke processen, entiteiten, interfaces en rapporten worden getest, en welke expliciet niet.
2. Testsoorten en cycli. Unit, string, SIT-rondes, UAT-rondes, regressie, performance, testen van datamigratie en mock-conversies, met het aantal rondes en de onderbouwing.
3. Planning en inspanning. Data voor elke cyclus binnen het SAP Activate-plan, met minstens 6 tot 8 weken voor UAT, en de inspanning begroot tegen het testaandeel van ongeveer 35 procent.
4. Rollen en eigenaarschap. De tabel met eigenaarschap hierboven, met namen.
5. Instap- en exitcriteria. Eén set per cyclus, met de ondertekenaar voor elk.
6. Omgevingen. Welke systemen voor welke cyclus worden gebruikt, hoe ze worden ververst en hoe projectwijzigingen gescheiden blijven van live supportwijzigingen.
7. Testdata. Waar de data vandaan komt, hoe die wordt gemaskeerd en hoe die tussen de rondes wordt ververst. Mijn gids over SAP-testdatamanagement gaat hier dieper op in.
8. Defectbeheer. Definities van ernst, ritme van triage, wie de prioriteit bepaalt en de beoogde oplostijd per ernst.
9. Tools. Waar testgevallen, resultaten, defecten en sign-offs worden vastgelegd, met één leidend systeem.
10. Aanpak van automatisering. Welke tests worden geautomatiseerd, welke handmatig blijven en waarom.
11. Rapportage. Wat het wekelijkse testrapport laat zien en wie het ontvangt.
12. Cutover- en go-livecriteria. De cutoverchecklist, de repetities die haar bewijzen en wie het go/no-go-besluit neemt.
13. Risico's en aannames. Beschikbaarheid van testers, data van omgevingen, gereedheid van data en afhankelijkheden van derden.

Wat tools betreft is SAP Cloud ALM de standaardkeuze voor nieuwe programma's. SAP stelt dat er geen aparte licentie voor SAP Cloud ALM nodig is: het is inbegrepen bij Enterprise Support, en de apps voor testmanagement bevatten de formele testgevallen, runs en resultaten.

SAP Solution Manager 7.2 wordt in veel programma's nog gebruikt, maar de mainstream maintenance eindigt eind 2027. Voor automatisering verkoopt SAP SAP Test Automation by Tricentis, dat samenwerkt met Cloud ALM; mijn vergelijking van SAP-testtools behandelt de bredere keuze.

De testfout die ik het vaakst zie, is te weinig testen in UAT en SIT.

Een veelvoorkomend mechanisme: de bouw loopt uit, de go-livedatum blijft staan, en de weken gaan van de testcycli af omdat die aan het eind van het plan zitten.

Dit zijn de patronen die het veroorzaken, en wat u aan elk ervan doet:

1. De SIT begint voordat de unittesten klaar zijn. De eerste SIT-ronde wordt een ronde unittesten. Houd vast aan de instapcriteria.
2. UAT wordt gepland voor twee of drie weken. Gebruikers uit de business kunnen in die tijd niet goed testen naast hun dagelijkse werk. Plan minstens 6 tot 8 weken en maak de testers vrij.
3. De integrator voert de UAT uit voor de business. De scripts slagen, en de business vindt de gaten na de go-live. Houd het eigenaarschap van UAT bij de proceseigenaren.
4. Testen wordt begroot als een kleine post. Bij ongeveer 35 procent van de inspanning wordt testen dat op een fractie daarvan is begroot als eerste geschrapt.
5. Exitcriteria worden tijdens de cyclus geschreven. Ze sluiten dan aan bij wat het team toevallig heeft gehaald. Schrijf ze vóór Realize.
6. Over de go-live wordt beslist op gevoel, niet op een checklist. Niemand kan laten zien wat er was afgesproken, dus niemand kan zeggen wat er ontbreekt.

Op dat laatste punt sta ik. Mijn go-livecriterium is een uitgebreide cutoverchecklist, vooraf afgesproken met de business, IT en de integrator.

Ze dekt technische stappen, dataloads, aansluitingen, validaties door de business, het omzetten van interfaces, gebruikerstoegang en go/no-go-momenten. Is een item niet compleet en afgetekend, dan is het programma niet klaar, wat de datum ook zegt.

Vraag uw testmanager vóór de start van Realize om het teststrategiedocument en toets het aan de opzet hierboven. Heeft het geen benoemde eigenaar voor UAT, krijgt UAT minder dan 6 tot 8 weken of ontbreken instap- en exitcriteria per cyclus, los dat dan eerst op.

Wilt u een onafhankelijke review van een teststrategie of een go-livechecklist, dan help ik organisaties daarbij. U kunt hier contact met mij opnemen.

Wat is een S/4HANA-teststrategie?

Het is het plan dat bepaalt welke testcycli draaien, in welke volgorde, wie eigenaar is van elke cyclus en die aftekent, en welk bewijs het programma nodig heeft om van de ene cyclus naar de volgende te gaan. Bij een S/4HANA-programma omvat ze meestal unit- en stringtesten, SIT-rondes, UAT-rondes, regressie, testen van datamigratie en cutover-repetities.

Hoeveel van een S/4HANA-programma is testen?

In de programma's die ik plan, kost testen ongeveer 35 procent van de programma-inspanning. Begroot het vanaf het begin op dat niveau, want testen dat te weinig budget heeft, wordt als eerste geschrapt als de bouw uitloopt.

Hoe lang moet UAT duren bij een S/4HANA-project?

Minstens 6 tot 8 weken. Testers uit de business voeren de UAT uit naast hun gewone werk, en ze hebben tijd nodig voor meer dan één ronde, zodat fixes uit de eerste ronde opnieuw worden getest.

Wie moet eigenaar zijn van de gebruikersacceptatietest in SAP?

De business, via benoemde proceseigenaren. De systeemintegrator kan scripts voorbereiden, de omgeving beheren en defecten oplossen, maar alleen de mensen die de processen uitvoeren, kunnen bevestigen dat het systeem voor hen werkt.

Wat zijn instap- en exitcriteria bij SAP-testen?

Instapcriteria zijn de voorwaarden die een cyclus nodig heeft voordat hij begint, zoals afgeronde unittesten, een gebouwde omgeving en geladen testdata. Exitcriteria zijn de voorwaarden waaraan hij moet voldoen voordat hij eindigt, zoals uitgevoerde scripts, geen open kritieke defecten en sign-off door de proceseigenaar. Elk criterium moet een antwoord met ja of nee geven en een benoemde ondertekenaar hebben.

Wat moet een go-livechecklist voor S/4HANA bevatten?

Technische cutoverstappen, dataloads en aansluitingen, validaties door de business, het omzetten van interfaces, gebruikerstoegang en de go/no-go-beslismomenten. Spreek haar vooraf af, repeteer haar in de mock-conversies of de generale repetitie en ga pas live als elk item compleet en afgetekend is.