Waaraan herken je een krachtig tool voor geautomatiseerd testen?

Auteur: MartinGijsen ● martin@deanalist.nl
Steeds meer mensen weten het al, soms helaas uit eigen ervaring: in tegenstelling tot wat nog veel wordt gedacht is het niet de keuze van het testtool dat het succes van geautomatiseerd testen bepaalt. Zo kan één project er succesvol mee zijn en een ander niet, terwijl ze vergelijkbare systemen ontwikkelen met de marktleider onder de testtools. Alleen een ‘goed’ tool is dus niet voldoende. Een tool kan wel meer of minder goed passen bij een organisatie of project en daarmee de kans op succes verhogen of verlagen, maar er komt nog wel wat meer bij kijken.
Dit artikel behandelt enkele factoren die belangrijk zijn om effectief geautomatiseerd te testen en hoe tools dat kunnen ondersteunen. Specifiek zal worden gekeken naar de PowerTools, een suite van gratis opensourcetools voor geautomatiseerd testen, die in steeds meer projecten worden gebruikt en die op 17 september 2013 centraal staat in een symposium met gebruikerservaringen (zie onderaan dit artikel).
Vier factoren die zeker beschouwd dienen te worden om tot effectief geautomatiseerd testen te komen, worden wel de PuPPeT factoren genoemd: People, Processes, Policies en Technology, oftewel Mensen, Processen, Beleid en Technologie. Het belang en de mogelijke invullingen van elk hiervan worden hieronder uitgewerkt.
Mensen
Hoewel het tool hopelijk de test gaat uitvoeren, zijn het nog steeds mensen die het tool moeten vertellen wat het moet doen. Het schrijven en het automatiseren van testgevallen zijn nogal van elkaar verschillende activiteiten die nogal verschillende vaardigheden vragen. Voor goede testgevallen heb je testvaardigheden nodig en die vind je vooral bij testers. Aangezien te veel onderhoudswerk een veel voorkomend en ook nog eens ernstig probleem is bij geautomatiseerd testen, is voldoende aandacht voor het beperken hiervan van groot belang. En dat vraagt juist software engineering vaardigheden, die we doorgaans meer bij ontwikkelaars vinden.
Automatiseerbare testgevallen moeten begrijpelijk zijn voor alle testers die ze moeten lezen, schrijven of onderhouden, gedurende de hele levensduur van het product. Dat betekent niet alleen dat ze er niet te ‘technisch’ uit moeten zien, maar ook dat het abstractieniveau hoog genoeg gekozen moet worden. Daardoor worden testgevallen (veel) compacter en dus overzichtelijker dan wanneer elke klik wordt uitgespeld. Een groot deel van de invulling van het fysieke testgeval komt dan dus niet expliciet in de geautomatiseerde test tot uitdrukking. Dit zal ook sterk duplicatie van testlogica verminderen en daarmee het onderhoud aan de testgevallen.
Door abstractere testgevallen komen veel details onder de motorkap terecht, in de implementatie van de testinstructies. Dit betekent dat een ervaren automatiseerder ervoor kan zorgen dat die logica zo gestructureerd wordt dat deze niet meer onderhoud zal vragen dan noodzakelijk. Dit blijft overigens belangrijk als een testtool een sexy GUI heeft, met drag & drop en zo. Hergebruik van logica (en eventueel ook data) is dan nog steeds essentieel om te veel onderhoud als gevolg van duplicatie te vermijden.
Een tool is dus niet zozeer krachtig te noemen als het alleen eenvoudig in het gebruik is. Natuurlijk is dat wel fijn. Het is zeker van belang dat een tool bij het opstellen van testgevallen niet omslachtig werkt of ‘technischer’ is dan noodzakelijk. Dit betekent namelijk niet alleen dat meer testers het tool zullen kunnen gebruiken, maar ook dat een tester zich daarbij kan concentreren op zijn vak, testen, in plaats van afgeleid te worden door techniek. Maar een tool moet ook ondersteunen dat een tester de automatisering van een testgeval kan overlaten aan een ander, omdat die het mogelijk veel beter (of sneller, of allebei) kan. Het is dan ook belangrijk dat een testgeval in automatiseerbare vorm kan worden opgesteld zonder dat (van tevoren of tegelijkertijd) de implementatie ervan moet worden gemaakt. Dit wordt niet door alle tools ondersteund.

De PowerTools hebben (nog) geen eigen schil om tests in te schrijven, onderhouden en uitvoeren. Ze laten de tester daarom gebruikmaken van FitNesse of Excel, twee populaire manieren om geautomatiseerde tests te schrijven. Instructies in Excel bestaan uit keywords, met de instructie in de eerste kolom en argumenten (testdata) in volgende kolommen. In FitNesse kunnen instructie en testdata in een vrij normaal lezende zin worden gecombineerd. Daarnaast worden ook de compacte data-driven tests ondersteund, waarbij testregels alleen testdata bevatten en data en logica van een test dus volledig gescheiden zijn. Ten slotte is het eenvoudig ondersteuning voor een eigen invoerformaat toe te voegen. In combinatie met het feit dat instructies door een tester zelf gekozen kunnen worden, zijn de PowerTools sterk in het uitdrukken van leesbare tests. Vandaar ook de naam, overigens een suggestie van Dorothy Graham. Testinstructies kunnen naar wens worden geprogrammeerd in Java of gescript in dezelfde vorm als de test. Een combinatie van beide kan ook.
Processen
Geautomatiseerd testen speelt een voorname rol binnen de Agile ontwikkelprocessen die je steeds vaker tegenkomt, maar wordt uiteraard ook in traditionele processen toegepast. In beide gevallen laat een scheiding van het werk in testen en automatiseren deze taken beter passen bij de vaardigheden van de diverse teamleden. Ook kan gelijktijdig testen en automatiseren de doorlooptijd van het automatiseren verkorten. Of de acceptatietest binnen of buiten een sprint moet worden geautomatiseerd is afhankelijk van een aantal factoren, maar automatiseren binnen de sprint heeft als voordeel dat iedereen aan stories van dezelfde ene sprint werkt.
Als testgevallen zowel handmatig als geautomatiseerd worden uitgevoerd, kan het logisch lijken een fysiek testgeval eerst in tekst uit te schrijven, het daarna te automatiseren en vervolgens beide versies naast elkaar te laten bestaan. Dit is meestal onverstandig en wel om twee redenen. Om te beginnen betekenen twee versies van hetzelfde testgeval dubbel onderhoud, aangezien beide actueel moeten worden gehouden om nuttig te zijn. Maar daarnaast zullen de beide versies na verloop van tijd niet meer consistent zijn. Ik vermoed dat dit een natuurwet is. Het gevolg hiervan is bijvoorbeeld dat iemand die de tekstversie van het testgeval leest, kan constateren dat het met de eisen overeenkomt, zonder te merken dat de geautomatiseerde test iets anders doet. Dat werkt niet fijn.
Men kan natuurlijk de tekstversie weggooien nadat deze is geautomatiseerd, maar dat vergt nog steeds dubbel werk dat kan worden voorkomen. Het is praktischer een testgeval meteen een vorm te geven die kan worden geautomatiseerd. Hiervoor zijn (high level) keywords heel geschikt. Als het hogere abstractieniveau van een keyword details van de test zou verbergen die duidelijk moeten blijven, kan worden voorkomen dat ze verloren gaan door ze in de omschrijving van het keyword op te nemen. De testgevallen en omschrijvingen van keywords samen kunnen dezelfde hoeveelheid informatie bevatten als uitgewerkte handmatige testgevallen (maar met minder saaie en onderhoudsgevoelige herhaling).
Moderne technieken sluiten hier niet alleen bij aan, maar kunnen ook de zo belangrijke link met de specificatie leggen. Zo wordt bij BDD (Behaviour Driven Development), wat overigens een specificatietechniek is, het gewenste gedrag van een systeem uit user stories nader uitgewerkt in een goed te automatiseren vorm (Given-When-Then). Specification by Example is wat flexibeler maar vergelijkbaar.

Tools die dateren van vóór de tijd dat Agile populair werd, ondersteunen Agile processen zoals Scrum en Kanban mogelijk niet (of niet goed genoeg). Daarentegen kan de ondersteuning van het testmanagement weer (te) beperkt zijn bij nieuwere  tools, vooral open source. Daar bestaat dan wel weer de mogelijkheid die zelf uit te breiden. Andere punten zijn versiebeheer en het tegelijk kunnen werken aan hetzelfde bestand, waar opensourcetools juist vaak sterk in zijn. Hoe dan ook, het keyword concept dat veel tools aanbieden, geeft qua proces veel flexibiliteit op het gebied van automatisering.
De PowerTools zijn gebaseerd op het keyword concept dat velen al goed kennen en past in (waarschijnlijk) elk proces. Vooral een aanpak met tests in FitNesse tests en code in Java, beide platte tekst, past prima in een standaard oplossing voor versiebeheer. Koppelingen met andere systemen, zoals testmanagement, zijn eventueel eenvoudig toe te voegen.
Beleid
Het beleid van een organisatie of project heeft vooral invloed op de keuze van de testtooling. Zo hebben heel wat organisaties, ook buiten de overheid, tegenwoordig een voorkeur voor open source. En niet alleen vanwege de licentiekosten van commerciële tools, maar bijvoorbeeld ook vanwege de soms uitstekende ondersteuning vanuit de gemeenschap of om de uitbreidbaarheid van de testoplossing. Daar staat wel tegenover dat bepaalde activiteiten mogelijk meer tijd kosten bij opensourcetools, vooral als die nog niet zo’n gebruikersvriendelijke interface hebben.
Soms hecht men vooral waarde aan gegarandeerde support. Maar dat voor open source geen gegarandeerde support beschikbaar zou zijn, gaat in het algemeen niet op. Ook voor opensourcetools is vaak wel een partij te vinden die gegarandeerde support wil bieden. Daarnaast geven de vele teleurstellende ervaringen met de support voor sommige commerciële tools aan dat het belangrijk is uit te vinden wat voor support er echt te verwachten valt nadat de sales meneer met een handtekening onder het contract het pand verlaten heeft. Dit omvat overigens niet alleen het krijgen van antwoorden en bug fixes, maar kan ook het vlot ondersteunen van nieuwe technologie omvatten.
Een punt dat ook onder beleid kan vallen is het toekomstvast maken van oplossingen, zodat de organisatie nog lang voordeel kan oogsten van de gedane investeringen. Hiervoor is het nuttig om bij geautomatiseerd testen een duidelijke scheiding te hebben in testtaken en (technischere) automatiseringstaken. Dit geldt ook, misschien nog wel sterker, als er een ‘local hero’ beschikbaar is die beide beheerst en alles doet. De afhankelijkheid van één persoon met een ongebruikelijke combinatie van vaardigheden is riskant. Het gevaar bestaat namelijk dat deze de automatisering zo opzet dat het voor hem prima werkt, maar de meeste testers er niet mee kunnen werken. Het komt geregeld voor dat zo iemand op een gegeven moment niet meer beschikbaar is door bijvoorbeeld ziekte of doordat het gras elders groener lijkt. De kans is groot dat dan de hele testautomatisering snel omvalt en nooit meer overeind komt met als gevolg dat de erin gedane investering vervolgens niets meer oplevert.
Het beleid kan ook vragen het aantal tools, frameworks en dergelijke, dat binnen de organisatie wordt gebruikt te beperken, zodat onder andere opgedane kennis en ervaring ermee waarde heeft in andere projecten. Een enkel tool dat alle relevante applicaties aankan, is één manier om dit te bereiken. Een andere insteek, die ook flexibel genoeg is om ontwikkelingen in de toekomst op te vangen, is te kiezen voor een tool dat eenvoudig uit te breiden is met (eigen) modules. Opensourceoplossingen doen dit vaak door het uitvoeren van en rapporteren over een test over te laten aan een generieke ‘test engine’, die naar wens te combineren is met één of meer interfacing modules. Die interfacing modules zijn vaak aparte tools met een API, zoals Selenium. Zowel de engine als de interfacing modules zijn generiek, oftewel onafhankelijk van het te testen systeem en daardoor bruikbaar voor veel situaties en systemen.

De open source PowerTools  (licentie: AGPLv3) bestaan uit een engine en een aantal interface modules. Ze werken samen met andere opensourcetools zoals FitNesse en Selenium. Daarnaast zijn er op verzoek ook gegarandeerde support en andere licenties beschikbaar. De PowerTools passen dus in het beleid van veel organisaties.
Technologie
Op het gebied van technologie is er een aantal aandachtspunten. Om te beginnen is het wenselijk dat via alle interfaces van het systeem kan worden getest. Bij het opsommen van interfaces is het belangrijk niet te snel tevreden te zijn. Een paar voorbeelden:

• Een webapplicatie kan normaal gesproken prima worden getest met het opensourcetool Selenium, maar daarmee kan alleen de pagina in de browser worden bediend. Als er vanuit de applicatie een bestand moet worden geselecteerd of opgeslagen, wordt er doorgaans een functie van het besturingssysteem aangeroepen. En daar kan Selenium niet mee overweg. Als dat ook nodig is, kan er een tool worden gekozen dat beide ondersteunt. Ook kan er een combinatie van tools worden gekozen die kan samenwerken, wat betekent dat minstens één van die tools een API moet hebben die vanuit een ander tool kan worden aangeroepen.
• Iets dergelijks geldt bij technologieën als flash, die in een webpagina kunnen worden opgenomen. Opensource- en commerciële tools die geschikt zijn voor webapplicaties ondersteunen wel altijd HTML, maar niet noodzakelijkerwijs die embedded technologie.
• Hoewel handmatig testen via de gebruikersinterface natuurlijk niet kan worden overgeslagen, is het waar mogelijk vaak praktischer om geautomatiseerde tests via ‘technischere’ interfaces uit te voeren. Bijvoorbeeld via webservices of SQL-queries of een combinatie hiervan. Dit heeft als voordeel  dat de vaak frequente wijzigingen aan de gebruikersinterface veel minder onderhoud aan de tests meer zullen veroorzaken. Daarnaast versnelt dit de uitvoering van de test vaak enorm. Overigens hoeven testgevallen er hierdoor niet ´technischer´ uit te gaan zien. Als ze op een voldoende hoog abstractieniveau zijn opgesteld, zijn ze functioneel van aard en komen er geen interface details in voor. Dan maakt het niet uit welke van de bruikbare interface voor de implementatie ervan wordt benut.

Een ander aspect van technologie om rekening mee te houden is de programmeertaal of –talen waar een tool mee overweg kan. Als hiervan gebruik zou worden gemaakt, dient het tool een taal te ondersteunen waarmee men in de organisatie vertrouwd is. Dan kunnen reeds aanwezige kennis en ervaring meteen effectief worden ingezet en worden er sneller resultaten zichtbaar.
Conclusie
Er zijn heel wat factoren waarmee rekening kan worden gehouden om geautomatiseerd testen tot een (groter) succes te maken. Hoewel bij vele hiervan het tool een rol speelt, is het duidelijk niet voldoende dat het tool technisch gezien geschikt is voor een applicatie. Een tool is alleen maar echt krachtig voor een project als het tool wat de PuPPeT factoren betreft past bij het project. De PowerTools hebben in dit verband veel te bieden.
PowerTools symposium
Op dinsdag 17 september 2013 zullen PowerTools gebruikers uit drie projecten over hun ervaringen ermee vertellen op een symposium. Dit evenement vindt plaats in het Vechthuis te Utrecht en duurt van 15:00 tot 17:00, met aansluitend een borrel. Deelname is kosteloos, maar in verband met de catering is registratie vereist. U kunt registreren door een e-mail te sturen naar powertools@deanalist.nl. Ook belangstellenden uit uw netwerk zijn van harte welkom.