Managed hosting door True

Performancetest in testomgeving niet zinloos

 

Channelweb Expert

ing. Marcel Wigman
Performance Consultant, Ymor. Expert van Channelweb voor de topics Digital Transformation, Beheer en Digital Workplace.

Regelmatig spreek ik 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 performanceproblemen 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 ik het meeste horen.

Geen zin

"De snelheid van een applicatie is bijvoorbeeld niet afhankelijk van het aantal servers dat naast elkaar gebruikt wordt"

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. Mijn advies: maak sowieso gebruik van een testomgeving, ongeacht of deze ‘productie-like’ is.

Testdata

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.

Mijn 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.

Veel tijd

"De dekking en complexiteit van de test die men denkt te moeten realiseren, kan voor lange trajecten zorgen"

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.

Mijn advies is: laat een performancetest opzetten door een ervaren performancetester en draag deze dan over aan de 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.

Keuze

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 procent van de performanceproblemen uit de applicatie en blijft de onverwachte 10 procent zitten voor productie? Of zet u de volle 100 procent risico’s door naar productie? Het is uiteindelijk een afweging tussen belangen, risico’s en kosten.

Dit artikel is afkomstig van Channelweb.nl (https://www.channelweb.nl/artikel/6829644). © Jaarbeurs IT Media.

?

 

Jouw reactie


Je bent niet ingelogd. Je kunt als gast reageren, maar dan wordt je reactie pas zichtbaar na goedkeuring door de redactie. Om je reactie direct geplaatst te krijgen, moet je eerst rechtsboven inloggen of je registreren

Je naam ontbreekt
Je e-mailadres ontbreekt
Je reactie ontbreekt

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.