Licentiekosten zijn niet de enige kosten van een tool. Ook andere factoren moeten van tevoren worden meegewogen, anders bestaat de kans dat je uiteindelijk te veel betaalt en te weinig krijgt. Een belangrijk deel van de beschreven ideeën is afkomstig van mede-auteur en Squerist-collega Roland van Leusden.
In een toolselectieproces moeten alle factoren meegenomen worden die later een rol gaan spelen, tijdens de implementatie en het gebruik. Alleen als al deze factoren worden meegenomen, kan er een juiste keuze worden gemaakt. In dit artikel focussen we op toolselectie voor testautomatisering en performance testen. Aangezien het bij automatische testuitvoering van het allergrootste belang is dat de tool goed aansluit bij de applicatie die getest wordt, is het belangrijk om de tool en de applicatie daadwerkelijk aan elkaar te koppelen in een proefopstelling. Het testen van de tool in combinatie met de applicatie wordt vaak een proof of concept (POC) genoemd. Alleen als commerciële en open source tools op dezelfde manier worden beoordeeld, kun je de tool kiezen die het beste past in jouw situatie.
Kosten en licenties
Behalve de initiële licentiekosten kunnen ook andere kosten bij open source tools lager uitvallen. Open soucre tools stellen bijvoorbeeld vaak minder hoge eisen aan de hardware. De definitie van open source is niet dat er geen licentiekosten zijn. Ontwikkelaars mogen wel degelijk licentiekosten vragen en doen dat in de praktijk soms ook. Open source betekent dat de broncode beschikbaar is. Hierdoor is het mogelijk om de software naar eigen behoefte aan te passen.
Open source software is bechikbaar onder diverse licenties. De twee meest gebruikte zijn de BSD (Berkeley Software Distribution), die de gebruiker geheel vrij laat, en GPL (General Public License). Bij de GPL is de gebruiker verplicht om de door hem gewijzigde broncode aan de open source gemeenschap beschikbaar te stellen. Sommige tools hanteren weer andere licenties en het is raadzaam om te controleren of commercieel gebruik wel is toegestaan.
Toeters en bellen
Commerciële software is vaak verder uitontwikkeld dan open source software en biedt meer extra's. Deze extra's variëren van installatiewizards en betere gebruikershandleidingen tot meegeleverde voorbeelden en rapportage-templates. Vaak ook ondersteunen commerciële tools meer platforms. De open source tooling richt zich op de webgebaseerde protocollen zoals http/s, imap en pop3, terwijl commerciële tooling ook de oudere client server-protocollen ondersteunt. Wel is er een tendens zichtbaar dat ook de oudere applicaties van een webfrontend voorzien worden. Maar de backend is vaak nog een ouwe, trouwe mainframe die er over tien jaar misschien nog steeds staat.
Eén van de belangrijkste extra's van een tool is de gebruikersondersteuning die erbij hoort. Als er zich een probleem voordoet, zal de leverancier het voor je oplossen. Dit kan een tijdje duren, maar je hoeft er in ieder geval niet meer aan te denken. Bij open source tooling zul je zelf naar een oplossing moeten zoeken. De open source gemeenschap kan je eventueel helpen, maar uiteindelijk is het jouw probleem. Wanneer je kiest voor open source tooling moet je er rekening mee houden dat er meer tijd nodig kan zijn om de tool up en running te krijgen. Als je dit onderschat, kan de open source tool achteraf duurder blijken dan zijn commerciële evenknie. Aan de andere kant, als je eventuele problemen aankunt, waarom zou je dan betalen voor extra's die je niet nodig hebt?
Bij open source tooling is het doen van een POC nog belangrijker dan bij commerciële tooling, omdat de documentatie niet altijd even goed is en de installatie vaak lastiger is. Open source gemeenschappen focussen zich meestal meer op functionaliteit en minder op installatie-wizards.
Tools en infrastructuur
Een POC is ook nuttig om de testresultaten van de verschillende tools met elkaar te vergelijken. Testtools zijn uiteindelijk ook software en bevatten dus bugs, die op elk moment kunnen toeslaan.
We hebben een experiment gedaan met Webload, OpenSTA en LoadRunner. Deze tools werden op dezelfde pc geïnstalleerd en alledrie voerden ze hetzelfde scenario uit, in een geïsoleerd setting, niet verbonden met het bedrijfsnetwerk. Bij metingen met één virtuele gebruiker werden er verschillen gevonden van 30 procent in de gerapporteerde responsetijden. Dit experiment maakt duidelijk dat de resultaten van de tools niet met elkaar overeenkomen. Maar hoe verhouden ze zich dan tot de werkelijkheid?
De verschillen in transactietijden worden veroorzaakt door de verschillende manieren waarop de tools werken en responsetijden meten. Van iedere tool kunnen we een betrouwbaar idee krijgen over de prestaties op basis van de verschillen in transactietijden bij wisselende belasting. De absolute transactietijden zijn meer of minder realistisch, maar de relatieve prestaties onder wisselende belastingen zou in elk geval realistisch moeten zijn. Dit wordt bevestigd door metingen. Monitoring software zoals HPOpenview, Tivoli, Perfmon en Rstatd, om er een paar te noemen, kunnen helpen om te bepalen hoe zwaar de omgeving belast wordt.
De infrastructuur waarin je de tool gaat gebruiken, dient ook mee te wegen in het toolselectieproces. Als je binnen de infrastructuur bijvoorbeeld een load balancer gebruikt, dan is het handig als de tool aanvragen vanaf verschillende IP-adressen (IP-spoofing) ondersteunt. Ook het emuleren van gebruikers die de applicatie via verschillende kanalen benaderen, bijvoorbeeld via wan, lan en adsl, kan noodzakelijk zijn. Dergelijke functionaliteit wordt meestal alleen in commerciële tooling gevonden.
Een testautomatiseringstool is meestal onderdeel van een veel groter testframework. Het kan lastig zijn om een open source tool te integreren met commerciële software die je al gebruikt. Als dit soort integratie gewenst is, moet dit ook een onderdeel van de POC zijn. Hetzelfde geldt voor commerciële tools. Sommige commerciële tools werken alleen samen met andere tools van dezelfde leverancier, voor bijvoorbeeld bevindingenbeheer, testmanagement en versiecontrole. Hierdoor kun je gedwongen worden om ook deze tools aan te schaffen en uiteindelijk meer te betalen dan je van plan was.
Voorbereiding en investering
Voordat u kunt beginnen met testautomatisering of performance testen moet de testdocumentatie een zeker niveau hebben. Het verbeteren van de testdocumentatie kan wat extra tijd geven voor het toolselectieproces en gaat er zeker voor zorgen dat het automatiseringsproject soepeler verloopt. Deze stap is essentiëel, los van de tool die je gaat gebruiken. Voor testautomatisering zullen de tests behalve de invoer ook de resultaatvoorspellingen moeten bevatten. Dit is vaak niet het geval omdat een intelligente tester wel begrijpt wat de uitkomst moet zijn. Testtools zijn niet intelligent en moeten expliciet verteld worden wat te verwachten. Voor performance-testen is het noodzakelijk om te weten wanneer een gebruiker wat doet. Er moeten zogenaamde gebruiksprofielen zijn.
Een andere noodzakelijke voorwaarde is de beschikbaarheid van een ervaren, fulltime testautomatiseringsspecialist. Voor welke tool je ook kiest, het automatiseren van testuitvoering vergt tijd, kennis en vaardigheden. Als het team geen ervaren, fulltime specialist kan leveren, dan is de testautomatisering of de performance-test gedoemd te mislukken.
Het oud-Hollandse gezegde 'bezint eer ge begint' is in hoge mate van toepassing op het automatiseren van testuitvoering. Maar als je inderdaad de tijd neemt voor bezinning dan kun je de tool kiezen die het beste past bij jou. Wees er wel op voorbeid dat elke nieuwe tool een investering vergt.
Een uitgebreide, Engelstalige versie van dit artikel is eerder gepubliceerd in Testing Experience.
