![\"\"](\"http:\/\/hans.vanloenhoud.eu\/blog\/wp-content\/uploads\/2012\/10\/Pleuris-2.jpg\" "\\"In")
<\/a>Informatie Management kwam met twee simpele requirements, te weten (1) de responsetijd van alle transacties mag niet meer zijn dan vijf seconden en (2) het systeem mag door de upgrade niet trager worden.\nHiermee ging het test team aan de slag in een \u2013 wat mij betreft \u2013 hele nette opzet van een performance test, met Performance Center als tool. Met een stuk of dertig typen transacties die alleen, in combinatie en met verschillende bedrijfsdrukten moesten worden getest, was dat een hele klus. Maar na een week of twee lagen de resultaten op tafel, en die zagen er heel bevredigend uit: de meeste transacties zaten rond de halve seconden met een paar uitschieters naar een seconde of twee. Iedereen haalde opgelucht adem. Ondanks dat de nieuwe versie heel wat nieuwe functionaliteit en extra overhead meebracht, bleef het project onder de gestelde vijf seconden grens, niet met de hakken over de sloot, maar echt ruim.<\/p>\n
Tot, halverwege de laatste testweek, iemand per ongeluk aan requirement twee dacht en een kleine, vergelijkende performance test losliet op de productieomgeving om te kijken wat daar de\u00a0response nu is. Gek, de response was daar ook rond de halve seconde. Alleen, in productie waren er geen uitschieters naar boven.
\nNou ja, dan was de nieuwe versie op een paar punten wat trager dan de oude, maar, ach,\u00a0dat was wel redelijk, vond het team, want het bleef nog steeds dik beneden die vijf seconden grens. En eigenlijk wel normaal om wat response in te leveren ten gunste van al die extra functionaliteit. Dat moet de business toch begrijpen.<\/p>\n
Nou, dat begrepen ze dus niet. Sterker nog, ze begrepen niet dat het project zo onnozel kon zijn om ook maar \u00e9\u00e9n seconde te denken dat een slechtere performance ooit acceptabel zou kunnen zijn. Ik heb in Nederland nooit meegemaakt dat een projectmanager zo \u2018unverfroren\u2019 (hij is een Duitser) de oren werd gewassen als de grote business baas dat deed in de conference call op die laatste testdag. Immers, juist de uitschieters waren de belangrijkste, meest gebruikte transacties, met iets van dertigduizend per uur. Geen denken aan dat een verslechtering van vierhonderd procent daar door de beugel kan, ook al gaat het maar om anderhalve seconde. Verzin maar iets, want dit kan echt niet!!!!
\nEn dat \u00e9\u00e9n week voor de geplande Go Live\u2026 Tot aan deze call dacht het hele project dat ze klaar waren. Dat ze eindelijk eens op tijd, binnen budget een project netjes hadden opgeleverd. Geen serieuze defects, alles opgelost en afgesloten.<\/p>\n
Niet dus. De soap gaat gewoon door. Gisterenavond is besloten om de go live een week uit te stellen. En vandaag hebben ze weer tien milliseconden gewonnen. Nog honderdnegentig te gaan\u2026<\/p>\n","protected":false},"excerpt":{"rendered":" … is uitgebroken in mijn project. Nou ja, mijn project, het project waar ik de afgelopen weken het meest mee te maken heb gehad, waarvan ik de testaanpak heb geaudit en waar ik goede maatjes met de test manager ben … Lees verder <\/a>Niet dus. Wat volgde was een weekend en een nieuwe week van overwerken, brainstormen, improviseren, software aanpassingen, hardware upgrades, invliegende topconsultants van de leverancier en veel stress, stress, stress. En testen, testen, testen, iedere keer dat er weer iets nieuws werd bedacht. Na een week was het verschil terug gebracht van anderhalf naar tweetiende seconde. Tweetiende seconde verschil op een backend transactie die onderdeel is van een keten van applicaties, die end-to-end vaak meer dan tien seconden kost, inclusief de lijnvertraging. Dat zal toch geen enkele klant merken.
\nDat was toch redelijk? Dat kon de business toch wel begrijpen? Alle alternatieven waren uitgeprobeerd en niemand had nog enig idee hoe ze de performance verder omhoog zouden kunnen brengen. Dus geen keus, eigenlijk.<\/p>\n