Geautomatiseerd testen van pakketsoftware

Het testen van applicatiesoftware kent twee werelden. Technisch testen is het domein van de ontwikkelaars en erop gericht om software technisch en functioneel correct in productie te krijgen. Ketentesten betreft het daadwerkelijk functionele gebruik (aangeduid met end-to-end processen) van de onderliggende geautomatiseerde systemen met onderlinge koppelingen en de daarin vastgelegde data. Geautomatiseerd testen tijdens het implementeren van standaard pakketsoftware is geen gemeengoed.

Dit artikel gaat in op het geautomatiseerd uitvoeren van keten- en acceptatietesten, en dan in het bijzonder in het kader van implementatietrajecten voor standaard pakketsoftware zoals erp-, crm- of hrm-systemen. Met het geïntroduceerde beslismodel kunt je zelf bepalen of geautomatiseerd testen in jouw situatie een te onderzoeken optie is.

Een standaard pakket is toch al getest?

Een veel gehoorde aanname bij keuze voor een standaard bedrijfsapplicatie voor erp.crm of hrm ten opzichte van maatwerk is dat het testwerk aanzienlijk minder zou zijn, omdat het systeem zich al ruimschoots bewezen zou hebben in de praktijk. De praktijk wijst echter uit dat niets minder waar is: standaard pakketten betekent inderdaad minder softwareontwikkeling en dus technische testen, maar daarom juist relatief meer ketentestwerk. Want de ketenrisico’s zijn niet lager, eerder hoger en de keten zelf kan erg complex zijn. Goede ketentesten vergen een aanzienlijke inspanning, zowel qua voorbereiding als zeker ook qua uitvoering. Dit is een inspanning die in de regel geleverd moet worden door de kerngebruikers uit de business. 

Ter illustratie , een middelgroot, internationaal opererend, handels- en assemblagebedrijf met een op basis van Lean principes verregaand geoptimaliseerde bedrijfsvoering, investeerde voor de initiële implementatie in Nederland van een integraal standaard erp-systeem  ongeveer veertigduizend eigen uren (twintig manjaar) in totaliteit. Ruim 40 procent van deze tijd werd besteed aan testactiviteiten.

In het geval van het implementeren van pakketsoftware zijn uitvoerige ontwikkel- en functionele testen op moduleniveau niet meer nodig. Ervan uitgaande dat het pakket is gekozen op basis van een gedegen selectietraject zijn eventuele missende onvolkomenheden beoordeeld en afgewogen ten opzichte van andere pakketten voor de definitieve aanschaf van de oplossing. Het aangeschafte pakket is daarbij het beste compromis gebleken. Het testen dient zich te focussen op correcte inrichting en aansluiting op het proces. Overigens, voor eventueel toe te voegen maatwerk aan de standaard oplossing geldt, dat dit wel een unit test dient te ondergaan.

Automatiseren van testen

Kijkend naar soorten testen die gebruikt kunnen worden in een implementatietraject (zie kader) komt een aantal typen in aanmerking om geautomatiseerd te worden uitgevoerd. Het betreft testen die regelmatig moeten worden uitgevoerd, zoals keten- en acceptatietesten en regressietesten, en testen die over het algemeen veel capaciteit vragen of zich realistisch gezien niet lenen om handmatig uit te voeren. Denk aan performance testen waarin grote aantallen gebruikers worden gesimuleerd met behulp van tools.

In het typische implementatieproject van standaard software vormt testen een belangrijk onderdeel in alle fasen. Ook in de selectiefase, waarin de proof of concept (PoC) een vorm van testen is, met scenario’s, bevindingen, het neerzetten van een geschikte omgeving, enzovoort. Overigens wordt in de regel onderscheid gemaakt tussen checken en testen. Checken is het afvinken van een eenvoudige checklist en is relatief eenvoudig. Het echte ‘dynamisch testen’ vergt nauwkeurig opbouwen van testdata en het doen van bewerkingen (online, vaak ook batch) in een nauwkeurig bepaalde volgorde input – ketenstappen – output. De ervaring leert dat dit veel tijd in beslag neemt en  dus kosten met zich meebrengt. Volgens Gartner gaat aan testen vaak meer dan 50 procent van de tijd en geld in it-implementaties voor een belangrijk deel naar dit type dynamische testen.

Naarmate meer incrementeel/agile wordt gewerkt wordt bovendien de behoefte aan nog testen groter. Immers, elk increment (sprint) vraagt om een controle of alles wat tot nu toe goed functioneerde nog steeds correct functioneert. Heeft de progressie (‘coole’ nieuwe functies) niet geleid tot regressie (omvallen van bestaande functies en interfaces). Regressietesten, of zuiverder gezegd non-regressietesten, zijn bij uitstek geschikt om te automatiseren. Om diezelfde reden begint in Agile/Scrum-teams de Test Driven Development aanpak steeds meer ingang te vinden. Testen gebeurt dan ’upstream’ en is geen ‘downstream’ activiteit meer. In Agile-termen spreken we dan van ‘debt’: een schuld die ooit moet worden ingelost. De andere kant van de agile medaille is ‘customer interaction over processes and tools’ (een van de vier principes van het agile manifesto). Dat betekent dat we niet te snel naar tools moeten grijpen als silver bullet voor elk probleem. In de praktijk betekent dit wat ons betreft: de bouwer automatiseert zoveel mogelijk van zijn testen, de gebruikers en key users denken drie keer na voor ze eraan beginnen.

Testtoold

Met betrekking tot testtools is het voor standaardpakketten zaak om vooral naar tools te kijken voor de end-to-end-ketentest (e2e). In de lijst mist Selenium, maar die zit meer aan de ontwikkelkant en vraagt om serieuze programmeervaardigheden bij de gebruiker. Overigens, hiermee is niet gezegd dat eindgebruikerstools geen programmeerskills vergen. In eerste instantie kan een relatief a-technische tester met de luxe capture/playback (record/replay) voorzieningen van de huidige tools snel een set testscripts aanmaken. Als het testen serieuzer wordt, is waarschijnlijk meer nodig, denk aan scheiden van data en logica, modulaire opbouw, foutafhandeling en exception handling en speciale objecten en situaties testen die niet automatisch worden herkend. Hiervoor is technische know-how en programmeerervaring nodig. Geautomatiseerd testen wordt dan al gauw ‘een softwareproject erbij’.

De inzet van geautomatiseerde testtools lijkt steeds noodzakelijk te worden bij standaardpakket implementaties. Hierbij kunnen zowel de leverancier/implementatiepartner als de klant een aantal afwegingen maken:

1. De leverancier/implementatiepartner die met hetzelfde pakket/framework veel verschillende klanten bedient: investeer in een standaard regressietestset die alle processen/functies van het pakket afdekt, liefst in een e2e-context. Zet de testset zodanig op dat deze eenvoudig kan worden aangepast aan klantspecifieke inregeling.
2. De klant/gebruiker die regelmatig nieuwe releases/updates krijgt van de leverancier (zowel tijdens het implementatietraject, als tijdens de beheerfase) en die elke keer opnieuw wil valideren dat de business processen niet omvallen en bijvoorbeeld premies, facturen, heffingen, uitkeringen enzovoort exact kloppen.

Ook voor pakketimplementaties is geautomatiseerd testen het onderzoeken waard. Maak hierbij wel de juiste overwegingen, geautomatiseerd testen is geen quick-win, het is een serieuze investering en het is een softwareproject erbij!

Onderstaande tabel ondersteunt de keuze bij het maken van een afweging of investeren in geautomatiseerde teststools nuttig is. De tabel toont tien aspecten die daarbij in overweging genomen moeten worden. Is de score lager dan vijftien punten dan is het afbreukrisico waarschijnlijk te groot, een score van vijftien punten of hoger duidt erop dat het inzetten van geautomatiseerde testtools je implementatieproject van standaard software zou kunnen vereenvoudigen.

Onno Wasser, Arne Smedema, beide adviseur bij Mitopics en Egbert Bouman, expert en practice manager bij testspecialist Valori.