Stress testing is de praktijk waarbij je software bewust overbelast om het breekpunt te vinden. In plaats van te controleren of het systeem onder normaal gebruik werkt, overspoel je het met veel meer verkeer, data of gelijktijdige gebruikers dan je verwacht, en kijk je wat als eerste faalt en hoe het herstelt.
Stel je voor dat je een brug test door er steeds zwaardere vrachtwagens op te zetten tot er iets buigt. Zulk zwaar verkeer laat je nooit echt toe, maar de test laat de werkelijke grens en de zwakste balk zien. Stress testing doet hetzelfde voor software: het onthult of de database, het netwerk of de server het eerst bezwijkt, en hoe hard de latentie oploopt naarmate de belasting stijgt. De uitkomsten wijzen vaak naar oplossingen als auto-scaling of betere load balancing.
Het doel is niet om de test netjes te halen. Het doel is om de fout op jouw voorwaarden te vinden, in een gecontroleerde run, in plaats van tijdens een echte piek met betalende klanten die meekijken. Wat de test leert, is vaak een verrassing. Teams verwachten dat de webservers het eerst begeven en ontdekken dat één database-query, onschuldig bij weinig verkeer, vastloopt zodra duizenden mensen hem tegelijk draaien. Of een externe dienst die je op elke pagina aanroept blijkt het plafond te zijn, niet je eigen code. Er zit ook een zachtere les in hóe een systeem faalt. Een goed ontwerp wordt netjes trager en toont onder extreme belasting een beleefd ‘even geduld’. Een broos ontwerp valt volledig om en laat bezoekers een foutscherm zien. Weten welke van de twee je hebt gebouwd, vóór de lanceerdag, is veel meer waard dan een groen vinkje dat alleen bewijst dat de makkelijke weg werkt.
Bij TopDevs draaien we een stresstest vóór elke lancering waar we drukte verwachten, zodat de zwakke plekken in een rustige repetitie opduiken en niet op de drukste dag van het jaar.
