Dat SAP systemen steeds meer in de cloud worden ondergebracht is een gegeven. SAP C4/HANA, het commerciële broertje van SAP S4/HANA, is volledig op deze leest geschoeid. Hand in hand met deze ontwikkeling gaat de verandering van de manier waarop nieuwe functionaliteit bij de gebruikers terecht komt. Eerder hadden organisaties veel controle over het moment en de manier waarop een nieuwe release of enhancement werd uitgerold (‘pull’). In het geval van C4/HANA is die controle veel minder, omdat de leverancier hier alles bepaalt (‘push’). De leverancier bepaalt het tijdslot van de release en geeft de gebruiker slechts een korte periode om te testen. In dit bijvoorbeeld slechts twee weken. Welke uitdagingen geeft dit aan de testconsultant? We nemen je mee aan de hand van, hoe kan het ook anders, 4 C’s.
Controle
Als een organisatie niet zelf bepaalt welke functionaliteit wordt uitgerold, en ook het moment waarop niet zelf kan bepalen, is het lastig om een gestructureerd testproces op te zetten. In een situatie waar de nieuwe releases gepusht worden door SAP, is dat dus een grote uitdaging. Zeker als er een afhankelijkheid is van bijvoorbeeld key-users die de testen uitvoeren. Als er echt maar twee weken zijn om te testen, terwijl er in diezelfde periode een maand- of jaarafsluiting speelt, moet de testconsultant over veel overredingskracht beschikken. Meer dan bij ‘pull’ is de medewerking van de business hierin essentieel. De vraag om inzet van key-users is gekoppeld aan een krap tijdslot. Controle over een proces is immers niet hetzelfde als controle over mensen.
Daarnaast is de grip op nieuwe functionaliteit minder. Omdat die in de push releases meestal zijn uitgeschakeld, redeneert men al snel dat dit de huidige functionaliteit niet raakt en testen niet zo heel erg noodzakelijk is. Vergissen is menselijk. Een wijziging in de code kan ook effect hebben op bestaande functies als deze nog niet ‘aan’ staat. En wat doen we met bevindingen? Soms kan een organisatie wachten op de betreffende hotfix. Maar als de bevinding expliciet de eigen organisatie betreft, moet de SLA daar wel hulp in bieden. Anders heb je simpelweg pech.
Configuratie
Het instellen van parameters, opzetten van maatwerk rapporten of actietabellen inrichten zijn voorbeelden van configureren. Feitelijk een gebruiksvriendelijke manier van programmeren waarin ook SAP voorziet. Hierover nog zo’n misverstand. Door de overgang naar push is bij releases het configureren, naast testen, nog het enige dat gebeuren moet.
Nieuwe functionaliteit, ondanks dat het niet aan is gezet, kan om aanpassingen vragen van bestaande configuraties of simpelweg om geheel nieuwe instellingen vragen. Denk bijvoorbeeld aan een nieuwe optie om klanten op allerlei geografische aspecten te screenen. Grote kans dat de bestaande data, rapportages en procesflows van klanten daardoor geraakt wordt. Als je de configuratie dan achterwege laat, is de kans groot dat er zaken vastlopen of misgaan omdat ergens in de code om deze data gevraagd wordt. Al wil je er in de praktijk helemaal niets mee doen. En omdat die instellingen ook steeds meer naar 'standaard' gaan (maatwerk doen we immers zoveel mogelijk buiten SAP), kunnen we de releases zonder al te veel zorgen accepteren. Niet dus.
Consultants
De ontwikkeling van pull naar push heeft een directe impact op het testproces. Maar hoe zit het met de testconsultant zelf? Wordt dat een technisch gedreven tester die zich verliest in tooling en met TMap zwaait als er niet geluisterd wordt? Of transformeert hij of zij langzaam in een salonfähige consultant, die weet hoe de business geholpen wordt? In de opkomst van kunstmatige intelligentie schemert eenzelfde ontwikkeling.
Het lijkt er op dat de testconsultant meer en meer dingen moet gaan begrijpen in plaats van beoordelen. Soft skills helpen daarbij. Het menselijke aspect krijgt meer en meer een plek in de activiteiten van de testconsultant. Samenwerking met business en key-users krijgt immers een nog meer prominente plek. In een situatie waar acceptatiecriteria voor nieuwe functionaliteit niet zijn beschreven, kan je bijna niet anders dan (nog) meer tegen de business aan schurken om uiteindelijk weer tot een gestructureerd testproces te komen.
Conclusie
Zijn we vanuit testoptiek blij met deze ontwikkeling? Mwah. Net als zoveel andere zaken in de IT struikelen de veranderingen over elkaar heen. Dat creëert soms onrust en leidt af van wat er van ons verwacht wordt: gestructureerd testen. Maar “Push” biedt evengoed kansen. Voor de techneuten onder ons zie ik meer en meer dat zij zich richting ontwikkeling gaan begeven. Anderen, waaronder ikzelf, kunnen veel meer verdieping in hun werk leggen. De rol van ‘testconsultant’ krijgt een groeispurt. Veel meer adviseren en stimuleren. Partner van de business.
Kunnen we vanuit de techniek niets anders doen dan lijdzaam toezien? Zeker niet. De regressietest staat nog meer centraal in het testproces. Zorg dus dat die op orde is. Plan het (repeterende) testproces samen met de business ver van tevoren. Maak harde afspraken over de inzet en beschikbaarheid van key-users. Daarvoor is kennis van het releaseplan van SAP wel noodzakelijk. Dan misschien wel de belangrijkste tip. Wacht niet met het op orde brengen van het testproces tot de cloud zijn intrede heeft gedaan. Zie deze ontwikkeling als een goede stok achter de deur.
Kom maar op! Push it real good!
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 eens contact met ons op.
