Performance testen met TMAP

Wat is performance testen eigenlijk?

Als we het over performance hebben, denken veel mensen meteen aan snelheid. "Hoe snel opent deze pagina?" Dat is een goed begin, maar het is niet het hele verhaal. Performance testen gaat over het gedrag van een systeem onder verschillende omstandigheden.

Binnen de TMAP kwaliteitsattributen kijken we naar de mate waarin een systeem voldoet aan de doelen voor reactietijd en verwerkingskracht. Je kunt het vergelijken met een auto. Een auto die op een lege weg 120 kilometer per uur rijdt, heeft een goede snelheid. Maar wat gebeurt er als er vijf personen in zitten, een dakkoffer op het dak staat en er een caravan achter hangt? Blijft de auto dan nog steeds soepel rijden, of valt hij stil bij de eerste de beste heuvel?

Bij software kijken we naar drie belangrijke zaken:

1. Responstijd: Hoe snel krijgt de gebruiker antwoord na een klik?
2. Doorvoersnelheid (Throughput): Hoeveel transacties kan het systeem tegelijkertijd aan?
3. Resourcegebruik: Hoeveel geheugen en rekenkracht heeft het systeem hiervoor nodig?

Waarom performance testen cruciaal is in Agile en DevOps

Vroeger was performance testen iets dat je helemaal aan het einde van een project deed. Er was een speciale 'testfase' waarin dure tools werden ingezet om het systeem op de pijnbank te leggen. In de moderne wereld van Agile en DevOps werkt dat niet meer. We leveren constant kleine stukjes software op. Als je pas aan het einde van het jaar test of het systeem snel genoeg is, ben je veel te laat.

Als een systeem traag is, haken gebruikers af. Onderzoek laat zien dat elke seconde extra levertijd direct ten koste gaat van de klanttevredenheid en omzet. Voor een student informatica is dit een harde les: een technisch perfecte app die traag reageert, wordt door niemand gebruikt. Voor een Product Owner is het simpel: slechte performance is een bedrijfsrisico.

Daarom spreken we binnen TMAP over 'shift-left'. Dit betekent dat we zo vroeg mogelijk beginnen met testen. Performance is geen 'vinkje' achteraf, maar een gesprek dat je al voert bij het verfijnen van een User Story.

Maak performance concreet met het TMAP VOICE-model

Het lastige van performance is dat het vaak vaag blijft. "De app moet snel zijn," zegt de business. Maar wat is snel? Voor een banktransactie is twee seconden prima, maar voor een actiegame is het een eeuwigheid. Om dit meetbaar te maken, gebruiken we binnen de e-learning TMAP: Quality for Cross-Functional Teams het VOICE-model. Dit helpt je om verder te kijken dan alleen de techniek.

Value (Waarde)

Vraag jezelf af: welke waarde levert snelheid op voor de gebruiker? Bij een webshop betekent een snelle checkout direct meer verkopen. Bij een interne bedrijfsapplicatie betekent een snellere zoekfunctie dat medewerkers minder gefrustreerd zijn en meer werk kunnen verzetten. Als je de waarde kent, weet je ook hoeveel tijd en geld je in het testen moet steken.

Objectives (Doelen)

Stel harde doelen vast. In plaats van "de app moet snel zijn", spreken we af: "95% van alle zoekopdrachten moet binnen 800 milliseconden een resultaat tonen bij 500 gelijktijdige gebruikers." Nu heb je iets dat je echt kunt meten.

Indicators (Indicatoren)

Hoe meten we of we de doelen halen? Hier komen de technische termen om de hoek kijken, zoals latency, CPU-load en memory usage. Dit zijn de instrumenten op je dashboard die vertellen hoe de motor van je software ervoor staat.

Confidence (Vertrouwen)

Dit is misschien wel het belangrijkste onderdeel voor een tester of QA-engineer. Hebben we genoeg getest om met een gerust hart 'live' te gaan? Als je alleen een test hebt gedaan met één gebruiker, is je vertrouwen laag. Heb je een zware loadtest gedaan die lijkt op de echte wereld? Dan is je vertrouwen hoog.

Experience (Ervaring)

Cijfers zeggen veel, maar niet alles. Soms voelt een app traag aan, ook al zijn de laadtijden technisch gezien prima. Bijvoorbeeld omdat er geen laad-icoontje in beeld komt. De beleving van de eindgebruiker is de uiteindelijke graadmeter voor succes.

Herkenbare situaties: Wanneer gaat het mis?

Om te begrijpen waarom we dit doen, kijken we naar een paar voorbeelden uit de dagelijkse praktijk van IT-teams.

De groeiende database

Een team bouwt een nieuw portaal voor een woningbouwvereniging. Tijdens het ontwikkelen werkt alles flitsend. Er staan immers maar tien testwoningen in de database. Maar zodra het systeem gevuld wordt met 50.000 woningen en 100.000 huurders, duren de zoekopdrachten ineens tien seconden. De database-query die op kleine schaal werkte, blijkt niet schaalbaar. Met performance testen op een representatieve dataset had dit team dit probleem al maanden eerder ontdekt.

Het mobiele netwerk

Een developer bouwt een prachtige feature op een snelle MacBook met een stabiele glasvezelverbinding. Maar de eindgebruiker zit in de trein met een matig 4G-signaal op een drie jaar oude telefoon. Als de app dan drie megabyte aan JavaScript moet inladen voordat er iets gebeurt, ervaart die gebruiker een enorme traagheid. Hier zie je dat performance ook te maken heeft met hoe je je software bouwt (bijvoorbeeld door code-splitting).

Het geheugenlek

Sommige problemen zie je niet meteen. Een applicatie kan de eerste uren prima draaien, maar langzaam steeds meer geheugen opsnoepen. Na twee dagen crasht de server ineens zonder duidelijke reden. Dit soort 'soak tests' (langdurige tests) zijn een essentieel onderdeel van een goede performance-strategie.

Hoe maak je performance testen testbaar in je team?

In een cross-functional team is kwaliteit de verantwoordelijkheid van iedereen. Dus ook performance. Hier zijn drie stappen die je morgen al kunt zetten:

1. Stel vragen bij de User Story: Als de Product Owner een nieuwe feature wil, vraag dan direct: "Hoeveel mensen gaan dit tegelijk gebruiken?" en "Wat is de maximale wachttijd die we acceptabel vinden?"
2. Monitor in productie: Gebruik tools om te zien hoe de software zich in het echt gedraagt. Als je ziet dat bepaalde functies steeds trager worden, kun je ingrijpen voordat het een serieus probleem wordt.
3. Test klein: Je hoeft niet altijd een enorme loadtest te doen. Een developer kan tijdens het schrijven van code al kijken hoeveel database-calls er worden gedaan. Minder calls is bijna altijd betere performance.

Structureel beter worden met Testlearning

Performance testen is een vak apart, maar de basisprincipes horen thuis in de gereedschapskist van elke IT-professional. Of je nu een developer bent die snellere code wil schrijven, of een tester die wil leren hoe je risico's in kaart brengt: kennis van TMAP helpt je hierbij.

In onze e-learning TMAP: Quality for Cross-Functional Teams gaan we diep in op deze kwaliteitsattributen. We leren je niet alleen de theorie, maar vooral hoe je dit in de praktijk toepast binnen een Agile of DevOps omgeving. Je leert hoe je samen met je team de juiste prioriteiten stelt, zodat je niet alles tot in den treure hoeft te testen, maar precies die onderdelen aanpakt waar de grootste risico's liggen.

Het voordeel van onze digitale trainingen is dat je leert op je eigen tempo, met voorbeelden die direct herkenbaar zijn voor jouw werkdag. Geen saaie lappen tekst, maar praktische handvatten waar je direct iets aan hebt.

Snelheid is een keuze

Softwarekwaliteit is niet iets dat per ongeluk ontstaat. Het is het resultaat van bewuste keuzes. Door performance testen serieus te nemen en de principes van TMAP toe te passen, voorkom je dat jouw team kostbare tijd moet besteden aan het blussen van brandjes in productie. Je bouwt software waar gebruikers blij van worden en die de groei van je organisatie ondersteunt in plaats van afremt.

Wil je ook leren hoe je kwaliteit structureel verankert in jouw team? Bekijk dan ons aanbod aan TMAP-opleidingen en zet de volgende stap in je professionele ontwikkeling. Want een snelle applicatie begint bij een team dat weet wat het doet.