De laatste tijd implementeren steeds meer organisaties een testtool. Ze verwachten hiermee voordeel te behalen in termen van (doorloop)tijd, geld of kwaliteit. Helaas worden deze doelstellingen lang niet altijd gehaald. Een testconsultant vertelt waarom.
Veel organisaties zien het ‘automatiseren van het testen’ als oplossing voor het tijdrovende en dure testproces. Vooral de zogenaamde record- en playbacktools hebben een hoge vlucht genomen. Met deze tools worden testgevallen opgenomen en later weer afgespeeld. Een record- en playbacktool heeft zo zijn voordelen. Maar niet in alle gevallen. Interessant is natuurlijk de vraag wanneer die voordelen zijn te realiseren.
Om de introductie van een testtool succesvol te laten zijn moet, enkele uitzonderlijke situaties daargelaten, aan vier eisen worden voldaan: een gestructureerd en volwassen testproces, een stabiel product, het product dient lang mee te gaan, de implementatie en organisatorische inbedding moeten goed geregeld zijn. Deze eisen worden hieronder uitgewerkt.
Remedie
Allereerst dient het testproces gestructureerd en volwassen te zijn. Hoewel sommige tool-verkopers ons anders willen doen geloven, blijft het handmatige deel van het testproces aanvankelijk grotendeels overeind staan. Het creatieve proces dat daaraan vooraf gaat kan tot op heden niet worden geautomatiseerd. Hoogstens gestructureerd gedocumenteerd. Zo moesten we eens met onervaren testers een geautomatiseerd testproces in. Dat leidde tot een aantal willekeurige testgevallen die niet op elkaar aansloten. Daarnaast was er geen enkel inzicht in de dekkingsgraad, kon er geen enkele garantie worden gegeven over de werking van processen en was de testset niet gebaseerd op een teststrategie. De gevolgen laten zich raden: het automatiseren van chaos leidde tot geautomatiseerde chaos. Remedie: eerst het proces structureren, dan pas automatiseren. Een collega van mij gebruikt een simpele, maar zeer treffende vergelijking: je moet eerst kunnen rekenen voordat je een rekenmachine kan gebruiken. Ditzelfde gaat op voor testtools: je moet eerst (gestructureerd) kunnen testen voordat je testtools kan gebruiken.
Een andere belangrijke eis is dat het te testen product stabiel is. Met stabiliteit wordt bedoeld dat het product niet te veel (grote) wijzigingen meer mag ondergaan. Anders zijn de opgenomen testgevallen niet meer goed bruikbaar, aangezien die testgevallen leiden tot meldingen van wijzigingen die wel degelijk bedoeld zijn. Het afspelen van de testsets geeft onvoldoende indicatie van de kwaliteit van het nieuwe product, terwijl het opnieuw opnemen van de testgevallen weer veel tijd kost. Zo hebben wij een grote bank geadviseerd een testtool in te zetten. Het ging hier om het testen van een nieuwe versie van een systeem voor thuisbankieren. Het was niet alleen belangrijk vast te stellen of de wijzigingen goed waren doorgevoerd, maar ook of de ongewijzigde delen nog goed functioneerden. De uitrol van de nieuwe versie was een kostbare aangelegenheid. Het pakket moest naar alle klanten worden opgestuurd. Bij eventuele fouten zouden de herstelkosten dus erg hoog zijn. Vandaar het grote belang dat werd gehecht aan een kwalitatief bijzonder goede regressietest. Deze regressietest werd echter handmatig en steeds door andere testers uitgevoerd. Zeker gezien de hoeveelheid testwerk was het risico van menselijke fouten groot. Met de inzet van een record- en playbacktool kon in relatief korte tijd met hoge mate van zekerheid kon worden vastgesteld dat alle ongewijzigde functionaliteit nog correct werkte. Aan de voorwaarde dat het product stabiel moet zijn, werd in dit geval voldaan.
Organisatorisch ingebed
De derde eis die gesteld kan worden aan de inzet van een testtool is dat het gebruikt wordt om een product te testen dat een behoorlijk lange tijd moet meegaan. Achterliggende gedachte is dat de aanschaf van een testtool aanvankelijk een extra investering vergt, zowel in tijd als in geld. Om het gebruik van een testtool verantwoord te maken dienen er dus meerdere testen uitgevoerd te worden op een stabiel product, dat een behoorlijke tijd gaat worden gebruikt. Hoewel soms niet te voorzien is hoeveel nieuwe releases er worden uitgebracht, is het toch goed van tevoren bij deze vraag stil te staan. Bij één van de projecten waarbij we betrokken waren, werden testscripts opgenomen in een testtool. Dit uitgangspunt gold voor alle programmatuur, dus ook voor conversieprogrammatuur. Voor eenmalig gebruikte programmatuur lijkt het niet mogelijk de investering in een record- en playbacktool terug te verdienen, omdat hergebruik van de testscripts niet aan de orde is.
De laatste eis die dat de testtool organisatorisch goed moet zijn ingebed. Een goed begin is immers het halve werk. Veel organisaties hebben ervaren dat het inzetten van een testtool geen sinecure is. Ook het beheren en onderhouden vraagt het nodige van een organisatie. De pakketten zijn technisch vaak redelijk complex, zodat zowel de installatie als het beheer veel aandacht vragen . Als dit in één keer goed is geregeld, kan veel frustratie en dubbel werk worden voorkomen.
Daarnaast is het ook belangrijk dat de gebruikers opgeleid worden. Wat dat betreft verschilt het implementeren van een testtool niet veel van de implementatie van een standaardpakket. Wanneer de opleiding tekortschiet benutten de gebruikers niet alle mogelijkheden en zijn zij in hoge mate afhankelijk van externe deskundigen.
In dit kader dient ook de dienstverlening geregeld te worden. Is er een interne vraagbaak? Wat gebeurt er met vragen die niet direct beantwoord kunnen worden? Hoe is de ondersteuning van de leverancier?
De communicatie is eveneens een belangrijk aandachtsgebied. Vooral het menselijke aspect van automatisering van processen werd vroeger nogal eens uit het oog verloren. Voor de implementatie van testtools gaat dit ook op. Duidelijkheid over de doelstellingen en consequenties kan de acceptatie verhogen.
Opleidingskosten
Vaak wordt een testtool bij een (pilot)project geïntroduceerd. Het kan zijn dat de inzet zich niet goed verhoudt met de overige projectdoelstellingen. Een projectleider moet binnen een bepaalde tijd en hoeveelheid geld een product opleveren dat voldoet aan bepaalde kwaliteitseisen. Het aantonen dat een testtool meerwaarde heeft kan hiermee in strijd zijn. Het verdient derhalve aanbeveling de introductie van een testtool te laten plaatsvinden ten laste van een extern budget en het project te compenseren voor de gemaakte kosten.
Een testtool wordt in het algemeen ingezet met de bedoeling om de kosten te verlagen, de doorlooptijd te beperken of de kwaliteit te verhogen dan wel te handhaven.
In eerste aanleg is met de inzet van een testtool een aanzienlijke investering gemoeid, zowel in geld als in tijd. Het gaat hierbij niet alleen om de aanschafkosten. Ook de opleidingskosten kunnen aardig oplopen. Daarnaast kan er sprake zijn van organisatorische kosten. Bijvoorbeeld omdat het testproces moet worden aangepast en de tool moet worden beheers. In sommige gevallen is het inhuren van externe expertise noodzakelijk. Deze investering dient later terugverdiend te worden. Een leverancier van testtools gaf desgevraagd aan dat dat zeer twijfelachtig is. "Kosten mogen niet de belangrijkste overweging zijn om een testtool in te zetten".
In een testomgeving is de kwaliteit van zowel de test zelf (dekkingsgraad) als het proces (betrouwbaarheid, herhaalbaarheid en traceerbaarheid) bedoeld.
Testscripts
Om één van deze drie doelstellingen (kostenverlaging, doorlooptijdverkorting, kwaliteitsverhoging) te kunnen bereiken is een aantal aspecten van belang.
Kennis en ervaring. Naarmate er binnen de organisatie minder kennis over en ervaring met testtools en de onderliggende programmeertaal, zijn de initiële kosten hoger. Denk maar aan het opleidings- en inleertraject. Ook dienen de medewerkers programmeerkennis en -ervaring te hebben om het tool optimaal te kunnen gebruiken, beheren en onderhouden. Reken maar op een leerperiode van een half jaar.
Aantal hertesten. Het aantal hertesten dat het systeem ondergaat bepaalt in belangrijke mate de voordelen van de tool in tijd en geld. Het aantal hertesten is vaak af te leiden uit het aantal (geplande) releases. Op de vraag hoeveel hertesten nodig zijn om ‘positief’ uit te komen, hebben we hele verschillende antwoorden gekregen. De ene leverancier meende dat de investering na één iteratie al is terugverdiend, de andere dacht aan "enkele tientallen". Een aantal van mijn collega’s menen dat drie tot zeven iteraties voldoende zijn.
KZA heeft meegewerkt aan een millenniumtest waarbij de projectleider besloot een testtool in te zetten om de testinspanning te beperken. Er werd een oudtest (ongewijzigde applicatie), nieuwtest (gewijzigde applicatie, getest op datum voor de eeuwwisseling) en toekomsttest (gewijzigde applicatie, getest op datum na de eeuwwisseling) uitgevoerd. De conclusie was dat het gebruik van de testtool erg veel tijd had gekost en eerder een blok aan het been was geweest dan voordelen had opgeleverd. Het aantal iteraties was te laag om de voordelen van het testtool te benutten.
Hoeveelheid testwerk. Wanneer een applicatie vaak moet worden getest dan is een testtool eerder kostenneutraal of voordelig dan wanneer er af en toe eens wat testwerk ligt. Indien een grote hoeveelheid testdata moet worden getest met hetzelfde testscript dan is de inzet van een testtool mogelijk zelfs de enige oplossing. Bij het eerder gegeven voorbeeld van het thuisbankierpakket was er duidelijk sprake van grote hoeveelheden testwerk. Hierbij was het evident dat er een complete hertest moest worden uitgevoerd wanneer er een kleine wijziging werd doorgevoerd.
Herbruikbaarheid testscripts. Hoewel een open deur is, hebben we een keer waargenomen dat met de herbruikbaarheid van de testscrips geen rekening werd gehouden. Bij een millenniumtraject werd voor alle applicaties gebruik gemaakt van de testtool. Er waren echter ook specifieke datumtesten die na de millenniumovergang niet meer gebruikt zouden gaan worden. Ook deze testgevallen werden in het script opgenomen.
Doorlooptijd project. Dikwijls wordt in projectmatig verband overwogen testtools in te zetten. Doordat er vaak weinig iteraties gemaakt wordt op hetzelfde product, is het vaak voor projecten duurder om te werken met een testtool dan zonder. De eventuele voordelen in tijd kunnen pas worden geëffectueerd in de onderhoudsfase. Het is van groot belang dat de kennis, kunde en de producten, inclusief documentatie, goed worden overgedragen aan de lijnorganisatie wanneer het project beëindigd wordt. De lijnorganisatie kan dan optimaal gebruik maken van het de resultaten van het werk dat is verzet en zo de opgedane ervaring en de voordelen optimaal benutten. Helaas zien we maar al te vaak dat aan het einde van een project diverse bruikbare zaken niet overgedragen, dan wel niet geaccepteerd worden. Bij het eerder genoemde millenniumtraject gebeurde dit ook. Één van de argumenten van de lijnorganisatie was dat er geen geld was voor opleiding van de lijnfunctionarissen. De geautomatiseerde scripts staan op dit moment op een fileserver te verouderen.
Regressietesten. Worden bij nieuwe releases alle onderdelen volledig doorgetest of alleen die delen die aangepast zijn? Dit soort vragen zijn van belang bij de overweging om een testtool in te zetten.
Bij één van de grootste softwarehuizen van Nederland heeft men als beleid ten aanzien van nieuwe releases dat de nacht vóór de geplande uitlevering alle schermen automatisch geopend worden en weer afgesloten. Op deze manier weet men zeker dat alle onderdelen op de tape staan. Daarmee is volledigheid gedekt. Het integraal testen van het pakket zou vel te veel tijd vergen. Om marketing-technische redenen kiest men ervoor dat niet te doen.
Gewenste dekkingsgraad. Een ander aspect dat met de gewenste kwaliteit samenhangt is de vraag welke dekkingsgraad gewenst is. Is men met een lage dekkingsgraad tevreden, dan is een testtool niet altijd aan te bevelen omdat een beperkt aantal testgevallen dan voldoende is. Zeer hoge dekkinggraden zijn vaak alleen haalbaar als er zeer veel testgevallen zijn. De complexiteit van systemen kan in soms zo hoog zijn vanwege allerlei variaties en links, dat het gebruik van een testtool de enige mogelijkheid is een hoge dekkingsgraad, en daarmee een kwalitatief goede test, te krijgen.
Lange adem
Uit het voorgaande kunnen we afleiden dat het soms moeilijk is om uit de inzet van testtools voordelen op het gebied van geld en tijd te behalen. Een lange adem en goede organisatie zijn van groot belang. Daarom is kwaliteit hét argument om testtools in te zetten. Wanneer er testscripts zijn, het testproces goed beheerst wordt en het onderliggende systeem stabiel is, kunnen testen snel en foutloos herhaald worden. Zoals we in het voorbeeld van het thuisbankierpakket hebben gezien, was het eenvoudig om de hele applicatie integraal te testen. Een ander voordeel was dat de geautomatiseerde test foutloos werd uitgevoerd. Handmatig werk is nu eenmaal onderhevig aan fouten. Geautomatiseerd testen kan de betrouwbaarheid en reproduceerbaarheid van de test dus aanzienlijk verbeteren.
Het is belangrijk zich vóór de selectie en implementatie van een testtool te bezinnen op de doelstellingen. Vervolgens dient de organisatie, eventueel met hulp van een deskundige onafhankelijke partij, te onderzoeken of de doelstellingen realiseerbaar zijn. De aspecten die in dit artikel zijn behandeld, kunnen hiervoor handvatten bieden. Daarnaast dient vastgesteld te worden in hoeverre aan de eisen voldaan wordt. Door vooraf te analyseren of de organisatie klaar is voor een testtool en of alle randvoorwaarden zijn ingevuld kunnen teleurstellingen worden voorkomen. Vervolgens kan, eventueel nadat risico’s zijn aangegeven, een onderbouwde beslissing worden genomen.
Er is geen standaard antwoord mogelijk. De materie is dermate complex dat het maken van een eenvoudige beslissingsboom met een simpel ja of nee niet te maken is. Het formuleren van haalbare doelstellingen en het maken van een zorgvuldige afweging na grondig onderzoek is het belangrijkste.
H.J.J. Cannegieter, testconsultant en accountmanager KZA Kwaliteitszorg