Het zwarte GAT
Als een testconsultant de rol van testlead voor de gebruikers acceptatie test (GAT) krijgt, is dat een van de meest opmerkelijke rollen die je als doorgewinterde tester kan hebben. Je bent verantwoordelijk voor slechts één van de vele testvormen (zoals de systeemtest, integratietest, functionele acceptatietest, etc). Ten opzichte van een testmanager, die over alle testvormen de scepter zwaait, lijkt dat een piece of cake. Maar schijn bedriegt.
Hoewel er steeds meer agile gewerkt wordt, worden de meeste SAP S/4HANA migraties volgens een waterval aanpak opgezet en daarmee zeer geschikt om een aparte testlead voor de GAT in te zetten. In een zuivere agile omgeving kom je deze rol niet of nauwelijks meer tegen. Nu weet iedereen dat waterval trajecten zo hun eigen specifieke uitdagingen hebben. Ook op testgebied. Daarom zoomen we in deze tip over SAP Testen in op de GAT.
Voor het testen
Wat en hoe gaan we testen? Voor een GAT zijn deze vragen soms moeilijker te beantwoorden dan je denkt. Vooral het ‘wat’ kan voor hoofdpijn zorgen. Zeker als het uitgangspunt is dat je niet 1:1 hetzelfde wil testen als hoe er bij de FAT of tijdens de sprints is getest. De GAT biedt immers de mogelijkheid om ervaren gebruikers op hun eigen manier naar het systeem te laten kijken. Maar als testlead wil je toch een lijstje hebben, dat je af kunt vinken en waarover je kunt rapporteren. Niet zelden kom je dan uit bij proces flows, die vertaald worden naar testscenario’s. En dat is in de meeste gevallen een goede basis. Door deze met de beoogde GAT testers door te nemen, ontstaat een gedeeld beeld van de testen die plaats gaan vinden. De moeilijkheid zit hem vaak in het feit dat de key-users hun processen heel goed kennen, maar het nieuwe systeem nog niet. Richting Go Live beland je in een situatie waarin deze key-users overvraagd worden. Training volgen, werkinstructies schrijven, testvoorbereiding én hun normale rol... allemaal tegelijk.
"De voordelen van key-users fulltime in het project zijn talrijk."
Een manier om dat te voorkomen is de GAT testers al veel eerder aan te haken. Het liefst fulltime. Ik heb een aantal keren meegemaakt, dat medewerkers een of twee dagen beschikbaar waren en dat later in het proces toch voor een volledige inzet werd gekozen. De voordelen zijn talrijk. Ze kunnen het systeem ontdekken, de testcases van tevoren uit gaan werken en je kan ze de basis van testen veel beter aanleren. Zeker in de wat grotere organisaties mag je als testlead voor deze manier van het inzetten van GAT testers alles uit de kast trekken. Ze zullen je later dankbaar zijn. De GAT fase verloopt hierdoor veel soepeler.
Tijdens het testen
Laat het los. Hoe vaak ik dit tegen betrokken eindgebruikers heb moeten zeggen, weet ik niet precies. Doe je dat niet, dan kan kostbare tijd verloren gaan aan discussies over details die tijdens het testen naar voren komen. Stelregel: is iets niet goed, maak dan een bevinding aan. Hebben de gebruikers en anderen tijdens de testvoorbereiding iets over het hoofd gezien dat een significante impact heeft op het proces, dan neem je pas op de plaats en bespreek je dit met stakeholders. Maar de ervaring leert, dat juist veel tijd verloren gaat aan geen van beide situaties. Er gaat met name tijd zitten in de relatieve onbekendheid met het nieuwe systeem en het ontbreken van kennis over de inrichting daarvan.
De meeste eindgebruikers zijn gemotiveerd en betrokken. Om verschillende redenen is het echter wel van belang om bij de start van het testen zelf aan te geven, dat er een deadline is en dat meters maken nu voorop staat. Meld je dat niet, kan het lastig zijn om het tempo gedurende de GAT nog op te schroeven. Een kwantitatieve planning van de testcases helpt jou en de eindgebruikers daarbij. Als er nog tijd over is, wil je natuurlijk wel dat de eindgebruikers door middel van error guessing de exoten in het systeem opzoeken.
Na het testen
Het zwarte gat. De testen zijn afgerond en het project zit waarschijnlijk in een freeze. En na de livegang is functioneel beheer in de lead en/of worden testen in het ontwikkelteam opgepakt. Het advies is de key-users nog een tijdje aan boord te houden. Zij kunnen hun collega’s helpen met het nieuwe systeem, maar ook zorgen dat de testadministratie op orde en herbruikbaar is. En bijvoorbeeld bevindingen van hun collega’s vastleggen in Jira. Als het voor livegang niet is gebeurd, is het aan te bevelen om aan een regressietest te gaan werken. In de praktijk zit je er als testlead na afloop van de GAT als je niet uitkijkt een beetje verloren bij. Een volgende GAT dient zich voorlopig niet aan en waarschijnlijk eindigt je opdracht snel of uiterlijk een paar maanden later. Om dat zwarte gat op te vullen, adviseer ik je een rol te gaan spelen in de hypercare en/of nazorg. Niet veel mensen hebben ervaring in het proces van nazorg en als tester heb je de skills om dat goed te doen. Ook in deze fase is er veel waarde toe te voegen op het gebied van testen van wijzigingen en fixes. Niet in de laatste plaats omdat richting Go Live veel aanpassingen op ‘on hold’ worden gezet en in deze fase alsnog worden uitgerold.
"Niet veel mensen hebben ervaring in het proces van nazorg en als tester heb je de skills om dat goed te doen."
GAT testen hebben een hele eigen dynamiek, die natuurlijk nog veel complexer is dan hier beschreven. Politiek, frustraties en een naderende live-gang zijn ingrediënten voor een turbulente fase van het project. Als u denkt dat uw organisatie hulp kan gebruiken bij de komende testfase, dan helpen we graag om deze op professionele wijze in te richten. Een succesvolle gebruikers acceptatietest draagt niet alleen bij aan een soepele livegang, het geeft vooral ook vertrouwen in het nieuwe systeem. Zo valt u niet in een zwart gat...
PTWEE helpt SAP gebruikende bedrijven beter en slimmer te testen en hanteert daarbij een pragmatische aanpak. Deze tip is opgesteld door SAP Testconsultant Martin. Heeft u behoefte om vrijblijvend van gedachten te wisselen over uw testuitdagingen? Neem dan contact met ons op.
