Testautomatisering heeft in de afgelopen jaren een grote groei en ontwikkeling doorgemaakt. Aanvankelijk was het aanbod beperkt en het gebruik ervan alleen weggelegd voor de kapitaalkrachtigen en techneuten, maar tegenwoordig is de tooling dermate toegankelijk geworden dat er nog maar weinig bedrijven zijn die niets op dit gebied doen. Ook met de sterke opkomst van de agile ontwikkelmethodiek is de inzet van testautomatisering nog meer in een stroomversnelling geraakt.
De implementatie van testautomatisering is een traject dat moeizaam kan verlopen en heeft in de loop der tijd bekende valkuilen opgeleverd op allerlei gebieden. Nieuwe ontwikkelingen hebben nieuwe inzichten daaraan gegeven, maar ook weer voor nieuwe valkuilen gezorgd. Om te voorkomen dat men in bekende valkuilen trapt, is het goed om ze onder de aandacht te blijven brengen.
In een tweedelige blog wil ik een tiental valkuilen benoemen en aangeven hoe je daarmee om zou kunnen gaan om ze te voorkomen. Deel 1 zal valkuilen behandelen die vooral in de beginfase van testautomatisering van belang zijn en in deel 2 zullen valkuilen behandeld worden die komen kijken als men daadwerkelijk tot implementatie van testautomatisering is overgegaan.
De Business Case
De inzet van testautomatisering wordt vaak vooraf gegaan door een business case. Vanuit de traditionele gedachten wordt altijd een ROI (Return On Investment) opgesteld op basis van de hoeveelheid test-uren die men denkt te kunnen besparen op de regressietesten.
Testautomatisering moet echter niet alleen gezien worden als een vervanging van handmatige testen, maar ook als kwaliteitsborging waarin geïnvesteerd moet worden. Zeker met de Agile ontwikkelmethodiek is testautomatisering een noodzakelijkheid geworden waarvan de inzet minder afhankelijk moet zijn van een ROI maar juist meer gedreven zou moeten zijn op het willen verhogen van de kwaliteit van de opleveringen.
De initiële verwachting zal zijn dat de kosten drastisch zullen dalen, maar in werkelijkheid zal vooral in het begin de investering juist hoog zijn. Dat maakt het des te belangrijker om een juiste inschatting te maken van wat men verwacht.
Geschiktheid van de organisatie
Veel organisaties denken testautomatisering te kunnen inzetten en gaan daarbij voorbij aan de vraag of de organisatie er wel geschikt voor is. Er zijn veel factoren die bepalen of de inzet van testautomatisering succesvol kan zijn of bij voorbaat al gedoemd is om te mislukken. Zijn de juiste mensen met de juiste kennis wel beschikbaar? Kennis op het gebied van o.a. geautomatiseerd testen en testtooling. Maar is er ook voldoende ondersteuning vanuit de organisatie?
Met behulp van het TPI (Test Process Improvement) model weet je snel genoeg of de ‘testorganisatie’ volwassen is en of deze al toe is aan de inzet van testautomatisering.
Het doel van de testautomatisering
Voor de inzet van testautomatisering zijn legio doelen te bedenken. Vaak zijn er nog verschillende partijen bij betrokken die ieder een ander doel nastreven. Denk aan management dat vooral de kosten zal willen drukken, de business die juist meer geïnteresseerd is in het waarborgen van de kwaliteit van het systeem en testers die het eigen werk eenvoudiger willen maken. Niet altijd zullen doelen samen kunnen gaan in de uitwerking ervan en zullen er dus keuzes gemaakt moeten worden.
Alvorens men met testautomatisering start moet het duidelijk zijn wat het hoofddoel is om zo de focus te kunnen houden. Dit doel moet breed gedragen worden en steun krijgen vanuit de organisatie. Gebeurt dit niet, dan is de kans op mislukking groot, omdat er gaandeweg keuzes gemaakt zullen moeten worden die per doel een andere gewenste uitwerking kunnen hebben.
Toolselectie
Met de juiste toolselectie valt of staat natuurlijk een belangrijk deel van de testautomatisering. Men zal in eerste instantie moeten bekijken of het te testen systeem zich leent voor testautomatisering en wat er dan precies noodzakelijk zal zijn in de te stellen eisen aan de testtooling.
Om tot een uiteindelijke toolselectie te kunnen komen, wordt vaak door meerdere leveranciers of hun partners een demo gegeven van hun tooling. De demo’s geven weliswaar een goed beeld van hoe de tooling werkt en wat het kan, maar als klant moet je absoluut kritisch blijven om later niet voor verrassingen komen te staan.
Tooling kan tegenwoordig enorm veel, maar wat men wil zal lang niet altijd op een eenvoudige wijze werken. Denk daarbij aan eventueel benodigd maatwerk waardoor de kosten enorm kunnen toenemen.
Het laten uitvoeren van een POC (Proof of Concept) geeft dan al meer indicatie van wat er mogelijk is en wat eventuele knelpunten kunnen zijn. Ook een POC is echter niet altijd zaligmakend, omdat een leverancier binnen een korte tijd moet aantonen dat de tooling overweg kan met de meest belangrijke onderdelen van het systeem van de klant.
Wees als klant altijd alert bij een demo of POC op hoe het een en ander met de tooling te bereiken is en stel kritische vragen. Zorg dat er bij dergelijke contactmomenten ook altijd een interne medewerker betrokken is die naast voldoende kennis van het eigen systeem ook voldoende technisch onderlegd is om te begrijpen wat wel/niet wenselijk is bij de realisatie van de testautomatisering.
De toegankelijkheid
Testautomatisering is met de tijd toegankelijker geworden, maar daarin schuilt ook gelijk een belangrijk gevaar om ondoordacht te werk te gaan. De inzet van specialisten lijkt dan immers minder noodzakelijk. Het is echter hun ervaring die het succes van de testautomatisering meer kunnen waarborgen en de juiste stappen kunnen nemen om valkuilen te vermijden.
Conclusie
In elke fase van het testautomatiseringsproces schuilen valkuilen. En het gevaar ligt daarbij al op de loer als er nog niet eens daadwerkelijk met testautomatisering gestart is. Het is daarom dan ook van groot belang dat men bij testautomatisering, hoe prematuur het ook nog kan zijn, gelijk voldoende aandacht eraan geeft omdat het niet zomaar iets is.
In deel 2 van mijn blog het vervolg op de valkuilen in de testautomatisering.