Agile en Performance Testen

Geschreven door Praegus

Gepubliceerd op 22 januari 2016

Blog Roland1
Blog Roland2
Blog Roland3

De laatste jaren ben ik als Performance Tester regelmatig betrokken bij projecten waarin “Agile” wordt gebruikt als methodiek. Wat mij daarbij opvalt is dat er vaak laat in het traject, rond de 15de sprint, over performance nagedacht wordt. Er is dan voldoende functionaliteit om de business processen uit te kunnen voeren, waardoor performance issues zichtbaar worden. Geautomatiseerd regressie testen wordt vanaf het begin gedaan, performance testen komt pas veel later aan bod. Is dat een probleem dan ?
Dat is zeker een probleem. Keuzes op architectuur gebied kunnen leiden tot slechte performance, wat vervolgens een aantal sprints kan kosten om te herstellen. In een van mijn projecten bleek bij een userstory in sprint 17 dat het gekozen database model op basis van de performance eisen niet geschikt was om attachments op te slaan, terwijl deze functionaliteit reeds bij de start van het project bekend was. Het ombouwen van de reeds gebouwde functionaliteit naar een ander databasemodel nam, inclusief testen, twee volle sprints in beslag. Om dergelijke kostbare ‘missers’ te voorkomen is het dan ook belangrijk om vanaf de eerste dag over performance na te denken. Performance word niet voor niets de verborgen functionaliteit van een applicatie genoemd. De focus ligt primair op business processen en functionaliteit. Hierdoor wordt performance meestal niet of te laat meegenomen als onderdeel van de user story en in de Definition of Done.
Projecten welke de waterval methodiek volgen kennen een duidelijke scheiding tussen de verschillende testen. Na bouw- en integratie testen volgen de functionele testen en als laatste de performance testen, vervolgens is er nog een periode voor Go Live waarin onder meer de problemen met de performance opgelost kunnen worden. Binnen een Agile werkwijze, met twee wekelijkse sprints, is het onverstandig om aan het einde van de sprint, als de user stories gebouwd en functioneel getest zijn, pas op performance te gaan testen. Voldoende tijd om bevindingen op te lossen en te her-testen is er dan niet. Het risico van een dergelijke werkwijze is ook dat er onder druk van de business besloten wordt om de nieuwe functionaliteit toch live te zetten ondanks de performance issues. Waardoor zgn. “technical debt” ontstaat.
Het bouwen van een applicatie welke door honderden gebruikers gebruikt wordt, vereist naast functionaliteit ook een gedegen architectuur. Met een goed fundament kun je zorgeloos Agile bouwen en voorkom je dat er een villa op het ‘fundament voor een tuinhuisje’ ontstaat, wat resulteert in performance problemen en meerwerk. We kunnen dan ook concluderen dat performance testen binnen Agile begint zodra de userstory besproken wordt, met de vraag: is de gewenste functionaliteit performance kritisch? Als deze vraag met “ja” beantwoord wordt, wat is dan de impact op ontwikkeling en testen. De antwoorden op deze vragen vertalen zich in een aantal taken zoals bv. unit testen voor performance, code profilering, code en query optimalisaties, creëren van test data, logins en opschalen van de test omgeving.  Door deze aanpak is het vanaf het begin duidelijk welke taken er in het kader van performance voor de userstory gedaan moeten worden.
Ontwikkelaars hebben een sterke focus op functionaliteit, mede gedreven door de wensen van de Product Owner. Als Performance Tester is het daarom belangrijk om binnen het team “Performance Awareness” te creëren, door het geven van presentaties, concrete voorbeelden en betrokken te zijn bij het ontwikkel proces. Inzichtelijk maken hoeveel impact een performance verbetering van 30ms voor een functie heeft bij 300 gebruikers helpt om ontwikkelaars inhoudelijk een beeld te geven dat kleine verbeteringen leiden tot grote verschillen. De ontwikkelaars hebben immers een prominente rol als het om performance gaat, tijdens de ontwikkelfase moeten er al op unit niveau performance testen plaats vinden welke leiden tot code optimalisatie en wijzigingen in de architectuur. Tooling zoals “Spring Insight“ geeft de ontwikkelaar inzicht waar de meeste tijd in de code gebruikt wordt en maakt de resultaten van code optimalisatie inzichtelijk.
Binnen projecten wordt door de ontwikkelaars vaak gebruik gemaakt van diverse frameworks zoals “Angular JS“, welke de ontwikkelaars ondersteunen om de gewenste functionaliteit te realiseren.  Aan dergelijke frameworks wordt door een grote community van ontwikkelaars bijgedragen. De focus ligt hierbij op functionaliteit en brede inzetbaarheid en minder op performance. Uit ervaring binnen een aantal projecten blijkt dan ook dat op basis van de resultaten van performance unit testen sommige functies binnen het framework aangepast of vervangen moeten worden door eigen functies, welke geoptimaliseerd zijn om de applicatie zo goed mogelijk te laten performen. Voorbeeld van een dergelijk wijziging is een functie welke standaard alle NAW-gegevens van een persoon terug geeft, waar alleen de naam en postcode nodig waren. Deze aanpassing leidde tot een lagere database en applicatie server belasting, minder netwerk verkeer en een lagere belasting aan de cliënt zijde, aangezien de functie die de naam en postcode eruit filterde kon vervallen. Een ander voorbeeld van een dergelijke optimalisatie is het ‘voorkoken’ van de data aan de cliënt side zodat deze in een formaat komt wat snel kan worden verwerkt en opgeslagen in de database aan de server side. Er vanuit gaan dat optimalisaties standaard een onderdeel van het ontwikkelproces zijn is een verkeerde aanname. Door tijdsdruk en focus op functionaliteit worden optimalisaties, zo is de ervaring, meestal niet meegenomen.
De wijze waarop code word geschreven kan ook veel invloed hebben. Het is dan ook verstandig om ‘pair programming‘ toe te passen bij code die performance kritisch is. Het invoeren en gebruiken van ‘code conventies‘ en het bereiken van een bepaalde dekkingsgraad voor de unit testen verhogen de kwaliteit, performance en onderhoudbaarheid. De performance tester is meestal niet degene die de code schrijft, maar wel de drijvende kracht achter het invoeren en monitoren dat de ontwikkelaars de tools en technieken toepassen.
Test tools als ‘Selenium’ en ‘Jmeter’ zijn eenvoudig te integreren in een Continous Intergration omgeving, door deze na iedere build uit te voeren komen functionele en performance problemen, ontstaan door het toevoegen van nieuwe functionaliteit, aan het licht. Voor een CI omgeving zijn er daarnaast diverse dashboards om per build de voortgang en kwaliteit te monitoren, gecombineerd met trend analyses. Een voorbeeld van een dergelijk dashboard is “SonarQube”. Een optimale synergie ontstaat als de performance van het productie systeem word teruggekoppeld in het Agile traject, bijvoorbeeld door middel van integratie tussen ontwikkeling en beheer, beter bekend als “DevOps”.
Binnen een Agile traject is de rol van de Performance Tester dan ook veel breder dan in waterval projecten. Naast performance testen in de sprints, borgt de Performance Tester ook de performance door actief betrokken te zijn bij het ontwikkel- en beheerproces. Op deze wijze krijgt performance testen binnen Agile de juiste functie, namelijk het valideren van de performance in plaats van ‘trouble shooten’ aan het einde van de sprint.
Ik heb dit artikel eerder gepubliceerd in de “Najaarsspecial 2015” van TestNet Nieuws.

Schrijf een reactie

Gerelateerde artikelen