Bij vrijwel ieder bedrijf, soms zelfs per project, werkt het weer anders: het opstellen van het rapport naar aanleiding van performance-test-resultaten. ‘Hier’ kijkt men slechts naar een uitdraai van cijfertjes en vinkjes en ‘daar’ is er enkele dagen radiostilte, waarin er diepgaande analyse wordt uitgevoerd. Uiteindelijk wordt die radiostilte dan verbroken met de oplevering van een uitgebreid testrapport, met soms onbegrijpelijke inhoud voor hen die de resultaten uiteindelijk moeten beoordelen. Waarom dat verschil? En bestaat er een “Best Practice”?
Test-doorlooptijd
“Ze willen direct het rapport opgeleverd zien, maar er is tijd nodig voor een grondige analyse.”
Men moet die test-fase door en vergeet nog wel eens wat er nodig is vooraf aan het testen. Men verwacht ook na de testen direct de resultaten te kunnen zien, akkoord te krijgen en door te kunnen naar productie. De performance-test is het laatste station voor de eindbestemming. We zijn er bijna!
Men was er eigenlijk al vanuit gegaan dat de oude test-scripts zonder meer herbruikbaar waren en er dus direct getest kon worden… De tijd die na het testen nog eens nodig is voor analyse was ook over het hoofd gezien en wordt dus ervaren als een vervelende, extra vertraging. Bij onvoldoende monitoring kan het zelfs voorkomen dat er eindeloos wordt doorgetest om met een verklaring te kunnen komen voor waargenomen “vreemd gedrag”. Ook bij ogenschijnlijk goed gedrag kunnen er twijfels blijven bestaan, of worden vaste punten van aandacht stuk voor stuk nagelopen. Ieder punt nagezocht in een eigen tool of intranet-pagina; monitoring is lang niet altijd even toegankelijk en dat neemt tijd in beslag.
Belangenkwestie
“Het product werkt toch goed, dus waarom kost het zoveel tijd? Zoek je soms naar problemen?”
Dergelijke vragen komen vaak naar voren in een organisatiestructuur waarbij het ontwikkelteam voornamelijk belang heeft bij de doorlooptijd van het project: ze moeten iets opleveren. Alle issues die vervolgens in productie naar voren komen zijn voor het budget van onderhoud en niet meer voor het project. Het is dan aan de performance-consultant om het belang van performance te verdedigen en dat zal hij/zij moeten doen op basis van vastgestelde risico’s en de daarop gebaseerde eisen, requirements, waar het product aan moet voldoen.
Echter doordat deze belangen eerder niet meespeelden is er vaak bij de voorbereiding al te weinig aandacht geweest voor meestal toch al vrij onzichtbare non-functional (waaronder performance) -issues. Ook wordt de performance-consultant vaak pas tegen het einde van het project betrokken. Hierdoor kan het zelfs zo zijn dat er pas op dat (late) moment een discussie ontstaat over de requirements waar het product werkelijk aan moet voldoen, of, wanneer het product de requirements niet blijkt te halen, in plaats van de performance van het product, de requirements ter discussie worden gesteld. En dan moeten wachten op een grondige analyse, waaruit vervolgens alsnog onverwachte performance-issues kunnen opduiken die voor (nog verdere) vertraging zorgen, maakt zo’n ontwikkelteam zenuwachtig waarbij frustraties kunnen oplopen.
DevOps
Onder andere om dit belangenconflict te doorbreken zie je nu ook veel bedrijven toewerken naar een DevOps-opstelling: een combinatie tussen development en operations, wat tevens vanuit de Agile-beweging voortkomt die meer en meer zichtbaar wordt binnen bedrijven.
Door het ontwikkelteam ook direct verantwoordelijk te stellen voor (performance-)issues in productie, worden ook de minder zichtbare issues belangrijker om opgelost te hebben, voordat er iets in productie gezet wordt. De kosten om ze op te lossen gaan immers van hetzelfde budget en de last om ze op te lossen, rust op dezelfde schouders; de tijd van hetzelfde team wordt erdoor verstoord. Hierdoor ontstaat er meer begrip tussen het ontwikkelteam en het testteam, voor zover dit onderscheid dan nog bestaat en de testers nog geen deel uitmaken van hetzelfde team.
Een goede voorbereiding zorgt voor een goede en snelle afhandeling
Rapporteren op basis van vooraf opgestelde requirements blijft het meest efficiënt om zekerheid te stellen dat de risico’s afgedekt zijn. Hoe beter de requirements zijn opgesteld (SMART), hoe eerder vooraf vastgesteld kan worden of de nodige monitoring op z’n plaats is en hoe sneller de performancetestconsultant kan vaststellen of het product aan die requirements voldoet. Zo kan dus snel een (bondig) rapport opgeleverd worden, die begrijpelijk is en voldoet aan verwachtingen. Nog mooier zou het natuurlijk zijn om op één (maatwerk) dashboard de beoordeling van al je aandachtspunten (SLA’s), zoals bijvoorbeeld op responstijden en resourceverbruik, bij elkaar te kunnen vinden.
Ik vermoed dat Performr wellicht ook uitermate geschikt is als maatwerk dashboard bij performance-testen?
