Sinds het protocol TruClient in Loadrunner is opgenomen hebben we nu de mogelijkheid om ook de client rendering tijden mee te nemen in een load test, maar is dit wel de verantwoordelijkheid van een performancetester?
Ik was deze blog begonnen terwijl ik in de rol van performancetester aan het werk was, inmiddels ben ik werkzaam in de rol van functioneel tester. De inhoud van de blog heb ik op deze tegengestelde ervaring aangepast.
Insteek als performancetester
Gewoonlijk heb je enkele keuzes wat je allemaal wil meenemen in je performancetest. Simpel gesteld heb je twee opties: Wil ik puur de capaciteit van de server meten door een test binnen het eigen netwerk of ga ik een performancetest uitvoeren waarbij ik de hele klantervaring meeneem door vanuit buiten het netwerk de testen uit te voeren. Met de introductie van TruClient kan je nu ook de client rendering meenemen in je performancetest. Dit is een goede toevoeging voor je gebruikerservaring, echter het nadeel van het meenemen van de client rendering in de klant ervaring is dat de resultaten niet voor alle gebruikers kan gelden. Er zijn zoveel verschillende devices en systemen die allemaal verschillende responstijden laten zien voor dezelfde actie.
Bovenstaande betekent echter niet dat je de client rendering dan maar moeten laten zitten voor wat het is en roept ook wel de vraag op wie is er verantwoordelijk voor het testen van de client rendering. Client rendering valt wel onder de non-functional requirements, maar de performancetester ziet meestal de front-end alleen tijdens de recording van een script. Buiten de tijd die je tijdens de recording op de applicatie doorbrengt zie je in het hele traject de front-end vrijwel niet. Het is juist een functioneel tester die veel meer tijd doorbrengt in de GUI en daardoor een beter zicht op vertragingen heeft.
Ondanks dat de testgevallen zich richten op de functionele werking van de applicatie wil ik pleiten voor het opnemen van de irritatie-issues. Raak je geïrriteerd door een slechte respons van onderdelen van je applicatie meldt deze dan aan als issue. Een performance tester kan dan vervolgens deze issues verder onderzoeken en de vinger precies op de pijnlijke plek leggen.
Insteek als functioneel tester
Recentelijk ben ik weer als functionele tester aan de slag. Door mijn ruime ervaring met performancetesten vallen vertragingen en onbeschikbaarheid mij sneller op dan mijn collega’s en probeer ik gelijk wat tools uit om de oorzaak te achterhalen. Dit kan ik echter alleen doen wanneer er niet zoveel tijdsdruk op mijn werkzaamheden staan. Als er wel tijdsdruk is dan loop ik tegen de volgende problemen aan in het verwerken van de performanceproblemen.
Aan wie kan ik de opvallende zaken aangaande performance melden? In de huidige omgeving is de leverancier verantwoordelijk voor de juiste werking, functionele en niet functionele zaken, van de testomgeving en productie. Er is daardoor niet een specifiek iemand of team waar ik terecht kan. Het beste wat mogelijk is is een melding maken in de issuetracker, maar dat is meestal ook maar een vage melding in de trant van “op die datum en tijd was deze functionaliteit erg traag” .
Door van alles te melden buiten mijn doel, functioneel testen, kom ik tijd tekort voor mijn gewone werkzaamheden. Overal wordt de kwaliteit natuurlijk een stuk beter, maar bijvoorbeeld het registratieproces die voor een bepaalde deadline volledig functioneel getest moet zijn heeft op dat moment een hogere prioriteit.
Waar het vooral op neerkomt is dat het voor de functionele testers erg belangrijk is om te weten waar of bij wie je opvallende zaken aangaande performance kan melden. Het is voldoende om emailadres te hebben zodat je snel direct kan melden wanneer en op welke plaats zich een performance probleem voordeed. Het is namelijk geen onwil of onkunde van de functionele tester dat de melding niet gedaan wordt, dus ga als performancetester een langs bij de projecten, laat weten wie je bent en wat je doet.
Bouke van der Schaaf
