Een nieuw softwarepakket – zo test je dat!

De laatste jaren werk ik bij diverse opdrachtgevers steeds mee aan de implementatie van AFAS. Een softwarepakket dat uitgerold wordt bij een nieuwe klant van AFAS ter vervanging van een of meerdere huidige systemen. Tijdens deze implementatietrajecten werk ik vaak mee aan de acceptatie van het pakket door het uitvoeren van verschillende soorten testen. Net als alle pakketten biedt ook AFAS je functionaliteiten die standaard uitgerold worden en uiteraard door de eigen testafdeling getest zijn. Maar jouw organisatie is net zo uniek als alle organisaties in Nederland en dus past een standaardpakket nooit 100% op je werkwijzen en procedures. Sterker nog, om het pakket aan je wensen te laten voldoen wil je het liefst zoveel mogelijk aanpassingen aan de standaard mogelijkheden doen zodat je de kritische eindgebruikers tevreden kunt stellen. Maar een standaardpakket is een standaardpakket, dus wat let je om je bedrijfsprocessen zo te optimaliseren dat ze wel aansluiten bij een standaard werkwijze.

AFAS richt voor je organisatie het systeem in met haar best practices, waarmee je na een goede acceptatietest live gaat op een bepaalde datum. Een goede acceptatietest valt en staat bij heldere requirements bijvoorbeeld vanuit je programma van eisen. Hierbij is het van belang om te bepalen wat de scope is waarmee je op de afgesproken datum live gaat. Welke bedrijfsprocessen zijn zo duidelijk dat ze meegenomen worden en welke moeten nog op de tekentafel gelegd worden? Niet geheel duidelijke processen houd je dan het liefst buiten de scope, zodat je hier rustig over na kunt denken en deze mee kunt nemen in een latere fase. En met je, bedoel ik jouw organisatie samen met de kerngebruikers van het systeem, die je zo vroeg mogelijk betrekt bij het opstellen van de requirements en het in kaart brengen van de risico’s.

De kracht van in dit geval AFAS is dat het de inrichting van het systeem samen met beheerders van de eigen organisatie doet. Dit om de kennis van het eigen pakket te bundelen aan de kennis van de organisatie en haar huidige systemen via die beheerders. De inrichting van een pakket bestaat vaak uit het converteren van gegevens, het inrichten van de werkprocessen en het leggen van koppelingen met andere systemen. Door de kerngebruikers bij de start te betrekken ligt er een stevige basis voor het opstellen van een goed testplan voor de uitvoering van de verschillende testsoorten.

Welke testsoorten of -vormen zou je kunnen doen bij de implementatie van een softwarepakket?

• Conversietest; het reviewen van de gegevensbestanden die als basis dienen voor de conversie van het oude naar het nieuwe systeem. Dit is niet altijd nodig wanneer data rechtstreeks uit een systeem getrokken wordt, zoals bijvoorbeeld bij een overgang van Youforce naar AFAS. Nadat de gegevens naar de testomgeving van je nieuwe pakket zijn geconverteerd toets je of de uitval wellicht eigen datafouten zijn, zodat je deze kunt herstellen. Daarnaast vergelijk je de data in het nieuwe systeem met die uit het oude systeem.
• Systeemtest; het toetsen of de ingerichte bedrijfsprocessen werken volgens de afgesproken functionele eisen. Het is goed om deze test te laten doen door een onafhankelijke partij, niet de ontwikkelaars zelf, maar ook niet de kerngebruikers. De laatste groep is namelijk vaak snel vergeten wat er bij het opstellen van de requirements is afgesproken en toetst het aan de eigen verwachtingen met kennis van het oude systeem.
• Acceptatietest; het testen met kerngebruikers voor de functionele kant en het testen met eindgebruikers voor de werking van het pakket. Voldoet het aan de verwachtingen en is het voor de ontvangende partij werkbaar en begrijpelijk.
• Usability test; het testen van het gebruik van de pagina en de ‘look and feel’ kun je onder de noemer acceptatietest houden, maar het is goed om het nieuwe pakket en het gebruik ervan door een usablity expert te laten beoordelen. Dit kunnen natuurlijk gewoon medewerkers van marketing, communicatie of zelfs HRM zijn.
• Integratietest; het testen of de aangesloten systemen technisch werken, maar ook of de geleverde data op de goede manier verwerkt kan worden, zoals dat bij het huidige systeem het geval is. Vaak wordt dit onderschat, want koppelingen doen het meestal wel. Maar wat is er vervelender als na livegang een nieuwe medewerker niet kan beschikken over een mailadres en inloggegevens, omdat de koppeling toch niet helemaal werkt.

Kortom testen bij een pakketimplementatie is vooral mensenwerk. Betrek je kern- en eindgebruikers zo veel mogelijk en zo vroeg mogelijk. Het draagt bij aan een breed gedragen applicatie met mensen die niet geheel vreemd zijn van het nieuwe pakket. Weerstand zal er altijd zijn, maar hoe minder weerstand hoe beter. Naast mensenwerk draagt tooling ook bij aan een fijn testtraject. Bij de laatste twee testtrajecten met gebruikers heb ik gebruik gemaakt van Testmonitor. Dit is een handige testtool om je requirements en risico’s te beheren, om van daar uit laagdrempelige testsets te ontwikkelen die kunnen leiden tot goede testresultaten. Over tooling schrijf ik later meer. Mocht je meer willen weten over het testen van AFAS of een ander pakket of het gebruik van Testmonitor als tool, stuur dan een bericht of een mail naar Richard Vrieling.

Veel succes!!

Alle initiatieven