Hoe vaak hoor je uitspraken als “onze website moet gewoon lekker snel zijn” of “het laden van deze pagina duurt wel een beetje lang”? Als performancetester hoor ik ze bij ieder project voorbij komen. Met deze abstracte omschrijvingen van de laadtijd van een website kan een tester niet zoveel. Maar wat kunnen we dan wel meten? En hoe belangrijk is dat?
Non-functional requirements
In ieder ontwikkelproces is er een periode waarin de requirements van de te ontwikkelen applicatie vastgesteld en uitgewerkt worden. Dat kan één keer aan het begin van het traject zijn, zoals volgens het watervalmodel, of iteratief in verschillende Agile-methoden, maar dit is in ieder geval een moment waarop wordt bepaald aan welke eisen een applicatie moet voldoen. Qua functionaliteiten is dat vaak wel duidelijk, al valt er te discussiëren over hoe gedetailleerd die informatie moet zijn. Maar als er gevraagd wordt naar de non-functional requirements, zorgt dat vaak voor verbaasde blikken. Deze ‘non-functionals’ zijn echter van grote waarde wanneer we kijken naar het performancetesttraject. Als je zoekt naar de definitie van non-functional requirements vind je vage omschrijvingen, zoals bijvoorbeeld: ‘specificatie van criteria die worden gebruikt om het gedrag van een systeem te kunnen beoordelen’. Het gaat dus om het gedrag van een systeem, applicatie, website of welk component dan ook. In de scope van een performancetesttraject komen woorden als ‘snel’, ‘schaalbaar’ en ‘robuust’ naar voren. Feitelijk betekent het dus dat er gekeken moet worden naar zaken als stabiliteit, capaciteit, schaalbaarheid en robuustheid. Deze termen zijn nog steeds vrij abstract, maar dit is te concretiseren door in te zoomen op de resources van een systeem. Hoeveel CPU-capaciteit is er nodig en hoe snel moet het zijn, hoeveel geheugen is er nodig, maar ook welke infrastructuur moet er liggen, et cetera. Echter, om deze vragen te kunnen beantwoorden is er eerst nog meer input nodig, en vaak is dit juist hetgeen bepaald moet worden tijdens en na afloop van de tests. Zo ontstaat er een vicieuze cirkel. Bovendien zijn deze technische componenten vaak niet direct interessant voor stakeholders. Als ze horen dat een optimaal gebruik van resources de kosten omlaag kan brengen, wordt het al interessanter. Maar waar in eerste instantie overeenstemming over bereikt moet worden en waar direct iets mee gedaan moet kunnen worden, zijn twee verschillende dingen. Hoe snel moet een applicatie zijn en hoeveel mensen moeten er tegelijkertijd gebruik kunnen maken van de applicatie. In performancetest-termen spreken we dan over responstijden en belasting, ook wel load genoemd: het aantal transacties/pagina’s/hits dat per seconde/minuut/uur verwerkt kan worden. Dit zijn essentiële non-functional requirements.
Responstijden
Responstijden zijn erg belangrijk voor de gebruikersbeleving. Wanneer bijvoorbeeld een webpagina of een component binnen een pagina traag is, is de bezoeker sneller geneigd de pagina te verlaten. Dit kan voor informatieve websites tot gevolg hebben dat de informatie niet wordt gelezen, maar het kan commerciële websites ook veel geld kosten. Ook gaat het bijvoorbeeld ten koste van de vindbaarheid van de website, aangezien Google bij het bepalen van de positie in de zoekresultaten ook kijkt naar de laadtijd van een pagina. Het is dus van groot belang dat stakeholders zich bewust zijn van het nut van lage responstijden. Er moet een requirement komen met een maximale responstijd waaraan een pagina moet voldoen. Dit is meetbaar voor de performancetester. Een maximale waarde is echter nog niet genoeg. Als er namelijk 1 meting boven de drempelwaarde uit zou komen, zou de test afgekeurd moeten worden. Daarom wordt er vaak gekeken naar gemiddelden of percentielen, een percentage van de metingen die onder de gestelde waarde moet zitten. Over de hoogte valt te discussiëren, dat zal in iedere situatie weer anders zijn, maar het is in ieder geval belangrijk dat er over nagedacht wordt en dat er een concreet requirement komt. Een voorbeeld hiervan is ‘In 95% van de gevallen moet de webpagina binnen 3 seconden geladen zijn’, waar natuurlijk nog allerlei afhankelijkheden aan vast kunnen zitten, zoals dat dit ook tijdens een bepaalde belasting het geval moet zijn.
Load
De belasting op een systeem wordt load genoemd. De loadverwachting, de verwachting van het aantal bezoekers dat gebruik maakt van een applicatie of website, het aantal transacties dat verwerkt moet worden, of het aantal pagina’s dat bezocht moet kunnen worden per tijdseenheid, is belangrijk om te kunnen bepalen of het systeem waar de applicatie of website op draait de belasting wel aan kan. Er kunnen namelijk wel snelle responstijden geconstateerd worden wanneer er 1 gebruiker op het systeem zit, maar dat wil niet zeggen dat het net zo snel is wanneer er 1500 gebruikers tegelijk bezig zijn. Als de stakeholders goed over de responstijden hebben nagedacht, dan willen ze de eisen die hieraan gesteld zijn ongetwijfeld ook waarborgen tijdens drukke perioden.
Conclusie
Een gedetailleerde uitwerking van deze 2 punten is een goed begin voor het stellen van duidelijke requirements. De performancetester weet waarop hij de (web)applicatie of systeem moet toetsen en de stakeholders weten wat ze willen en wat ze kunnen verwachten. Zo is het duidelijk wat de impact is van cijfers die in het uiteindelijke testrapport staan, en of er nog actie moet worden ondernomen om het te verbeteren. Zonder deze requirements is het mijns inziens niet relevant om te starten met het performancetesttraject. Natuurlijk zijn er ontelbare andere dingen waar rekening mee gehouden moet worden en is er veel meer input nodig om de teststrategie en vervolgens de testsoorten te kunnen bepalen, maar een stukje verwachtingsmanagement over de responstijden en de bezoekersaantallen, is een goede start. Weet wat je meet.