Organisaties kiezen er nog steeds vaak voor om hun applicatie alleen maar functioneel te testen. Performance testen wordt als moeilijk en arbeidsintensief beschouwd, waarbij testen als geheel als sluitpost op de begroting wordt gezien.
Tegelijkertijd hebben maar weinig mensen in de gaten, hoe complex hun applicatie landschap eruit ziet en welke eisen er gesteld zijn om voorspelbare IT aan te bieden. Dit heeft allemaal te maken met het feit dat het applicatie landschap steeds complexer aan het worden is, aangedreven door nieuwe technologie in de cloud met in begrip van containers en microservices. De wereld is in sneltrein vaart het hebben van monolitische software aan het afbouwen. Het doel is sneller veranderingen door te voeren waar de business om vraagt. En dat vraagt om een andere manier van testen dan de traditionele manier. Waarom?
Omdat cloud based applicaties niet bestaan totdat ze worden aangeroepen. Je kunt beginnen met slechts drie regels code, maar wanneer een gebruiker ermee in aanraking komt, kunnen er wel honderd functies in werking treden.
Het stellen van performance gerelateerde onderwerpen aan uw SAAS-partij is uit de boze. Je neemt ook aan dat een SAAS-partij zijn zaken op orde heeft. Immers uw SAAS-partij heeft veel klanten, u moet zich geen zorgen maken. “En als er problemen zijn, dan hebben we dat snel opgelost”.
Veelal blijkt dat SAAS -partijen er een potje van maken, geen performance testen uitvoeren, onvoldoende monitoring hebben ingericht om problemen snel te identificeren, of u wegwimpelen door te stellen dat zij grote klanten hebben waar performance geen probleem is. Daar zit u dan, 4 uur van onbeschikbaarheid en weg dagomzet.
“Bij ons gaat nooit wat fout”, “We hebben de laatste tijd geen prio 1 incidenten”, “Als er wat fout gaat met de SAAS applicatie, dan moet de SAAS leverancier het oplossen” zijn vaak gehoorde kreten. En toch staat u bij Allestoringen.nl, klagen uw consumenten op Social Media over uw organisatie met overbelasting van uw servicedesk tot gevolg. Als bedrijf is de bedrijfsvoering wel sterk afhankelijk van SAAS dienstverlening en zijn papieren SLA’s al lang niet voldoende meer om de oorzaak van een productie probleem in 10 minuten te vinden. Medewerkers kunnen meldingsmoe zijn van het zoveelste probleem te melden, beheerders staan met de handen in het haar omdat de leverancier weigert het probleem serieus te onderzoeken.
Praktijkvoorbeelden laten helaas te vaak zien dat incidenten niet tot op de bodem worden uitgezocht. Het incident wordt opgelost met een lapmiddel, maar het probleem ettert op de achtergrond rustig door totdat het opnieuw losbarst.
De realiteit is echter ook dat veel mensen tegenwoordig thuis moeten werken, bedrijven meer als ooit tevoren zich moeten kunnen beroepen op beschikbare en presterende IT-diensten. Om testen dan nog als een sluitpost te beschouwen, is het spelen met vuur.
- Het achterhalen van de oorzaak van incidenten kost veel tijd door de complexiteit van het applicatie landschap.
- We zien performance problemen te laat, pas op een pre-productie omgeving.
- Ketens worden complexer door het aantal betrokken applicaties, microservices, containers en de orchestratie ertussen, infrastructuur en de verantwoordelijke partijen. Niemand heeft het overzicht en het inzicht om snel issues te duiden.
- Performance testen kost veel tijd om het gerealiseerd te krijgen.
- Huidige Performance testen laten alleen responstijd tabellen zien, maar we weten nog steeds niet wat de oorzaak is. Daar zijn we naar op zoek.
- We kunnen niet op locatie bij onze klanten testen; zij ervaren de problemen, maar zitten over de wereld verspreid.
- We hebben geen standaard web gebaseerde applicaties en dus kunnen we het niet op performance testen. De problemen houden aan, veel tijd gaat verloren aan registratie en administratie van incidenten in plaats van het structureel oplossen. We komen niet verder.
- We willen performance testen integreren in onze CI-pipeline alleen weten niet wat er allemaal om de hoek komt kijken.
- Bij performance problemen worden we van het kastje naar de muur gestuurd. Op den duur sijpelt het probleem van zelf weer weg.
- Service levels worden niet gehaald
- Time-to-market wordt niet gehaald
- Inefficiency
- Exploitatie kosten/herstelkosten te hoog
- Sprintplanning onder druk
- Improductiviteit van medewerkers, geen focus voor de werkzaamheden
- Imagoschade van bedrijf
- Omzetverlies
- Het niet halen van de bedrijfsdoelen
- Geen sturing en geen vooruitgang in leveranciersgesprekken bij performance problemen
- Eerder testen (Shift Left) om eerder problemen te detecteren.
- Sneller problemen identificeren (MTTI).
- Voorspelbaarder worden op performance SLO’s (beschikbaarheid en responstijd).
- Voorkomen van incidenten (Sterke reductie prio 1 incidenten).
- Integratie met CI tooling voor automatisch performance testen.
- Testen van applicatie protocollen anders dan alleen maar web (bijvoorbeeld VOIP).
- Samenwerken met de SAAS-partij bij performance problemen door het hebben van een gemeenschappelijk performance referentiekader.
Intake
Elke performance test start met het doen van de intake om te begrijpen wat er getest moet worden met welke eisen (Non Functional Requirements), hoe de testomgeving eruit ziet, welke test data nodig er nodig is, op welke manier we de gedragingen van de applicatie, de bijbehorende resources en infrastructuur gemonitord worden, eventuele performance problemen die er zijn etc. Het geeft ons een totaal beeld zodat we deze kunnen gaan vertalen in de vervolgstappen met bijbehorende planning.
Non Functional Requirements
Valideren van de testresultaten gebeurt door te starten met het vastleggen aan welke eisen de applicatie dient te voldoen. Hoe snel moet een applicatie presteren voor een eindgebruiker? En hoeveel procent moet de applicatie functionaliteit beschikbaar zijn? Deze eisen, de zogenaamde Non Functional Requirements worden van te voren vastgelegd samen met de klant. Om na de testen te kunnen zeggen of de applicatie voldoet aan de eisen.
Test scripts
De eindgebruikershandelingen worden vastgelegd in een test script. Hierdoor is de test op elk gewenst moment te herhalen. We gaan niet teveel handelingen meten. Door slim deze eindgebruikershandelingen te kiezen op basis van productiegebruik komen we tot de juiste representatieve mix.
Opbouw testomgeving
Het verkrijgen van representatieve testen vraagt om een representatieve testomgeving. Niet geschaalde omgevingen kunnen cijfermatig niet zomaar geëxtrapoleerd worden om tot grote voorspelbaarheid en betrouwbaarheid te komen. Een niet volledige test omgeving E2E kan opgelost worden door het toepassen van service virtualisatie.
Test tool
Voor de test worden zogenaamde robots gebruikt die de test scripts draaien. Deze test robots kunnen on-premise draaien of ergens in de wereld. Het argument is om de test zo dicht mogelijk bij uw echte gebruikers te draaien om het zo representatief en dus betrouwbaar te maken.
Test Data
Bij performance testen hoort ook voldoende test data die voldoet aan bepaalde eisen. Een uur testen met verschillende gebruikersprofielen eist bepaalde test data. De te raadplegen test data in de database dient een productie vulling te hebben om betrouwbare test resultaten te verkrijgen. Met onze dienst kunnen we helpen om test data te genereren dat voldoet aan de eisen.
Monitoring
Tijdens de testen wordt de testomgeving in de gaten gehouden met monitoring. Deze monitoring kan door de klant worden gedaan, of ingericht worden door 360Performance. Onderscheid wordt er gemaakt in traditionele technische monitoring (CPU, memory, disk, netwerkkaart) en APM-monitoring (Full-stack monitoring inclusief applicatie laag). De keuze bepaalt de mate van oplossendvermogen afhankelijk van low hanging fruit of dieper verborgen performance probleemoorzaken.
Type Test
We bieden zes verschillende smaken testen aan: load, endurance, volume, scalability, spike and stress. Ieder van deze testen hebben een ander doel.
Test executie
De test is op afstand te volgen. Met al het thuiswerken is het geen enkel probleem om middels een dashboard uw mensen de test te laten volgen. Dit levert het voordeel dat uw technische mensen direct op de betrokken systemen, applicaties en infrastructuur kunnen kijken in geval van problemen.
Test resultaat
De testresultaten worden weergegeven middels een tabel. De responstijd en beschikbaarheid van te voren te testen eindgebruikershandelingen worden getoond en gewogen aan de hand van de 95ste en 99ste percentiel waarbinnen de responstijden vallen. Op deze manier kun je gemakkelijk zien of je je test doel hebt gehaald of niet.
Analyse
Indien men de test uitvoert met behulp van een APM tool zoals Dynatrace, dan zijn we staat om de applicatie te diagnosticeren. Op deze manier vinden we de root cause van eventuele performance blemen. Ook weten we op welke manier de code in samenhang met de beschikbare resources heeft samengewerkt. Deze fact based onderbouwing maken performance test een stuk betrouwbaarder, en zien we geen zaken over het hoofd.
Testrapport/Testbrief
Na analyse volgt de vastlegging van de resultaten, de bevindingen en de conclusies met aanbevelingen wat de volgende stap moet zijn. Het testrapport wordt altijd besproken met de klant om duidelijkheid te geven, om te voorkomen dat er open einden zijn waarmee de klant niet verder kan gaan.
Testregie
Performance testen vraagt om regie om testen gerealiseerd te krijgen en naderhand snel de bevindingen opgepakt te krijgen. Veel disciplines en externe partijen kunnen er bij betrokken zijn met ieder hun eigen agenda. Dwingende ogen gelden veelal en dat zetten wij in om zaken snel voor elkaar te krijgen. De regisseur bewaakt het geheel, zorgt voor de tijdige communicatie tussen de stake-holders, jaagt op waar nodig met als doelen:
- Hoe eerder we testen, hoe eerder we de oorzaak weten.
- Hoe sneller de bevindingen worden opgepakt, des te sneller kunnen we hertesten en weten of het probleem is opgelost.
Bevindingen registratie en opvolging
Het doen van bevindingen, het registreren ervan en te zorgen dat men aan de slag gaat met de bevindingen is belangrijk om tot de oplossing te komen. Inhoudelijk zijn we geïnteresseerd wat er veranderd is zodat we begrijpen wat er getest moet worden en waar we naar moeten kijken om te bepalen dat het ook daadwerkelijk is opgelost.
Hertesten
Hertesten zijn nodig om gedane bevindingen met de bijbehorende oplossingen te testen. Op deze manier wordt de kwaliteit gevalideerd, en de voorspelbaarheid van de oplossing getoetst.
Naadloze integratie
Performance tests alone don’t always paint the full picture. Incorporating application monitoring allows you to take a centralized approach to data collection and connect the dots. LoadRunner Cloud has a rich selection of third-party tools to integrate with: continuous integration (CI) servers, such as Jenkins, Azure DevOps, Bamboo, and AWS CodePipeline; APM tools such as SiteScope, Application Insights, AppDynamics, Dynatrace, and New Relic; and Git, Splunk, Network Virtualization (NV), and WebPageTest. These integrations offer flex- ibility and allow your agile testing and develop- ment teams to run performance tests as part of their builds in an easy, automated manner.
Ondersteunde protocollen
JMeter, Gatling, Selenium, Web HTTP/HTML, Java, Mobile (Web), Web Services protocol, TruClient, DevWeb, MultiSAP Web + SAP UI, .NET MultiOracle + Web, Citrix, UFT Developer, MQTT, Siebel
Ondersteunde browsers
Chrome, Firefox, Safari and Edge
Load Generatoren in de wereld
Zet de volgende stap
Ontdek hoe 360Performance u kan helpen bij het opzetten, uitvoeren of verder professionaliseren van performance testen.
Met alle liefde laten we je zien wat Performance testen 3.0 is, wat we te bieden hebben en zoomen daarbij graag in op specifieke wensen en vragen!
