Managed hosting door True

Testen had ICT-fout Liander kunnen voorkomen

Energienetbeheerder Liander had 2,8 miljoen euro niet hoeven terugbetalen aan zijn klanten als het conversietraject gestructureerd was getest. Dat zeggen Computable-experts. 'Conversies en migraties worden vaak bestempeld als technische aanpassingen. Programmeurs en projectleiders trekken al snel de conclusie dat functioneel testen niet nodig is. Dat is een illusie', zegt manager teststraat André Weber van Capgemini BAS. Bij de overgang naar een nieuw softwaresysteem bij de energienetbeheerder werd een fout model ingevoerd, waardoor klanten zeven jaar lang voor een te dure meter betaalden.

Het is verstandig dat bij een conversie wordt gecontroleerd of de gegevens in systeem a overeenkomen met de data in systeem b, zegt Wilcor Toele, managing partner test consultancy van Active Professionals. Dat kan met een regressietest. Dat hoeft geen moeilijke of dure test te zijn, zegt it-architect Wouter Geurts van Logica. 'In principe is het risico van foutieve berekeningen te ondervangen door het oude systeem (een deel van) de rekening te laten produceren en de (be)rekeningen van het nieuwe systeem hiermee te laten vergelijken.'

Het houden van overzicht, wordt door de experts als een belangrijke voorwaarde gezien bij een ontwikkeltraject. 'Bij migratietraject misschien wel nog belangrijker aangezien het veelal om grote, werkende systemen gaat', zegt senior testmanager Ewald Roodenrijs van Sogeti. 'Gezien het feit dat er door een ontwikkelaar een verkeerd model is gebruikt, vraag ik me af of het overzicht tijdens de migratie goed is behouden.' Het inschakelen van een testmanager is, volgens Roodenrijs, een manier om overzicht te bewaren.  Ook senior testconsultant Johan Vink van Sogeti adviseert testen en toetsen van een derde partij. 'Ieder mens maakt fouten en is meer of mindere mate blind voor de fouten die hij maakt.'

Kiezen tussen kwaliteit en tijd

Toch is het niet zo raar dat de energienetbeheerder waarschijnlijk niet uitgebreid getest heeft, zegt Partner Agile Testen Anko Tijman van Ordina. 'Ik denk niet dat er zeven jaar geleden al ict-afdelingen bij energiebedrijven waren die gestructureerd testen hadden geïmplementeerd of daartoe in staat waren geweest.' Bovendien moeten bedrijven altijd afweging maken tussen de tijd van een softwareproject of de kwaliteit van de software. 'Opdrachtgevers nemen vaak (on)bewust grote risico's met betrekking tot kwaliteit van de software als daarmee de producten binnen de beschikbare tijd en geld worden opgeleverd', zegt Vink.  Ict-consultant Christian Hoppenbrouwers van EclipseIT vindt dat aan het testproces bij Liander relatief veel tijd besteed had moeten worden. 'Het facturatieproces lijkt me een van de core-processen bij Liander.'

Zelfs testen is geen garantie voor het vinden van alle fouten in software", zegt Principal Technology Officer Sander Hoogendoorn van Capgemini. 'Ook testen is mensenwerk, net als conversies uitvoeren trouwens.' Maar het is wel raar dat de fout zeven jaar later gevonden werd, zegt Roodenrijs. 'Na een migratie is het aan te raden tellingen uit te voeren op, in dit geval, bijvoorbeeld het aantal meters en de verdeling van deze. De verdeling en aantal zouden in het systeem hetzelfde moeten zijn als voor de migratie.' 'Blijkbaar voert Liander geen standaard controle tellingen uit die resultaten vergelijkt en is in productie ook niet regelmatig geëvalueerd of de resultaten conform verwachtingen waren', zegt Vink.

Reactie Liander

Liander zegt in een reactie dat de migratie wel getest is. Er is op verschillende manier getest, maar uitgebreid testen biedt geen honderd procent zekerheid, zegt het bedrijf. 'Datamigratie van het ene naar het andere klantsysteem is een uitermate belangrijk proces, dat wij ingrijpend hebben getest. Het blijft ongelukkig, voor de klant is het vooral vervelend als er toch iets niet blijkt te kloppen.'

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/3029912). © Jaarbeurs IT Media.
?

 

Reacties

Liander had 2,8 miljoen kunnen besparen... dat klopt natuurlijk niet.

Als ze mensen niet teveel hadden laten betalen, dan hadden ze dat extra geld wat ze nu terug moeten betalen helemaal niet ge�ncasseerd. Dus dan zouden ze die 2,8 miljoen nu ook niet in hun portemonnee gehad hebben.

Het is dus niet zo dat ze 2,8 miljoen euro kwijt zijn, ten opzichte van de situatie dat de fout er niet zou zijn geweest.

Ach, ze hebben er 5 jaar over gedaan om de fout te vinden.. En meteen maar een vacature geopend:

http://banen.computable.nl/careers/jobsearch/detail?jobId=18368832&viewType=main&networkView=main

Als de tester deze fout al gevonden had. Want natuurlijk is die software getest. Testen bestond 20 jaar geleden ook al. Deze fout was in hun voordeel te weinig berekenen en dat terughalen lijkt me moeilijker. Dan teveel terugbetalen.

Edsger W. Dijkstra zei al:

"Het testen van programma's kan een zeer effectieve manier zijn om de aanwezigheid van fouten aan te tonen, het is echter een hopeloos inadequate manier om de afwezigheid van fouten aan te tonen."

DIt heeft niet zoveel met testen te maken en des te meer met een zorgvuldige manier van werken tijdens een conversie. Met een simpele controletelling en vergelijking oud versus nieuw was dit hoogst waarschijnlijk ook gevonden.
Als de programmeur van een verkeerd model uit is gegaan bij de conversie is de kans groot dat de tester dat ook heeft gedaan.

Testen is belangrijk, maar we moeten het nu ook weer niet als tot "tovermiddel" verheffen.

Jelle Calsbeek
Testconsultant

Een simpele regressietest gemaakt door een professionele tester had deze fout aan het licht kunnen brengen. Wat dat betreft ben ik het eens met de meningen van de heren in het artikel.

De schade bedraagt natuurlijk geen 2,8 miljoen. Zoals Jasper al aangaf. De schade is moeilijk in te schatten, maar dat er sporake is van reputatieschade is duidelijk. Het feit dat ze nu op Computable.nl staan kost wellicht klanten. Geen idee of ze ook in de dagbladen gestaan hebben, maar als dat het geval was, had het zeker klanten gekost!

Het enige waar ik het niet mee eens ben, is dat een testmanager voor beter overzicht zorgt... Bovendien vraag ik me of dat in dit geval geholpen had. Maar misschien begrijp ik Ewald niet helemaal?!

Wat Wouter al aangaf in het artikel: een eenvoudige regressietest waarin de facturen oud en nieuw vergeleken worden, had de fout gevonden!

@Huib Schoots: volgens mij kun je als consument wel je energieleverancier kiezen, maar niet je netbeheerder. Dat wordt nog steeds bepaald door je woonplaats. Van klanten verliezen kan dus geen sprake zijn en de imagoschade zal dus ook wel meevallen. Feit is wel dat Liander 7 jaar lang te hoge bedragen hebben ge?nd. Het deel dat niet terug betaald wordt, is winst samen met de rente die het bedrag de afgelopen 7 jaar heeft opgebracht. Deze fout heeft het bedrijf dus geld opgebracht!

Dit zegt niet alleen wat over het migratietraject. Ook de controller en de accountant hadden op basis van controletotalen kunnen constateren dat er te veel werd gefactureerd. Wanneer namelijk minder stroom (Q) binnenkomt dan dat er uitgaat ((PxQ)/P = Q), zouden alle bellen moeten gaan rinkelen.

Blijkbaar is het model voor de berekening van stroomverlies niet zo nauwkeurig dat het teveel (een jaarlijks bedrag van 500.000) of de trendbreuk opvalt.

En laten we wel wezen, als 500.000 al materieel zou zijn, dan zouden we geen energiecrisis hebben.

@Robert: ik heb geen idee waar je het over hebt. Er is m.i. een te hoge meterhuur berekend en niet een te hoog stroomverbruik. Wel even bij de les blijven.

Meterhuur betalen gaat na volledige afschrijving gewoon door he. Maw. in de meeste gebouwen wordt huur geheven voor oude apparatuur dat allang niet meer in de financiele boekhouding terug te vinden is als active. Hoe doen ze dat?

Ach.....achteraf is dit makkelijk concluderen natuurlijk

Er zal ongetwijfeld wel getest zijn; ik heb in de negentiger jaren enkele mainframe migraties gedaan, en toen was het fenomeen testen echt al wel bekend.

Alleen....wat test je, en in hoeverre kun je vertrouwen op wat anderen roepen ???

In het verleden waren we volgens mij veel meer geneigd de "expert" te geloven als die riep dat er niet getest hoefde te worden. Ook werd het geloofd als iemand riep dat er getest was; bewijs werd niet gevraagd.

Voorbeeld: klant zegt bij de test-migratie dat alles werkt. Bij de echte migratie toch talloze problemen. Wat blijkt: de klant had alleen gekeken of hij verbinding kreeg met het mainframe. Niet geprobeerd in te loggen, niet geprobeerd een programma te starten enz.
De migraties daarna zorgde ik er altijd voor dat ikzelf, of een collega, ter plekke was om mee te testen.

En dat geeft meteen aan wat in mijn ogen het verschil is met 7 jaar geleden: we testen nog steeds, maar zowel de kwaliteit van het testen is sterk verbeterd, als ook het vastleggen van testbewijs.

Maar wat er mis is gegaan bij Liander?....daarvoor moeten we denk ik toch echt de testers van weleer zien te vinden

Als je weet uit wat voor troep er destijds in eerste instantie moest worden geconverteerd is het resultaat nog niet zo gek, het draait uiteindelijk om een paar euro per aansluiting!

Een beetje vage titel: "Testen had ICT-fout Liander kunnen voorkomen". Met testen voorkom je geen fouten. Je toont ze hooguit aan. In het gehele artikel is niet terug te lezen of er voor het moment van implementeren uberhaupt aangetoond is dat er een fout bestond. Ik kan mij ook vinden in de opmerkingen van Anko en Johan. Stel dat de fout wel gevonden is, dan kan een opdrachtgever (en niemand anders!) alsnog beslissen om door te gaan met implementatie.

@Huib: Reputatieschade. Hoezo? Ze corrigeren een fout die op een eerder moment gemaakt is, waarbij de klant nu financieel gecompenseerd wordt. Dat zou zelfs goed kunnen uitpakken voor hun reputatie. Een fout maken is menselijk. Een fout toegeven is niet per definitie slecht voor de reputatie. Het helpt overigens vaak wel mee wie er baat bij de foutcorrectie heeft. Ga maar na...als de Belastingdienst een fout maakt ten nadelen van de burger, staat iedereen op zijn achterste poten.

Datamigraties, met daarin conversies worden nog weleens vergeten of onderschat. "Ach, dat pakken we tussendoor wel even mee" of "dat doen we wel met een scriptje". (Soms) kleine acties die mogelijk grote gevolgen kunnen hebben. Ook conversie- en migratiesoftware is functionaliteit! En maar al te vaak risicovolle functionaliteit. Juist omdat er grote hoeveelheden data doorheen gaan. Het kan dus geen kwaad om in een teststrategiebepaling standaard na te gaan of er sprake is van datamigraties en/of dataconversies.

Lees meer over:
Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×