Wanneer ontwikkelpartijen een applicatie hebben ontwikkeld moeten ze verschillende kwaliteitsaspecten nalopen. Hiervoor gebruiken ze vaak een eenvoudige checklist. Functionele kwaliteit? Check. Compliance? Check. Performance? Check!
Dan is het de beurt aan de beherende partij: zij stellen de benodigde hardware samen volgens de specificaties van de ontwikkelaars. Hierop wordt het nieuwe softwarepakket geïnstalleerd. Ook hierbij worden er nog een aantal functionele testen gedaan en dan kan de applicatie in productie.
Niet zo lang en gelukkig…
In eerste instantie functioneert de nieuwe applicatie naar behoren. Maar na een aantal weken komen toch klachten: de applicatie is toch niet zo snel als verwacht. Wanneer de traagheid niet wordt opgelost, kan het van kwaad tot erger gaan totdat de applicatie onwerkbaar is. Het herstarten van de servers biedt een tijdelijke oplossing, maar uiteindelijk keren de problemen terug. Het opschonen van data is ook een techniek die de applicatie weer tijdelijk nieuw leven in blaast. Door beide technieken regelmatig toe te passen lijkt de applicatie stabiel. Dit is echter pleisters plakken in plaats van de wonden helen. Het beheer van de applicatie wordt hiermee een dagelijkse zorg.
Bij een slecht presterende applicatie zien we vaak dat betrokken partijen bij de schuldvraag naar elkaar wijzen. Externe consultants worden ingevlogen om onderzoek naar de bottleneck te doen, maar de verbetermogelijkheden zijn beperkt nu de applicatie al live is. Een snelle oplossing lijkt buiten handbereik en de onderlinge verhoudingen tussen de betrokken partijen wordt er vaak niet beter op.
Problemen voorkomen
Dit scenario komen we in de praktijk nog veel tegen, maar is niet nodig. Voordat een applicatie wordt gelanceerd kan met een performancetest in de testomgeving worden nagegaan hoe deze onder belasting zal presteren. Het samenstellen en uitvoeren van een goede performancetest is echter niet eenvoudig. De test moet van hoge kwaliteit zijn om écht inzicht te bieden in de performance, waarnaar er een verbeterslag kan worden gemaakt.
Maar hoe ziet een goede performancetest er dan uit? De test moet een juiste samenstelling van scenario’s hebben, waarmee specifieke risico’s op performance worden getoetst. Een website die beschikbaar moet zijn tijdens noodsituaties, moet bijvoorbeeld veel verkeer tegelijkertijd aankunnen. Een applicatie die maar een klein aantal gebruikers heeft, moet vooral snel zijn en daarbij is de piekbelasting van ondergeschikt belang. Andere vragen kunnen zijn: herstelt een applicatie zelfstandig na overbelasting? Of wat gebeurt er als de infrastructuur tijdelijk verbroken wordt? Iedere applicatie heeft een ander type performance test (of meerdere typen) nodig om de gewenste scenario’s te testen.
De kwaliteit van applicaties valideren met behulp van performance testen voor livegang is dus belangrijk maar vereist enige kennis en uiteraard is de juiste tooling nodig. Uit de testen komt noodzakelijke kennis waarmee de juiste configuratie en schaling van een applicatie in de productieomgeving bepaald kan worden. Het is dus van belang om met een leverancier goed af te stemmen welke snelheid gebruikers mogen verwachten en om dit door te vertalen naar de juiste testen. Hiermee voorkom je dat een applicatie bij livegang toch niet naar behoeven functioneert en behoud je tevreden gebruikers. Ready? Test, go!
Reacties
Bent u bekend met de oplossingen van Smartbear?