In mijn carrière als performancetestconsultant ben ik bij veel verschillende projecten en organisaties betrokken geweest. Ik heb veel projecten succesvol, maar ook onsuccesvol zien verlopen. De redenen daarvan zijn uiteenlopend van een moeizame organisatie, slechte planning tot complexe applicaties. Traditioneel worden de performancetesten meestal aan het einde van een project uitgevoerd en vangt daarmee alle klappen in een project die voor uitloop zorgen. Dit kan het vaak moeilijk maken om een performancetesttraject succesvol te doorlopen.
Op 4 februari 2014, toen ik mijn presentatie over succesvol performancetesten op een thema-avond bij TestNet gaf, bleek dat de genoemde valkuilen nog wel wat losmaakten. Er waren bepaalde valkuilen die sommigen niet als een valkuil zagen of de valkuil op een andere manier uitlegde. Dit bracht mij op het idee om de genoemde valkuilen uit de presentatie verder toe te lichten. Niet om de discussie weg te nemen, maar om helderder te maken waarom bepaalde valkuilen belangrijk zijn om te noemen en te erkennen.
1. Geen (duidelijke) performance criteria
Een van de belangrijkste valkuilen is het vooraf niet of onduidelijke gedefinieerd hebben van de performance criteria waaraan de applicatie moet voldoen. Het niet vooraf definiëren van acceptatie-criteria betekent dat achteraf de resultaten niet voldoende goed kunnen worden beoordeeld. Natuurlijk kun je meestal wel gaan testen zonder performance criteria. Je kunt alleen niet onderbouwd beoordelen of het goed (genoeg) of onvoldoende presteert. Het wordt dan een kwestie van gevoel. Meestal betekent het gebrek aan criteria dat na de testen de resultaten worden geëvalueerd en het gevoel gaat spreken of de performance voldoende is. Ook kan het lastiger zijn om zonder criteria de testen op te zetten. Welke testen ga je dan uitvoeren? Een stresstest is dan het meest waarschijnlijk: kijken waar de maximale belasting ligt en wat de bottleneck van de applicatie is. Een loadtest kan al wat lastiger zijn. Met welke belasting ga je testen? Als je inzichtelijk hebt hoeveel gebruikers op piekuren actief zijn en hoeveel en welke pagina’s ze ophalen, heb je voldoende feedback, maar heb je dat niet, dan wordt het een schot in het donker. Naast het niet hebben van criteria, zijn er ook vaak onduidelijke of slechte performance criteria. Vereisten zoals: “De applicatie moet 1.000 gebruikers aankunnen” of “De responstijden moeten lager zijn dan 4 seconden” zijn niet concreet genoeg. Als een applicatie 1.000 gebruikers moet aankunnen, zijn dat dan gebruikers die binnen een dag op de applicatie zijn gekomen, die op één moment actief zijn of die op hetzelfde moment een verzoek doen? Ook de criteria met betrekking tot de stelling dat responstijden onder de 4 seconden moeten zijn is beperkt. Bij welke belasting? Je hebt vaak te maken met incidentele pieken, keur je dan de applicatie af, omdat je in de test enkele metingen net daarboven had? Betere criteria zijn SMART. Ze moeten realistisch zijn, dus afgeleid van een reëel verwacht piekgebruik. Het komt maar wat vaak voor dat uit testen blijkt dat de criteria niet worden behaald en dat dan achteraf de criteria maar worden bijgesteld, omdat ze bij nader inzien toch niet realistisch waren. Geef bij de criteria over responstijden altijd een percentiel mee, bijvoorbeeld 98%, en benoem uitzonderingen.
SMART acceptatie criteria zullen dan een centrale rol gaan spelen bij performancetesten en de betekenis van de resultaten.
2. Onjuist gesimuleerde belasting
Een andere valkuil is het simuleren van een niet representatieve belasting. Het zogenoemde loadmodel (verhouding tussen klikpaden/functionaliteiten) dient altijd representatief te zijn. Als je bijvoorbeeld een piekuur simuleert, is het belangrijk om in (ongeveer) de juiste verhouding het aantal authenticaties, opgevraagde overzichten en startpagina’s te raken. Doe je dat niet, dan is de kans groot dat je de zware acties te veel of te weinig raakt en de resultaten anders uitvallen. Vervolgens worden er de verkeerde conclusies getrokken.
Het is dus belangrijk om aandacht te schenken aan een analyse van het werkelijke gebruik op een productieomgeving. Logging op een webserver, bijgehouden statistieken in de database of Google Analytics zijn voorbeelden van bronnen om het werkelijke gebruik te achterhalen. Gebruik deze ook, het zal de performancetesten beter maken!
3. Een te uitgebreide scope
De voorgaande valkuil ging over het belang van het simuleren van een representatieve belasting, maar haaks daarop staat de valkuil van een te uitgebreide scope. Het is belangrijk om de belasting zo representatief mogelijk te simuleren, maar je kan daarin ook te ver doorschieten door alles proberen op te nemen in de performancetesten. Afhankelijk van de robuustheid van de testscripts, de frequentie van de wijzigingen van een applicatie en beschikbare tijd moet bepaald worden hoeveel functionaliteit gedekt dient te worden. Belangrijk is in ieder geval dat de meest geraakte functionaliteit wordt gedekt. Ik heb vaak meegemaakt dat projectmanagers of producteigenaren graag zoveel mogelijk, zo niet alles, gedekt willen zien in de performancetesten. Dit is vaak onmogelijk. Een goed performancetester zal de juiste dekking van klikpaden moeten kunnen vaststellen, zodat met relatief minimale inspanning nieuwe versies getest kunnen worden. Het maakt vaak niet uit om alle type overzichten mee te nemen, of alle tabbladen van een webpagina. Het verschil ertussen is meestal minimaal en dan loont het niet de moeite. Het risico is namelijk dat er te veel tijd gaat naar scripten in plaats van naar de werkelijke testuitvoer. En dat is zonde.
In de volgende blog zullen nieuwe valkuilen en problemen bij performancetesten worden benoemd.
