Erwin Biharie over JMeter

| De meerwaarde van JMeter en de grenzen opzoeken.

Erwin Biharie is sinds 2008 actief als testengineer bij opdrachtgevers in diverse branches. Begin 2016 heeft gekozen om zijn carrière te vervolgen bij Immune-IT. Hieronder het verhaal van Erwin en JMeter.

Tot nu toe heb ik veel op projecten gezeten waarin ik functioneel en technisch moest testen. Maar als ik kijk naar mijn eigen ontwikkelingsplan, dan wil ik graag doorgroeien in de richting performance en automatisering. Daar is heel veel vraag naar en ik vind het ook gewoon leuk.

JMeter is een tool waarmee je in Java testscripts kunt schrijven. Ik heb JMeter in het verleden vaak  gebruikt voor load testen en stresstesten, maar ook voor mijn functionele testen. Bij een bepaalde opdrachtgever moest ik onderzoeken hoeveel verzoeken onze hardware, servers en apps aan zouden kunnen, zonder vast te lopen. Bij de lancering van een nieuwe mobiele app, gingen wij ervan uit dat wij na de eerste maand ongeveer 20K users zouden hebben. Dus dan begin je eerst te testen met 100 verzoeken tegelijkertijd. Als dat goed gaat, dan bouw je op naar 1000 users - en dan naar 10.000, totdat je bij de 20.000 bent. Dat was geen overbodige luxe, bleek later. Bij de uiteindelijke release van de app ging het dak er meteen af. We zaten binnen een week op 20K downloads, alleen al op IOS! Mijn opvolger op dit project gaat de load testen nu verder opvoeren.

JMeter

Ik heb de load testen destijds geschreven met JMeter, waarmee je een script kunt maken waarin je grote aantallen users simuleert. Ik liep daarbij overigens wel tegen een grens aan wat betreft het aantal users. De bottleneck bleek niet zozeer de tool zelf, maar het werkgeheugen van de Mac-laptop waarop ik moest werken. Op een stand alone Mac kun je maar tot 50 users parallel actief laten runnen. Ik heb dit toen creatief opgelost door de runs 200 x te laten loopen zodat ik toch uitkwam op serieuze aantallen. Ook de end-to-end performancetest heb ik gescript in JMeter.

Waarom ik voor JMeter gekozen heb? Ik wilde iets doen met performancetesten en tooling. Toen ik vervolgens ging googelen, kwam JMeter voorbij – en dat leek mij wel wat. Omdat ik snel aan de slag wilde, heb ik mij meteen een avondje verdiept in JMeter. Als je informatie een beetje snel oppikt, kun je heel wat leren van instructiefilmpjes op youtube. Omdat ik ook weinig ervaring had met Java, heb ik mij daar ook maar meteen even in bijgespijkerd – ook weer via google en youtube.

Meerwaarde

Mijn opdrachtgever was heel erg blij met de uiteindelijke resultaten. Door mijn tests kwamen wij er bijvoorbeeld achter dat een bepaalde transactie bijna 24 seconden duurde – dat is veel te lang. De vertraging bleek veroorzaakt te worden door een soort extra controle op een verkeerde plaats. Die controle hebben wij dus verplaatst naar een andere plek in de keten. De resultaten lieten ook zien dat de snelheid van de systemen omlaag ging naarmate het aantal simultane gebruikers sterk toenam, maar met die bevinding is uiteindelijk niets gedaan. Een kwestie van risico-analyse.

Omdat ik de enige tester was in het scrumteam met drie developers en de Product owner, was ik in de praktijk, tester, testmanager en testcoördinator tegelijkertijd – voor zover je die termen nog mag  gebruiken in Scrum. Uiteindelijk heb ik dan ook de hele performance en loadtest op poten gezet. De Product owner en Scrummaster hadden daar zelf eigenlijk helemaal niet gedacht. Ook heb ik de Product owner op pad gestuurd om binnen de organisatie op zoek te gaan naar cijfers rondom oude load testen, waartegen ik mijn eigen nieuwe bevindingen zou kunnen afzetten.

Grenzen opzoeken

Bij Immune-IT hecht men veel belang aan de inhoudelijke groei van de eigen testers. Ik heb de afgelopen jaren certificaten gehaald als TMAP, BI testen, Scrummaster, ISTQB, XML – en ik heb een basiscursus Java gedaan. De kennis die ik  hiermee heb opgedaan is nu goed te gebruiken in mijn werk. En ik weet niet of er al echt goede trainingen zijn voor performance testen, maar als dat zo is, dan ben ik daar ook wel in geïnteresseerd.

Wat ik echt een uitdaging vind is de grens opzoeken van hardware/servers en software, dingen slopen eigenlijk. En ik vind het leuk om eigen testscripts te schrijven: dat is technischer en dynamischer dan alleen de frontend te testen door op velden/knopjes te klikken. Ik heb met dat laatste trouwens wel veel ervaring en kan ook goed overweg met Selenium DE, de bekende record en replaytool. Zodra ik daar de kans toe krijg, probeer ik altijd meteen alle regressietesten te automatiseren, dat scheelt veel tijd en geld voor de klant.

Uiteindelijk moet je als tester vooral heel goed meedenken met het belang van de Product owner. Had ik bijvoorbeeld niet gewezen op het belang van de load test, dan was er een groot risico geweest dat de app zou zijn bezweken onder de onverwachte populariteit in de eerste week. Dat is imagoschade die je de klant wil besparen. In die zin is een goede tester zijn geld dubbel en dwars waard.