Waar het vaak fout gaat met performancetesten

Seneca zei ooit: Als je niet weet naar welke haven je zeilt, is geen enkele windrichting gunstig. Vrij vertaald: als je geen idee hebt wat je doel is, kun je de weg ernaartoe ook niet bepalen.

Hoe komt het dan toch dat zoveel bedrijven en organisaties, als ze een applicatie ontwikkelen, wel weten DAT ze performance willen laten testen, maar niet kunnen aangeven HOE de applicatie zou moeten performen? En dat terwijl de basisvragen voor de productowner helemaal niet zo moeilijk zijn en niet enorm veel tijd hoeven te kosten. Als kwaliteitsadviseur kun je je klant helpen om deze antwoorden helder te krijgen door de juiste vragen te stellen. Met dit artikel geef ik je een aantal handvatten.

In een performancetest draait het om ´zo realistisch mogelijk simuleren van de wijze waarop de applicatie na GoLive in productie gebruikt zal worden´. Als je als product owner binnenkort een applicatie wilt laten realiseren, stel dan onmiddellijk de vervolgvraag: hoe gaat de applicatie in productie nu eigenlijk gebruikt worden? Probeer daarvan een beeld te vormen voordat je performancetesters inhuurt.

De sleutel tot een goede performancetest ligt namelijk niet, zoals dikwijls wordt aangenomen, bij het inhuren van een goede performancetester maar bij een accurate gebruiksanalyse door de businessorganisatie van het bedrijf. Een goede performance tester kan deze informatie overigens ook uitstekend boven water krijgen, maar performancetesters worden meestal vrij laat in het project betrokken. En dan is er vaak te weinig tijd over voor een gedegen gebruiksanalyse. Een performancetester moet dus dikwijls gevoed worden met hoe het systeem zal worden gebruikt. Voed hem met verkeerde uitgangspunten en de resultaten van de test zullen onbetrouwbaar zijn.

Nu hoor je performancetesters dikwijls praten in jargon als ´hits per tijdseenheid, pages per second, queueing, threading, concurrent users, enzovoorts’. Wees niet bang, het analyseren van de gebruikersaantallen gebeurt gewoon in de taal die de businessorganisatie begrijpt. Een goede performancetester is in staat om de vertaling te maken van businesstaal naar performance-scripting.

Kwaliteit van het loadmodel

De kwaliteit van het loadmodel bepaalt dus in belangrijke mate het realisme van de resultaten van een performancetest. Performancetests werken met enorme volumes. Omdat de wet van de grote getallen van toepassing is kunnen de uiteindelijke meetresultaten er maar zo een factor ‘tig' naast zitten, als je het toetsingskader onzorgvuldig opstelt. Een te grote afwijking kan het verschil betekenen tussen een performant systeem of een krantenkop.

Hoe ziet zo’n loadmodel eruit? En hoe kom je daartoe? Stel jezelf allereerst de twee volgende vragen:

• Aan welke performance-eisen moet de applicatie voldoen?

• Hoe simuleren we een reële productiesituatie het beste (welke processen met welke aantallen)?

Het eerste aspect beschrijft de doelen en wordt door veel organisaties nog wel ingevuld, maar doelen kunnen niet los worden gezien van de beschrijving van de weg ernaartoe. Onderstaande gaat over het verkrijgen van het antwoord op de tweede vraag.

PREGAPS-mnemonic (ezelsbrug)

Ik heb gewerkt aan een europees aanbesteed project, waarin de volgende eis geformuleerd was: ‘500 gebruikers moeten met het systeem kunnen werken’. Onduidelijk was echter: is dat het totale klantenbestand dat van het systeem gebruik maakt? Is dat het aantal gebruikers dat op een zeker moment gelijktijdig is ingelogd? En wat voor acties doen die 500 gebruikers in het systeem met welke frequentie? De leverancier van de applicatie, tevens belast met het aantonen van deze eis, logde bij gebrek aan een dwingend loadmodel 500 virtuele gebruikers in het systeem in, wachtte een uur en logde ze vervolgens weer uit zonder dat ze ook maar één klik in het systeem hadden gedaan. Eis gedekt, klant gefopt, recipe for disaster. Dit probleem kun je niet volledig aan de leverancier wijten: als opdrachtgever heb je ook een verantwoordelijkheid om systeemgebruik SMART te maken! Je loadmodel is dé blauwdruk voor het nabootsen van de praktijksituatie,

Om bovenstaan de reden houd ik niet van de veelgebruikte term concurrent users (´aantal gelijktijdige met het systeem werkende gebruikers), omdat deze term zonder de toevoeging ‘op welke manier gebruiken ze de applicatie?’ betekenisloos is. Tien gebruikers die berekeningen uitvoeren kunnen een groter beslag op een applicatie leggen dan honderd gebruikers die simpele opvragingen van statische content doen. Daarnaast is ook van belang hoe actief de gebruiker is. Klanten op websites vertonen bijvoorbeeld in de regel veel actiever gedrag dan medewerkers in een procesondersteunende applicatie: klanten gaan bewust naar een site, doen daar een aantal acties en verdwijnen weer. Beheerders hebben diverse ondersteunende applicaties gedurende de werkdag op de achtergrond open staan en gebruiken deze bijvoorbeeld enkel op de momenten dat een collega belt om zijn wachtwoord te laten resetten.

In plaats van ´hoeveel gebruikers zitten er gelijktijdig in mijn applicatie´, werk liever toe naar 'aantal transacties per tijdseenheid', dat geeft een betrouwbaardere basis. Mijn PREGAPS-mnemonic (Processes, Rates, Educated guesses, Goals, Availability, Peaks, Specials) geeft je een uitstekende structuur om in een aantal logische stappen te komen tot een weloverwogen loadmodel, gebaseerd op transacties per tijdseenheid. Elke stap in het proces borduurt voort op de voorgaande. Het loadmodel is voor performance testspecialisten vervolgens een uitstekend uitgangspunt om de daadwerkelijke performancetest uit te werken.

Processes

Breng eerst met behulp van business stakeholders in kaart welke processen in de applicatie naar verwachting het meeste worden uitgevoerd. Bijvoorbeeld:

1. Raadplegen productinformatie autoverzekering;

2. Opvragen offerte;

3. Afsluiten autoverzekering;

4. Doorgeven schademelding;

5. Raadplegen voortgang schademelding;

6. Raadplegen frequently asked questions;

7. Downloaden voorwaarden verzekering;

8. Vraag stellen via contactformulier

Rates

De volgende stap is om te achterhalen hoe vaak de processen in een eenheid van tijd worden uitgevoerd. Sommige gegevens kun je eenvoudig benoemen omdat ze algemeen bekend zijn:

• Je organisatie kan je direct vertellen dat maandelijks ongeveer 5.000 mensen een nieuwe autoverzekering sluiten;

• De afdeling schade weet uit ervaring dat per dag gemiddeld 50 nieuwe schades worden aangemeld;

Voor andere gegevens zul je gedurende een bepaalde periode moeten meten, bijvoorbeeld door het oude systeem te monitoren, of door andere stakelholders om informatie te vragen. Zodoende kom je aan nadere gegevens:

• Monitoren van de oude (te vervangen) site leert dat maandelijks 100.000 offerteberekeningen worden uitgevoerd (oftewel: 5% van de offerteberekeningen leidt tot afsluiting van een nieuwe polis);

• De helpdesk krijgt gemiddeld 1000 telefoontjes per dag. Je callcenter houdt bij dat 450 gesprekken gaan over ‘frequently asked questions’. Nog eens 50 telefoontjes gaan over informatie met betrekking tot een lopende schadeafhandeling (op een totaal klantenbestand van 50.000 verzekerden is dat 0,1%). De overige 400 telefoontjes gaan over vragen die niet eenvoudig te categoriseren zijn.

Eindstand 'Rates'

1. Raadplegen productinformatie autoverzekering;

2. Opvragen offerte 100.000 per maand;

3. Afsluiten autoverzekering; 5.000 per maand (5%);

4. Doorgeven schademelding; 50 per dag;

5. Raadplegen voortgang schademelding;

6. Raadplegen frequently asked questions;

7. Downloaden voorwaarden verzekering;

8. Vraag stellen via contactformulier

Educated Guesses

Van processen 2 tot en met 4 is hierboven vastgesteld hoe veelvuldig ze voorkomen. Over processen 5 en 6 weten we al iets, maar dat heeft niet rechtstreeks betrekking op de nieuwe applicatie. Van processen 1, 7 en 8 ontbreken meetgegevens, omdat er nog geen metrieken bekend zijn. Bijvoorbeeld omdat een bepaalde functie in het oude systeem nog niet online werd aangeboden. Daarvoor zul je met collega’s (doe dat vooral samen!) een ´educated guess´ moeten maken. Daaruit zou kunnen komen:

• van alle mensen die een offerteberekening uitvoeren heeft 25% genoeg interesse om de productinformatie op te vragen (proces 1)

• product management schat dat 50% van alle vragen die nu via de telefoon worden gesteld straks via de site wordt afgehandeld. Dat betekent:

• 25 mensen raadplegen de informatie van een lopende schade (proces 5);

• 225 keer per dag worden frequently asked questions geraadpleegd (proces 6);

• 200 keer per dag zal een vraag via het contactformulier gesteld worden (proces 8)

• van alle mensen die de productinformatie bekijken download 10% de pdf (proces 7).

Dit levert de eerste versie van het loadmodel op (zie hieronder ‘Eindresultaat Educated Guesses’.

Eindresultaat: ‘Educated Guesses’

1. Raadplegen productinformatie 25.000 per maand

2. Opvragen offerte 100.000 per maand

3. Afsluiten autoverzekering 5.000 per maand

4. Doorgeven schademelding 50 per dag

5. Raadplegen schademelding 25 per dag

6. Raadplegen faq 225 per dag

7. Downloaden productinformatie 2.500 per maand

8. Vraag stellen via contactformulier 200 per dag

Je ziet in bovenstaand overzicht nog verschillende tijdseenheden. Hoewel de verleiding groot is om dit aan elkaar gelijk te trekken, doe dat nog niet! Bij punt ‘Availability’ zul je zien waarom niet.

Goals

We hebben nu gebruiksfrequenties voor alle processen zoals ze in de 'nu'-situatie bekend zijn. Belangrijk is nu om te kijken naar de business goals van de nieuwe applicatie, dit wordt dikwijls vergeten. Vaak heeft een systeem het doel om bijvoorbeeld een product dat ermee verkocht wordt, beter in de markt te zetten. Daarmee zal ook de belasting op het systeem toenemen. Probeer bijvoorbeeld de doelen van het systeem en het product over een jaar te benoemen.

Na lancering van de nieuwe site en de reclamecampagne verwachten we het eerste jaar 20% toename van het aantal geïnteresseerden op de site.

• De ambitie is dat door betere productvoorwaarden en agressieve campagnevoering aan het einde van het jaar niet 5%, maar 7% van alle offertes leidt tot een nieuwe polis.

• Daarnaast is de verwachting dat einde van het jaar er niet 50.000, maar 75.000 klanten verzekerd zijn, waardoor ook het aantal schademeldingen zal stijgen.

Deze gegevens moeten worden meegenomen naar het loadmodel. Bepaal naast de nu-situatie bijvoorbeeld een 'verwachte situatie aan het eind van het jaar', en naar behoefte eventueel nog andere toekomstscenarios.

Eindresultaat: ‘Goals’

1. Raadplegen productinformatie 30.000 per maand (huidige aantal + 20% toename)

2. Opvragen offerte 120.000 per maand (huidige aantal + 20% toename)

3. Afsluiten autoverzekering 8.400 per maand (aantal offertes x 7%)

4. Doorgeven schademelding 75 per dag (aantal klanten x 0,1% per dag)

5. Raadplegen schademelding 30 per dag (huidige aantal + 20% toename)

6. Raadplegen faq 270 per dag (huidige aantal + 20% toename)

7. Downloaden productinformatie 3.000 per maand (huidige aantal + 20% toename)

8. Vraag stellen via contactformulier 240 per dag (huidige aantal + 20% toename)

Availability

Een performancetest draait in een tijdsbestek van een aantal uren, niet in dagen of maanden. Daarom moet het gebruik worden omgerekend naar aantal processen per uur (of nog kleiner). Als je dat zou doen door het aantal keer per maand door 30 (gemiddeld aantal dagen in een maand) te delen en vervolgens door 24 te delen (aantal uren in een dag) dan ga je voorbij aan dat niet elke applicatie op elke dag en op elk uur van de dag gelijkwaardig wordt gebruikt. Stel jezelf daarom de volgende vragen?

• Wordt mijn applicatie op elke dag van de week ongeveer gelijkwaardig gebruikt? Zijn er bijvoorbeeld in het weekend gebruikers in actief? Voor een website bestemd voor klanten zal het antwoord positief zijn, maar een interne beheerapplicatie wordt in veel gevallen in de weekends niet gebruikt.

• [endif]--Zijn er uren van de dag waarop mijn applicatie niet/nauwelijks gebruikt wordt? Een internationale website wordt wellicht 24 uur van de dag gebruikt. Een nationale website wordt gedurende een uur of 14 (van 9:00 tot 23:00) intensief gebruikt, maar dus ook 10 uur niet. Een interne applicatie wordt misschien maar 8 uur (werkdag) intensief gebruikt. En zijn er wellicht nog verschillen per proces? Bijvoorbeeld: bij het omrekenen van het aantal frequently asked questions moet rekening worden gehouden dat de klantendesk van 9:00 tot 17:00 bereikbaar is, maar de website 24 uur per dag, 7 dagen in de week. ![endif]--

Twee rekenvoorbeelden voor Availability:

Raadplegen productinformatie - 30.000 keer per maand. De site wordt 7 dagen per week actief gebruikt, maar enkel in Nederland, dus ongeveer 14 uur per dag. Dat betekent 30.000 gedeeld door gemiddeld 30 dagen per maand gedeeld door 14 uur per dag is ongeveer 71 keer per uur.

Chatten met de online-helpdesk - 600 keer per week gedurende werkdagen van 9:00 tot 21:00. Dat betekent per dag gemiddeld 120 vragen, uitgesmeerd over 12 uur per dag maakt gemiddeld 10 vragen per uur.

Deze beschikbaarheidscalculatie mag absoluut niet vergeten worden! Een voorbeeld wat er gebeurt als je deze omrekening vergeet:

100.000 keer proces ‘verwerken factuur’ per maand betekent voor een Internationale website (24 uur per dag, 7 dagen per week): 3333 keer per dag, is 139 keer effectief per uur.

Voor een interne applicatie (8 uur per dag, 5 dagen per week):zijn de uitkomsten echter totaal verschillend: 100.000 keer gedeeld door 20 werkdagen in een maand is 5.000 keer per dag, gedeeld door 8 uur per dag is 625 keer effectief per uur gedurende de actieve uren. Dat betekent een verschil van bijna factor 5! Zorg dus dat je weet wanneer je applicatie gebruikt wordt!

Eindresultaat: ‘Availability’

1. Raadplegen productinformatie 71 keer per uur

2. Opvragen offerte 286 keer per uur

3. Afsluiten autoverzekering 20 keer per uur

4. Doorgeven schademelding 5 keer per uur

5. Raadplegen schademelding 1,5 keer per uur

6. Raadplegen faq 14 keer per uur

7. Downloaden productinformatie 7 keer per uur

8. Vraag stellen via contactformulier 12 keer per uur

Hierboven staat nu exact waar je performancetester naar op zoek is om een performancetest te kunnen creeren. Hij zal virtuele gebruikers op het systeem laten werken, met deze gebruiksstatistieken. Een belangrijke schakel ontbreekt echter nog, de piekvolumes!

Peaks

De meeste applicaties hebben piekmomenten. Dat kunnen pieken per dag zijn (klantensites vaak aan het begin van de avond), of per week (een applicatie waarin uren worden geboekt vaak op vrijdagmiddag), of per maand (maandafsluiting) of zelfs per jaar (de piek van pintransacties rond de kerstdagen). Daarnaast heb je soms minder voorspelbare, maar daarom niet minder benoembare pieken. In onze casus is de toename van schademeldingen bij winterse omstandigheden een mooi voorbeeld. Beschouw daarom per proces of er aanwijsbare regelmatige of incidentele pieken zijn. In ons geval weet ‘product management’ te vertellen:

Structurele pieken zijn de planbare pieken: vraag bij de business stakeholders naar dagelijkse, wekelijkse, maandelijkse of jaarlijkse pieken. Voorbeelden:

• Dagelijks: aan het begin van de avond zijn er 3 keer zoveel bezoekers op een retailwebsite dan normaal;

• Wekelijks: op vrijdagmiddag wordt 90 procent van de urenstaten ingevuld;

• Maandelijks: salarisfacturen worden vaak in batch op één willekeurig moment in de maand opgemaakt;

• Per kwartaal: de omzetbelasting wordt aan het begin van een nieuw kwartaal doorgegeven;

• Jaarlijks: in de laatste week van mei en de eerste twee van juni (vakantiegeld) worden er online 5 keer zoveel televisies verkocht.

Incidentele pieken zijn pieken die niet van tevoren in te plannen zijn, maar wel gerelateerd kunnen worden aan een specifieke gebeurtenis.

• In de wintermaanden kan het aantal schademeldingen bij winterse omstandigheden oplopen tot 5x zoveel als normaal.

• Na een renteverlaging kijken 10 keer zoveel mensen of oversluiten voor hen interessant kan zijn.

Eindresultaat: ‘Peaks’

1. Raadplegen productinformatie 3 x normaal

2. Opvragen offerte 3 x normaal

3. Afsluiten autoverzekering 3 x normaal

4. Doorgeven schademelding 5 x normaal (winterpiek, met de aanname dat mensen schade zsm melden en er dus niet een extra piek is tussen 19:00 en 20:00)

5. Raadplegen schademelding 15 x normaal (wintermaanden, met de aanname dat ook de dagelijkse piek tussen 19:00 en 20:00 van toepassing is)

6. Raadplegen faq 3 x normaal

7. Downloaden productinformatie 3 x normaal

8. Vraag stellen via contactformulier 3 x normaal

Specials

De laatste stap zijn de Specials. Ga na of er hele uitzonderlijke omstandigheden zijn en bespreek met de businessorganisatie hoe je hiermee om wilt gaan.

Een voorbeeld: normaal verwacht men 4.000 offerteberekeningen per dag, maar in de eerste twee weken na GoLive wordt een enorme tv-reclamecampagne gelanceerd. Uit ervaring is bekend dat het aantal bezoekers direct na de reclamespot gedurende een uur kan oplopen tot 50x de normale hoeveelheid, en daarna loopt het geleidelijk weer af tot normale proporties.

De vraag is of je het systeem hierop wilt dimensioneren. Als je systeem dergelijke aantallen moet aankunnen is het systeem gedurende 99% van de tijd waarin het normaal belast wordt overgedimensioneerd en dat kost uiteraard geld! Het kan een afgewogen keuze zijn dat een applicatie een bijzondere piek niet aankan, denk aan het telefoon tijdens de jaarwisseling. Dat hoeft niet erg te zijn, als maar een bewuste businessbeslissing is gemaakt van baten en kosten.

De finale selectie van processen

Je hebt er nu alles aan gedaan om de juiste input te leveren, de gemiddelde performancetester zal verrast opkijken als hij een dergelijk uitgewerkt loadmodel krijgt. Hiermee kan hij beginnen om de performancetest technisch uit te werken. Voor performancetests moeten geautomatiseerde scripts worden gemaakt. Dat betekent dat er code geschreven moet worden om andere code te testen. Dat is tijdrovend en dus duur. Het doel van een performancetest moet dus niet zijn om ALLE mogelijke processen in een applicatie te testen. Sterker nog, mijn streven is altijd: probeer met zo min mogelijk processen zoveel mogelijk van het gebruik af te dekken. Mijn ervaring, zeker bij webapplicaties, is dat je vaak met 10% van de processen 90% van het gebruik kunt afdekken.

Bepaal daarbij ‘Welke processen in de applicatie worden het meest gebruikt?’, aangevuld met ‘Welke processen in de applicatie zijn het ‘duurst’ (zodanig complex dat ze meer systeemcapaciteit opsouperen)’.

In onze casus blijken we aan de eerste drie processen genoeg te hebben om 90,5% van alle klantbewegingen af te dekken, eventueel aangevuld met het proces ‘downloaden van de productieinformatie pdf’, omdat dat het downloadbestand erg groot is. Deze informatie hoef je uiteraard niet zelf te bedenken, maar vraag je performancetester om met de systeemontwikkelaars uit te zoeken of er nog bijzonder zware processen bij zitten. Of doe dat zelf.

Tot slot

In de praktijk zie ik in mijn rol als testmanager vaak dat goede loadmodellen voor performancetesten ontbreken of te laat in het project worden gemaakt. Businessorganisaties zijn dikwijls terughoudend om mee te werken, enerzijds omdat investeren in een dergelijk onderzoek tijd kost, anderzijds omdat het aanleveren van gegevens betekent dat men kan worden afgerekend wanneer deze onjuist blijken. Vaak is het formuleren van een loadmodel echter helemaal niet zo moeilijk en ook niet bijzonder tijdrovend. Het begint met het interviewen van de juiste mensen en het stellen van de juiste vragen. En dan zul je zien dat een aanpak volgens bovenstaande structuur al snel een bovengemiddeld goed resultaat oplevert, dat bovendien helder en in Jip-en-Janneke-taal uitlegbaar is aan management en andere stakeholders.