Organisaties die met SAP werken kiezen er steeds vaker voor om al het maatwerk in SAP te ontmantelen en onder te brengen in losstaande (low-code) oplossingen. SAP en maatwerk is immers niet altijd een even prettig huwelijk. Als er bij het SAP testen issues zijn, bevinden die zich meestal in die hoek. Het complexe IT-landschap waar SAP een onderdeel van is, blijkt niet altijd zo overzichtelijk als je zou willen. Vergeten maatwerk kan dan een heuse sta in de weg zijn. Het kiezen voor maatwerk buiten SAP lijkt dan ook een verstandige route.

SAP en maatwerk is niet altijd een prettig huwelijk

Het testen van deze losstaande (web)oplossingen levert doorgaans niet al te grote problemen op. Het team, en dus ook de tester, heeft vanaf de eerste coderegel stap voor stap aan de oplossing gewerkt en kent het door en door (uitgaande van een agile omgeving).

SAP test in Waldorf de eigen standaard SAP-oplossing uitvoerig en dus er lijkt vanuit testperspectief geen vuiltje meer aan de lucht. Nou, net niet helemaal. De aandacht die het maatwerk in SAP normaal gesproken opeiste, verplaatst zich nu namelijk naar een andere plek. Waar moet u dan nog aan denken wat testen betreft? Begin met deze vier aspecten.

API’s

Stel dat daadwerkelijk al het maatwerk in SAP is verwijderd en alleen de door-en-door geteste functionaliteit van het ERP-systeem gebruikt wordt. Wat er nog wel is, is de communicatie tussen de (web)oplossingen en SAP, veelal via API’s. Daar waar testautomatisering lang niet altijd het antwoord is op elk testvraagstuk, is dat hier wel het geval. In tegenstelling tot GUI-testen zijn API-testen wel goed te automatiseren. Kijkend naar de standaard rolverdeling in testen, zijn de unit-testen de verantwoordelijkheid van de ontwikkelaar en de GUI-tests dat van de testprofessional. Het automatiseren van API’s hangt daar een beetje tussenin. Het advies is daarom bij het automatiseren van de API tests het ‘wat te testen’ vooral een vraagstuk van de tester te laten zijn en het ‘hoe te testen’ bij de ontwikkelaar te beleggen; een joint-effort. Het voordeel van deze tests is dat ze snel uitgevoerd worden, wijzigingen in standaard SAP worden zo snel zichtbaar. Het spreekt voor zich dat ook in andere situaties het automatiseren van de API-tests toegevoegde waarde kan bieden.

Regressietest

Een andere aanbeveling is om naast het API testen een separate en compacte regressietest op de standaard SAP-changes los te laten. Aan de basis van een regressietest ligt vaak een product-risicoanalyse die bepaalt welke onderdelen van het systeem en/of bedrijfsprocessen de hoogste risico’s met zich meedragen. Alleen de onderdelen en/of processen met het allerhoogste risicoprofiel neem je in deze testset op. Deze is duidelijk compacter dan de regressietest die het team in andere situaties gebruikt. Deze regressietest ligt in handen van de tester van het team.

Error-guessing

Bij het testen van updates of releases is het gebruikelijk om gebruik te maken van de kennis en tijd van eindgebruikers. Voor de push-releases waar we het nu over hebben, is dat aan te bevelen. Drie tot vier gebruikers met veel kennis van de processen en ervaring met SAP laat je het gewijzigde SAP onderdeel doorlopen. De testtechniek die je daarvoor in kunt zetten is error-guessing. Met wellicht wat hoog-over testscenario’s doen de gebruikers hun dagelijkse werk en gaan ze daarnaast op zoek naar de ‘exoten’ en lastige (deel)functionaliteiten. Omdat hier ervaren gebruikers voor nodig zijn, bestaat het risico dat minder ervaren gebruikers geen kennis opdoen. Voeg dus een wat minder ervaren gebruiker aan de groep toe en laat deze persoon mee testen.

Planning

Naast de genoemde maatregelen is er nog één grote uitdaging die om de hoek komt kijken: hoe voer je de testen uit in een kort tijdsvenster? De update is op de test- of acceptatie omgeving vaak maar een of twee weken beschikbaar voor de release naar productie. Voor de regressietest die door de tester van het team wordt uitgevoerd, kan dit lastig zijn omdat SAP geen enkele rekening houdt met het ritme van de sprints waarin het team werkt aan de eigen oplossing.

Daarnaast vragen de testen met eindgebruikers planning-technisch extra aandacht. Bij testen waarvoor meer tijd is, is het soms al lastig om gebruikers van hun dagelijkse werk te halen. En ook hier speelt dat SAP geen rekening houdt met bijvoorbeeld een maandafsluiting waar de financiële eindgebruiker mee te maken heeft. Een strakke planning is voor zowel de regressietest als de error-guessing testen het devies. De release-kalender van SAP hangt daarom boven het bed van de SAP tester.

De releasekalender van SAP hangt boven het bed van de SAP tester!

Direct profijt

Er zijn veel uiteenlopende ideeën en beslissingen te nemen als het gaat over een testaanpak. Met alleen de vier genoemde aspecten zijn wellicht niet alle zorgen weggenomen. Echter zijn deze onderdelen relatief snel te realiseren en brengen ze direct profijt. De trend om maatwerk ‘buiten de deur’ van SAP te zetten door bijvoorbeeld de inzet van low code levert stabiliteit in de core van het SAP landschap. Dit ontslaat echter niemand van de verantwoordelijkheid om de teststrategie hierop aan te passen (en deze uit te voeren!).

Het verbeteren van testen vraagt visie en discipline, mocht het bovenstaande te veel hooi op de vork opleveren dan is het wellicht verstandig eens te praten met een gespecialiseerde testpartij met veel kennis en ervaring in SAP testen?

PTWEE helpt SAP gebruikende bedrijven beter en slimmer te testen en hanteert daarbij een pragmatische aanpak. Deze tip is opgesteld door Martin Heining, SAP Testconsultant bij PTWEE. Heeft u behoefte om vrijblijvend met ons van gedachten te wisselen over uw testuitdagingen? Neem dan gerust contact met ons op!