De testfase staat op de planning. De consultant heeft de inrichting opgeleverd, er zijn een paar weken gereserveerd en de testscripts liggen klaar. Het voelt georganiseerd.
Maar wat we keer op keer zien: na de livegang duiken er fouten op die in de testfase niet naar boven zijn gekomen. Niet omdat er niet getest is, maar omdat er verkeerd getest is. Processen leken te werken. Het eindresultaat klopte niet. Of de testomgeving was niet goed klaargezet. Of de juiste mensen hadden geen tijd om aan te haken.
De fouten die na livegang het meeste pijn doen, zijn zelden echt verrassend. Ze zijn te herleiden tot keuzes die weken eerder gemaakt zijn, of niet gemaakt zijn.
Begin bij de start van de realisatiefase, niet vlak erna
De meest gemaakte fout: testvoorbereiding begint te laat. Organisaties wachten tot de inrichting klaar is en beginnen dan pas na te denken over wie er gaat testen, wanneer en hoe. Tegen die tijd is de planning al krap.
Een gezonde testaanpak start parallel aan de realisatiefase. Dat betekent: zodra de analysefase is afgerond en de inrichting wordt gebouwd, begin je tegelijkertijd met het plannen van de testsessies, het bepalen van de testcapaciteit en het voorbereiden van de testscripts.
Dit geeft je de ruimte om de juiste mensen op het juiste moment beschikbaar te hebben. Leidinggevenden, personeelsadministratie, finance: dit zijn precies de mensen die tijdens de testfase aanwezig moeten zijn, en precies de mensen die een volle agenda hebben. Begin je te laat, dan haak je ze af. De testfase vindt dan plaats met de verkeerde deelnemers, of zonder de mensen die er wél bij hadden gemoeten. De bevindingen die daar uitkomen zijn dan ook beperkt, niet omdat de inrichting goed is maar omdat de test onvolledig was.
Wie pas begint met testvoorbereiding als de realisatiefase al ver gevorderd is, is te laat.
De happy flow is geen bewijs dat het werkt
Veruit de meest voorkomende testvalkuil: mensen klikken door de schermen heen, zien dat het proces doorloopt en concluderen dat het goed is. Dat is de happy flow, en hij is niet genoeg.
Een concreet voorbeeld. Je test het indienen van een declaratie. Je dient hem in, je keurt hem goed, alles ziet er netjes uit. Maar heb je ook gecontroleerd of de goedgekeurde declaratie daadwerkelijk op de loonstrook terechtkomt? Dat is het eindresultaat. Pas als je dat gecontroleerd hebt, is de test echt volledig uitgevoerd.
Ditzelfde geldt voor de uitzonderingen: wat als een declaratie wordt afgekeurd? Wat als een verplicht veld ontbreekt? Wat als een leidinggevende niet de taken van zijn medewerker ziet? Testscripts moeten niet alleen het gewenste pad doorlopen, maar ook de uitzonderingen dekken, en altijd eindigen bij verificatie van het eindresultaat.
Een inrichting die er goed uitziet geeft een vals gevoel van zekerheid. De test is pas geslaagd als je hebt bevestigd dat het proces oplevert wat het moet opleveren. Niet als je hebt gezien dat de schermen laden.
Testscripts op basis van de analyse, niet op basis van aannames
Wie schrijft de testscripts, en op basis waarvan? Dit is waar het regelmatig misgaat bij organisaties zonder AFAS-ervaring.
We zien testscripts voorbijkomen die scenario's bevatten die technisch niet mogelijk zijn in AFAS. Een klassiek voorbeeld: er wordt getest wat er gebeurt als je een tekstwaarde invult in een bedragsveld. Dat kan AFAS gewoon niet. Een bedragsveld accepteert nooit tekst. Testen hierop is zinloos, en kost tijd die je beter ergens anders aan besteedt.
De basis voor goede testscripts is Simplr, het analysetool dat centraal staat in veel AFAS-implementaties. Daarin staat precies hoe de inrichting is gemaakt: welke knoppen waar staan, hoe processen zijn ingericht, welke afwijkingen ten opzichte van de standaard zijn vastgelegd. Pak die informatie erbij en verwerk hem één-op-één in de testscripts. Zo test je alleen wat er daadwerkelijk in jouw inrichting zit, en mis je niets wat wel relevant is.
AFAS levert ook standaard testscripts aan. Die zijn een goed vertrekpunt, maar ze zijn generiek. Ze moeten worden aangepast aan jouw specifieke inrichting. De keuzes die tijdens de analysefase zijn gemaakt, moeten terugkomen in de test. Een testscript dat de analyse niet spiegelt, test in feite iets wat je nooit hebt afgesproken.
Heb je intern iemand die AFAS al kent (een toekomstig beheerder of iemand die eerder met het pakket heeft gewerkt), betrek die persoon bij het beoordelen van de testscripts. Zij zien eerder welke scenario's realistisch zijn en welke niet.
De technische voorbereiding die testsessies stilleggen
Je hebt de planning klaar, de testscripts staan op orde, en dan begint de eerste testsessie niet. Niet omdat de inrichting niet deugt, maar omdat de testomgeving niet goed is klaargezet.
Functioneel beheer is verantwoordelijk voor die voorbereiding, en het vraagt meer dan een kopieer-actie. Denk aan: gebruikers deblokkeren, ze op de juiste plek in het organigram plaatsen, toegangsrechten controleren, InSite en OutSite publiceren, en de mailserver deblokkeren als je e-mailtemplates wilt testen.
Wat gaat er het vaakst mis? Twee dingen. De mailserver is niet gedeblokkeerd, waardoor je communicatie niet kunt testen. En gebruikers staan niet op de juiste positie in het organigram, zodat een leidinggevende niet de taken van zijn medewerker ziet, of iemand überhaupt niet kan inloggen. De testsessie begint dan met een kwartier troubleshooten in plaats van testen.
Reken op minimaal één tot twee uur voor het klaarzetten van een testomgeving. En weet: na elke testsessie worden bevindingen verwerkt in de live-omgeving, niet in de testomgeving. Die raakt dus meteen out-of-date. Voor elke nieuwe testsessie moet de omgeving opnieuw worden klaargezet. Plan dat in, samen met functioneel beheer, voordat de testfase begint, niet op de ochtend van de sessie zelf.
Vanuit onze begeleiding bij AFAS-implementaties zien we dat dit klaarzetmoment stelselmatig te laat op de agenda komt. Bij Covio zit het standaard in de planning, zodat de eerste minuut van een testsessie ook echt aan testen wordt besteed.
Een goede testfase staat of valt met voorbereiding, en die voorbereiding begint bij de start van de realisatiefase, niet een week ervoor. Met de juiste mensen, realistische testscripts en een technisch goed klaargezette omgeving verklein je de kans op verrassingen na livegang aanzienlijk.
Wil je dat Covio de testfase samen met je voorbereidt en begeleidt? We helpen organisaties bij zowel de opzet als de uitvoering. Neem contact op; we denken graag mee.