Management

Dit is een bijdrage van Ymor
Apps
performancetesten

Is performancetesten in testomgevingen zinloos?

Wat houdt IT-afdelingen tegen om een applicatie te testen voor livegang? We zetten drie redenen op een rij

27 januari 2020
Door: Ymor , partner

Wat houdt IT-afdelingen tegen om een applicatie te testen voor livegang? We zetten drie redenen op een rij

Bij Ymor spreken we regelmatig testmanagers die vinden dat de kosten voor het neerzetten van een ‘performance testomgeving’ te hoog zijn en (mede) daarom geen performancetesten uitvoeren. Het gevolg daarvan is echter dat we nog steeds veel applicaties met performance problemen tegenkomen. Denk aan eventwebsites die down gaan bij piekbelasting, ticketwebsites die traag worden bij drukte, of applicaties die als onderdeel van de kantoorautomatisering ineens niet meer de gewenste snelheid halen. Wat houdt IT-afdelingen dan ook tegen om een applicatie te testen voordat deze live gaat? In deze blog zet ik de drie redenen op een rij die wij het meeste horen.

 

REDEN 1: “PERFORMANCETESTEN IN EEN TESTOMGEVING HEEFT GEEN ZIN”

In de ideale situatie is een performance testomgeving beschikbaar met exact dezelfde capaciteit en architectuur als de productieomgeving. Maar een ‘productie-like’ testomgeving zien we in onze praktijk zelden. Testomgevingen kosten geld en worden daarom zo eenvoudig mogelijk uitgerust – met als doel de applicatie functioneel te laten werken.

Maar heeft het daarom geen zin om een performancetest uit te voeren in de testfase van applicatieontwikkeling? Zeker wel! De snelheid van een applicatie is bijvoorbeeld niet afhankelijk van het aantal servers dat naast elkaar gebruikt wordt. Responstijden kunnen daarom goed gemeten worden op een enkelvoudige configuratie. Zelfs het gebruik van trage servers in een testomgeving heeft een voordeel: als de applicatie daarop voldoende snel presteert, kan de garantie worden afgegeven dat de applicatie nog sneller zal zijn in de productieomgeving met snellere hardware. Verder leveren de grenzen die in een testomgeving ontdekt worden, nuttige kennis op voor de inrichting van de productieomgeving. Bijvoorbeeld voor de configuratie rond connectiepooling, en de wijze waarop de capaciteit van een applicatie zich laat schalen.

Het is dus juist zinvol om te performancetesten op een ‘minderwaardige’ testomgeving. Ons advies is dan ook om sowieso gebruik te maken van een testomgeving, ongeacht of deze ‘productie-like’ is.

 

REDEN 2: “ER IS ONVOLDOENDE TESTDATA”

Testomgevingen bevatten vaak niet meer dan maar een paar of tientallen testgevallen. De vullingsgraad van de database is dan niet representatief voor de situatie in productie. Heeft performancetesten in zo’n lege omgeving dan wel zin? Jazeker!

De meest complexe performanceproblemen worden veroorzaakt doordat applicaties inefficiënt omgaan met hun data. Deze categorie problemen is juist in een testomgeving met weinig testdata goed te detecteren en te analyseren. Los ze zo vroeg mogelijk in het ontwikkelproces op, voordat er meer functionaliteit van afhankelijk wordt. Is data vulling dan helemaal niet nodig voor performancetesten? Zeker wel, maar het soort performanceproblemen dat gevoelig is voor data volumes is eenvoudig te detecteren en op te lossen. Bij voorkeur doen we dat in de testfase, maar monitoren en oplossen in productie omgeving kan een verantwoorde keuze zijn.

Ons advies: performancetesten worden bij voorkeur uitgevoerd op een realistisch gevulde database. Maar voor het vinden van de meest ernstige performance problemen is de aanwezigheid van grote aantallen database regels niet van belang. Voer dus altijd een performancetest uit voor live-gang.

 

REDEN 3: “PERFORMANCETESTEN KOST TE VEEL TIJD”

Dit is eigenlijk nooit een goed argument. De voorbereidingstijd die nodig is om een goede performancetest te maken kan fors zijn, maar deze is goed in de hand te houden. Het is vooral de (on)ervarenheid van de persoon die de performancetesten maakt, dus de leercurve, die de voorbereidingstijd laat toenemen. Ook de dekking en complexiteit van de test die men denkt te moeten realiseren, kan voor lange trajecten zorgen. Tot slot vindt het maken van een performancetest vaak plaats naast alle reeds lopende werkzaamheden, waardoor de test geen focus heeft en alleen al daardoor langer duurt dan nodig.

Ons advies is: laat een performancetest opzetten door een ervaren performancetester en draag deze dan over aan uw eigen mensen. Denk vooraf na over de risico’s die voor uw applicatie(s) gelden en laat dit meewegen in de samenstelling van de performancetesten. Laat u adviseren en wees flexibel in de afwegingen die nodig zijn om een goede set met uitgangspunten op een rij te krijgen voor de performancetesten.

 

WELKE KEUZE MAAKT U?

Grote problemen zijn de uitvergroting van kleine problemen. Kleine problemen kunnen met performancetesten gevonden worden in een beperkt geschaalde testomgeving met maar weinig data. Ook applicatiegedrag met grote datasets kan eenvoudig worden nagebootst in een testomgeving. Verder is de keuze natuurlijk aan u: halen we 90% van de performanceproblemen uit de applicatie en blijft de onverwachte 10% zitten voor productie? Of zet u de volle 100% risico’s door naar productie? Het is uiteindelijk een afweging tussen belangen, risico’s en kosten.

 

Deze blog verscheen eerder op https://www.ymor.com/nl/resources/blog/is-performancetesten-op-een-testomgeving-zinloos-2

Reactie toevoegen