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.'
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.