‘Data driven’, een oude term, die tegenwoordig weer steeds meer gebruikt wordt. Hoewel het jaren geleden al gebruikt werd als programmeermodel, waarbij de data de flow van een applicatie stuurt in plaats van de applicatielogica zelf, lijkt het nu in alle markten toegepast te worden. Even kort googlen resulteert in pagina’s over marketing, journalistiek, economie, management, noem maar op. Maar wat betekent deze term in de performance wereld?
Betekenis
Op het internet lijkt er genoeg te vinden te zijn over data driven performance (of load) testing, maar eigenlijk wordt de methode waar ik op doel vrijwel nergens vermeld. Er wordt gesproken over data sources waarmee je testscripts kunt voeden. Denk aan inloggegevens, gebruikerskarakteristieken, sessiegegevens, eigenlijk alles wat dynamisch kan of moet zijn in een loadtestscript, als het informatie is die voorafgaand aan een handeling bekend moet zijn. Maar dit is toch vrij standaard bij een testvorm waarbij je honderden of duizenden gebruikers op een applicatie wilt simuleren, zal je misschien denken. Dat klopt! Het gebruik van data sources maakt een script nog niet data driven, daarom vind ik een groot deel van de gevonden teksten misplaatst. In de meeste gevallen ondersteunt de data de logica van een script, zoals vaak het geval is in een ‘normale’ performance test, in plaats van andersom.
Wat ik bedoel gaat een stuk verder. Wat nou als de volledige controle van een testscript wordt uitgeoefend door een data source, welke alle benodigde input bevat, waardoor het script zelf slechts de handvatten biedt om deze input te verwerken? Niet meer een testscript die een vooraf gedefinieerde flow volgt, maar een flow die wordt gecreëerd op basis van informatie die extern aangeleverd wordt. Dat zou een performance test veel realistischer maken, mits de data een representatieve weergave van de werkelijkheid is.
Voorbeeld
Misschien is bovenstaande allemaal nog wat vaag, maar laat ik een concreet voorbeeld geven. Beheerders van een webshop zien in de productieomgeving plotseling een enorme drukte ontstaan, waarna de responstijden omhoog schieten en klanten fouten op hun scherm te zien krijgen. Tijdens de drukte is er chaos in het bedrijf en het direct achterhalen van het probleem is lastig. De webshop heeft wel een representatieve testomgeving waarop later gecontroleerd uitgezocht kan worden wat er precies aan de hand was. Als de juiste data is opgeslagen, dan zou er met deze data driven methode in theorie een exacte reproductie kunnen plaatsvinden van hetgeen er op de productieomgeving is gebeurd, om zo gecontroleerd de oorzaak te kunnen achterhalen. Kan dat dan niet met een performance test zoals je die gewend bent uit te voeren? Misschien, misschien niet. Op deze manier worden er in ieder geval niet zomaar lukraak wat hits op verschillende functionaliteiten gegenereerd, maar exact de situatie die zich heeft afgespeeld. Niet alleen maar het zelfde aantal ingelogde klanten die een standaard flow volgen, maar exact dezelfde ingelogde klanten, die dezelfde handelingen uitvoeren als wat zich op productie heeft afgespeeld. Dezelfde zoekopdrachten, dezelfde aankopen, dezelfde bedragen, allemaal op exact dezelfde relatieve tijdstippen. Wanneer de oorzaak geen toeval is geweest, zouden de problemen op hetzelfde moment moeten optreden. Je kunt daar dan op anticiperen en alles monitoren, zodat je de controle houdt over de systemen en precies weet wat er gebeurt.
Belemmeringen
Dit klinkt in mijn oren allemaal vrij logisch en zou dan ook overal toegepast kunnen worden. Maar zo makkelijk is het niet. Alles valt of staat met 2 belangrijke zaken. De beschikbare informatie die als input moet dienen en de staat van de omgeving. De input is in dit geval natuurlijk de gegevens uit productie. Maar dat kan vaak niet zomaar beschikbaar worden gesteld. Uit het oogpunt van veiligheid en integriteit kunnen klantgegevens niet altijd zomaar worden gebruikt. Dat meneer de Jong een boek van 9,95 heeft besteld kan misschien niet zoveel kwaad, maar als het over bankzaken zou gaan, zitten daar weer allerlei restricties aan vast. Bovendien is toegang verkrijgen tot productielogs vaak een vak op zich. De staat van de omgeving is ook zeer belangrijk. Als de testomgeving niet gelijk geschaald is aan productie, als er componenten ontbreken op de testomgeving, als er andere configuraties worden gebruikt, als niet alle gebruikers in de testdatabase staan, of bedenk nog talloze redenen waarom de staat van de testomgeving niet gelijk is aan die van productie, dan gaat deze vlieger niet op. Er moet een (bijna) 100% representatieve test gedaan kunnen worden, anders is het de moeite niet waard om zoveel extra tijd te besteden om deze methode te hanteren, ten opzichte van een ‘normale’ performancetest.
Voorbeeld 2
Is dit nou alleen toe te passen wanneer er een verstoring is geweest die gereproduceerd moet kunnen worden? Nee, natuurlijk niet. Een ander voorbeeld is een migratietraject waarbij applicaties omgezet moeten worden van een oude naar een nieuwe omgeving. Niet alle bedrijven hebben voldoende budget om hun hele ontwikkelstraat opnieuw in te richten, dus wordt er dan aandacht besteed om eerst de nieuwe productieomgeving op orde te krijgen. Bovendien lukt het vaak niet om een testomgeving volledig representatief aan productie te krijgen, dus wat is er dan mooier dan de nieuwe productieomgeving te vergelijken met de oude. Een piekdag uit productie volledig simuleren op de nieuwe omgeving, om vervolgens een goede vergelijking te maken. Klinkt als een ideaal scenario, toch? Ook hier geldt weer dat alle data beschikbaar en te gebruiken moet zijn op de nieuwe omgeving. En zo zijn er nog een aantal situaties te bedenken.
De data
Hoe moet zo’n script er nou uitzien? Dat is natuurlijk per situatie en per applicatie afhankelijk. Maar in essentie is het niet anders dan bij iedere andere test, er moet een gebruikershandeling worden gesimuleerd. Daarbij kunnen de volgende vragen worden gesteld:
- Welke actie wordt er uitgevoerd
- Welke informatie is er nodig om de actie uit te voeren
- Hoe lang duurt het voordat de volgende actie wordt uitgevoerd
Een dergelijk input bestand zou dan ook minimaal deze vragen moeten kunnen beantwoorden.
Conclusie
Het staat hier allemaal wat zwart-wit beschreven, waardoor het zo simpel lijkt om te implementeren. Maar het kan erg complexe situaties opleveren. Is deze methode een last of een lust? Daar kan ik geen duidelijk antwoord op geven. Dat moet een ieder namelijk voor zijn eigen organisatie en/of situatie bekijken. Het kan in ieder geval in sommige situaties erg voordelig zijn om eens te kijken naar nieuwe methodes. Innovatie is immers van cruciaal belang voor de continuïteit van organisaties.