De Agile ontwikkelmethode is inmiddels bij veel organisaties al gemeengoed geworden. Laat ik het zo zeggen: een groot aantal van deze organisaties hebben veel elementen van de Agile ontwikkelmethode geïmplementeerd in de bedrijfsprocessen. Het functioneel testen is bij de meeste organisaties al op een redelijk niveau ingeregeld. Zelfs geautomatiseerde functionele testen worden steeds beter ingebed in het ontwikkelproces. Door deze ontwikkeling is de vraag naar performancetesten in een Agile omgeving ook toegenomen. Mijn ervaring is dat performancetesten nog te weinig op een gestructureerde manier in een Agile omgeving worden uitgevoerd. Dat is ook niet zo gek, want er zijn enorm veel uitdagingen, mitsen en maren om dit onderdeel goed in te passen.
Bij het traditionele watervalmodel wordt er pas aan het einde, vlak voor de livegang, performancetesten uitgevoerd. Dat zie ik bij de meeste applicaties die middels Agile worden ontwikkeld helaas ook gebeuren. Nog steeds worden er na enkele sprints, voor een officiële livegang, ‘snel’ performancetesten uitgevoerd. Vaak is er geen onwil om dat niet eerder te doen, maar er zijn zeker ook wel gegronde redenen om dit niet eerder te doen. Een voorbeeld hiervan is dat de kosten hoger zullen zijn, als er bij iedere sprint performancetesten zullen worden uitgevoerd. De baten hiervan zijn echter moeilijk te bepalen.
Theorie versus praktijk
De theorie, of anders gezegd de ideale situatie, is dat binnen de Agile ontwikkelmethode de performance continu onder controle is en binnen de gestelde eisen valt. Elke nieuwe iteratie wordt weer doorgetest. Dat betekent dat bij een nieuwe oplevering snel inzichtelijk is wat de performanceverschillen zijn en de performanceproblemen tijdig worden aangepakt.
De praktijk laat echter doorgaans een ander scenario zien. Een omgeving die slecht beschikbaar is, omdat deze gebruikt wordt voor met name functionele testen, testscripts die niet meer werken op de nieuwe versie van de software of de performancetestconsultant die niet direct beschikbaar is. Ook is een ontwikkel- of testomgeving vaak verre van representatief met productie, wat het beoordelen van de resultaten kan bemoeilijken. Soms is het ook lastig om überhaupt een performancetest uit te voeren, omdat deze de hele keten raakt en alles daarvan moet blijven werken. Allemaal zaken waar je bij functionele testen vaak praktischer mee om kan gaan.
Oude denken versus nieuwe denken
De transitie van performancetesten van het watervalmodel naar Agile, oftewel het oude denken versus het nieuwe denken, vergt een mentaliteitsaanpassing. In de oude situatie wil je eigenlijk pas laat de testscripts gaan opnemen, omdat de applicatie en de omgeving dan pas beschikbaar en functioneel getest is. Je gaat testen op basis van algemene applicatie- of systeemrequirements en meestal op basis van een blackboxbenadering. In een Agile omgeving is dat nagenoeg onmogelijk. Je moet eerder anticiperen op performancetesten. Je zal moeten gaan testen op specifieke componenten (API calls, individuele pagina’s of datgene wat beschikbaar is). De requirements moeten dan ook per component worden bepaald. Ook zal de omgeving meer als een grey box moeten worden gezien. Essentieel in dit alles is de samenwerking met ontwikkelaars. Is deze goed, dan zal het voor de performancetester een stuk eenvoudiger zijn om meer kennis van de interne werking van de applicatie te krijgen.
Robuustheid
Het is dus niet zonder meer eenvoudig om performancetesten in een Agile omgeving te embedden. Wil je dat wel doen, dan zijn er diverse aandachtspunten. De grootste valkuil die ik ben tegengekomen, is misschien wel dat men de testen nog volgens de oude manier wil uitvoeren, namelijk; de gehele applicatie testen. Dat betekent alles tegelijk en scripts zo realistisch mogelijk houden. Dat is natuurlijk een goed streven en een noodzaak bij goed performancetesten. Echter, in een Agile omgeving, waar applicatieversies elkaar snel opvolgen, een bijna praktisch onmogelijke opgave. Realiseer je dat je niet altijd alles kan testen en dat de tijd hierbij je grootste vijand is. Respecteer dat, communiceer dat en neem het mee in je testopzet. Het is belangrijk dat je de applicatie goed kent. De ene applicatie is veel gevoeliger voor wijzigingen op de herbruikbaarheid van je testscripts dan de ander. API’s zijn bijvoorbeeld robuuster dan GUI’s. Maar ook herbruikbaarheid en/of complexiteit van testdata speelt een rol in die robuustheid. Die robuustheid is één van de meest cruciale factoren op de grootte van je testset. Afhankelijk van de doorlooptijd van een sprint zou je eigenlijk binnen een dag je testscripts weer op de rit moeten hebben om nieuwe regressieperformancetesten te kunnen uitvoeren. Doe je er altijd meer dan twee dagen over om de test weer klaar te zetten, dan zou ik adviseren om kritisch te kijken naar je testopzet. Eigenlijk duurt het dan te lang om effectief binnen Agile te kunnen werken. Lever dan maar in op representativiteit als je bijvoorbeeld de doorlooptijd enorm kan verbeteren. Representatieve performancetesten doe je dan in een later stadium. Met robuust inrichten maak of kraak je de performancetestinrichting in een Agile omgeving.
Overige aandachtspunten
Natuurlijk zijn er nog tal van andere aandachtspunten om performancetesten in een Agile omgeving mogelijk te maken. Belangrijk is om per sprint de risico’s en impact van wijzigingen op de performance te evalueren (PRA – Performance Risico Analyse). Op basis daarvan kan je eventueel de performancetestset uitbreiden of bepaalde focus leggen bij het testen. Houd je testen simpel en maak ze zeker niet te lang. Wacht ook niet totdat alles compleet is ontwikkeld, maar pak een deel van wat beschikbaar is en ga daar alvast mee aan de slag. In 80% van de gevallen zul je al bevindingen ontdekken die je anders pas later zult ontdekken. Probeer bij de ontwikkelaars ook aan te sturen op de testbaarheid van de applicaties. Je kunt ze bijvoorbeeld duidelijk maken welke zaken impact hebben op je testscripts en hoe ze dat beter kunnen organiseren, zodat jij er minder last van hebt. Ook dien je rekening te houden met testdata. Idealiter is deze herbruikbaar. Probeer anders de testen zo in te richten dat de testdata ‘zichzelf in stand houdt’. Houd jezelf niet voor de gek dat je alles kan scripten en testen. Houd altijd de balans tussen de tijd die je steekt in testvoorbereiding, uitvoer en analyse.
Automatiseren van testen
Het geautomatiseerd uitvoeren van performancetesten, als er een nieuwe build wordt opgeleverd is de volgende stap. Dit is echter vaak een nog grotere uitdaging. Het moet mogelijk zijn dat performancetesten, zonder aanpassingen van scripts en handmatige voorbereiding, kunnen draaien. De eerdergenoemde aandachtspunten gelden voor automatische performanceregressietesten nog sterker. De testen dienen nog robuuster opgezet te worden.
Ook is het vergelijken van testresultaten geen eenvoudige opgave. Vaak is er een menselijk oog nodig om te beoordelen of de test wel zuiver heeft gelopen. Zijn er bijvoorbeeld geen pieken in de responstijden geweest, die door andere zaken zijn opgetreden, die eigenlijk niet van belang zijn. En zijn de fouten die ineens zijn opgetreden te verklaren. De automatische testen dienen altijd nog met een menselijk oog te worden beoordeeld op de kwaliteitsgehalte daarvan. Indien alles goed is ingericht, kan dat meestal binnen enkele minuten worden afgerond.
Performancetesttools kunnen ook steeds vaker worden geïntegreerd met bijvoorbeeld Jenkins, om automatisch performancetesten uit te voeren bij een nieuwe build. De resultaten kunnen dan automatisch worden vergeleken. Alleen al deze mogelijkheid biedt enorm veel perspectief in de wereld van performancetesten!
Geen acceptatietest
De simpelere testen zijn nog altijd geen vervanger van de traditionele acceptatieperformancetesten. Omdat er veelal in representativiteit wordt ingeboet en veel op componentniveau wordt getest, kunnen deze de grootschaligere performancetesten niet geheel vervangen. Er kunnen altijd zaken zijn die pas aan het licht komen als er werkelijk representatief wordt getest. De testen worden bepaald op basis van risico’s, budget en tijd. Het is verstandig bij grote wijzigingen, of voor de eerste livegang, de grootschalige, representatieve performancetesten te doen. Deze acceptatieperformancetesten zouden eigenlijk bij de release planning moeten worden ingebracht.
Samengevat
De transformatie van traditioneel testen naar een Agile methode, en dan nog het liefst op een geautomatiseerde wijze, is geen makkelijke. Er zijn enorm veel aandachtspunten om het tot een succes te maken. Robuustheid, risico’s, beschikbare tijd en budget zijn de grootste factoren die bepalen hoe ver je kan gaan met het embedden van performancetesten in een Agile omgeving. Denk bij dit alles dat voorkomen beter is dan genezen, want de schade zal enorm zijn als de applicatie in de ‘echte wereld’ niet aan de beschikbaarheidseisen zal voldoen.
