Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het redactionele gedachtegoed van de redactie.

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.

Testen van software: soorten testen

Testen door de ‘bouwer/inrichter’ van het systeem (implementatiepartner) c.q. de it-afdeling:

  • Unit test: (geïsoleerd) testen van specifieke stukken code.
  • Smoke test: snelle test om te controleren of alles goed lijkt te functioneren, alvorens een volledig testtraject te starten.

Testen door de ‘gebruikers’ van het systeem (key users):

  • Acceptatietest: testen of een functie c.q. het gebruik correct wordt uitgevoerd. Onderscheid wordt gemaakt in:
    • FAT Functionele Acceptatie Test: controleren of het system volgens specificaties werkt;
    • GAT Gebruikers Acceptatie Test: controleren of het systeem de bedrijfsprocessen correct ondersteunt
    • BDT Business Day test: Kan een tweeledig doel dienen, het simuleren van een standaard werkdag met oog op (1) performance (gedurende een bepaalde periode op de dag gelijktijdig inleggen Verkooporders met hele afdeling) en (2) test op kennis en vaardigheden van eindgebruikers

Testen door de ‘gebruikers’ van het systeem (key users) in samenwerking met de ontwikkelaars c.q. technici:

  • Keten- (ook integratie- of end-to-end) test: testen of nieuwe delen software correct werken in interactie met de overige delen van het systeem.
  •  (Non-)regressietest: testen of de bestaande functionaliteit nog steeds functioneert na het doorvoeren van wijzigingen

Overige testen

  • Mass test: testen met productiegegevens om aan te tonen dat het systeem grote volumes kan verwerken met mogelijk veel uitzonderingen
  • Performance test: testen of het systeem binnen de opgegeven en/of acceptabele grenzen blijft qua performance

Specifieke checks:

  • ‘Canary’ test: geautomatiseerde, niet-destructieve test die regulier wordt uitgevoerd in een live-omgeving. Als deze test faalt, is er in de regel iets bijzonder ernstigs gebeurd met het systeem.
  • PVT Productie Verificatie Test of Pre-flight check: Test die worden uitgevoerd in een productie-achtige omgeving ter voorkoming van het ‘op mijn systeem werkte het wel’ syndroom.

Testkretologie: ‘White box’ testen betekent dat de input en de output bekend zijn, evenals de werking van het systeem die ook geïnspecteerd kan worden. Bij ‘Black box’ testen is de input bekend en bekend wat de output zou moeten zijn. Unit testen is in deze lijst de enige vorm van ‘White box’ testen.

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.




 

Succesfactoren

Weging

 

 

 

A

Applicatie-inrichting en keten stabiel

Als de applicatie voortdurend verandert dan wordt de onderhoudslast (scripts voortdurend aanpassen) te groot.

De applicatie-inrichting, maatwerk en keten zijn compleet en stabiel en veranderen niet meer wezenlijk.

4 pt

 De applicatie-inrichting, maatwerk en keten zijn grotendeels gedaan maar moeten nog in Operatie gevalideerd worden.

2 pt

De applicatie-inrichting, maatwerk en keten zijn werk in uitvoering.

0 pt

B

Volwassen Testproces

Automatiseren van de chaos is ‘faster disaster’. Zorg voor een ‘Risk Based’ testset, anders krijg je een triviale testset die niet de echte risico’s dekt.

Er ligt een grondige risicoanalyse aan het testplan ten grondslag

3 pt

Er ligt beperkte risicoanalyse aan het testplan ten grondslag

1 pt

Er ligt geen expliciete risicoanalyse aan het testplan ten grondslag

0 pt

C

Stabiele (keten)testomgeving

100 % stabiliteit is essentieel want geautomatiseerd is gevoelig voor kleine afwijkingen

De testomgeving inclusief de interfaces zijn compleet, gedocumenteerd getest en stabiel en hebben 1 of meer dedicated beheerders

3 pt

De testomgeving is deels stabiel en er is geen formele dedicated beheerder

1 pt

De testomgeving is niet  gedocumenteerd, niet getest en er is geen formeel beheerplan

0 pt

D

Verwacht aantal keer herhalen minimaal 8

Investering in testtools loont alleen als je de test vaak herhaalt. De consensus ligt rond de 8 keer.

De te automatiseren testeset zal > 8 keer worden herhaald het komende jaar

3 pt

De te automatiseren testeset zal > 5 keer worden herhaald het komende jaar

1 pt

De te automatiseren testeset zal < 5 keer worden herhaald het komende jaar

0 pt

E

Technische know-how  beschikbaar

Testautomatisering implementeren is ‘een softwareproject erbij’ en vraagt om programmeerskills.

Er is iemand met veel skills, of meerdere medewerkers met goede skills

2 pt

Er zijn enkele personen met programmeerervaring

1 pt

Er is niet of nauwelijks programmeerervaring

0 pt

F

Pakket onder de motorkap stabiel

Testtools interfacen (meestal!) via ID’s of andere kenmerken van de onderliggende software objecten. Als die bij nieuwe releases veranderen dan doen je scripts het niet meer.

Design en object ID’s onder de motorkap zijn vast en veranderen niet met nieuwe releases.

2 pt

 Design en object ID’s onder de motorkap zijn niet stabiel en kunnen veranderen met nieuwe releases.

0 pt

G

Referentieel integere set (keten)testdata

Zonder goede testdata kun je niet geautomatiseerd testen

Aparte sets testdata voor > 80% aanwezig

2 pt

Testdata voor > 40% aanwezig

1 pt

Testdata nog niet aanwezig

0 pt

H

Testscenarios  beschikbaar

Dekkende set scenarios die geschikt zijn om te scripten.

Testscenario’s zin al >80% gereed

1 pt

Testscenario’s zijn er nauwelijks of niet

0 pt

I

Testtoolkennis aanwezig

A fool with a tool is still a fool.

Er is iemand met veel ervaring met beoogde tool(s) of er zijn meerdere personen met toolervaring

3 pt

Er zijn enkele personen met ervaring

1 pt

Er is niet of nauwelijks ervaring

0 pt

J

Testtool is reeds geselecteerd of geïmplementeerd in de organisatie

Tools is er al of met een tool is al veel ‘check’ ervaring of een goede POC gedaan.

Implementatie gereed

2 pt

Selectie gereed

1 pt

Niet aanwezig

0 pt

 

TOTAAL

Max 25

 

Indien score lager is dan 15 pt, dan is het afbreukrisico van geautomatiseerd testen groot

Jouw score

 
 
 
 
Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5437984). © Jaarbeurs IT Media.
?

 

Reacties

Leuk om te lezen. Nog wel een paar aanvullingen.
Ik mist het testen van de SOAP/API laag (Test Automation Pyramid van Mike Cohn). Samen met de unit testen zou dit idealiter 75% van de geautomatiseerde testen moeten zijn. Daarnaast vind ik het raar dat Selenium webdriver als een tool voor 'programmeurs' wordt genoemd. Dit is verreweg de meest gebruikte library voor het automatiseren van testen.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×