
Zes enorme testblunders
Iedereen maakt fouten, daar is niets aan te doen. Dat geeft niks. Het wordt pas erg als de fout in het eindproduct blijft zitten. De volgende zes voorbeelden tonen aan waarom.

Zes enorme testblunders
Iedereen maakt fouten, daar is niets aan te doen. Dat geeft niks. Het wordt pas erg als de fout in het eindproduct blijft zitten. De volgende zes voorbeelden tonen aan waarom.
Iedereen maakt fouten, daar is niets aan te doen. Of het nu gaat om managers, systeembeheerders, engineers; iedereen laat op een bepaald moment een steekje vallen. Dat is niet erg. Het wordt pas erg als het testproces dat dit soort fouten bloot moet leggen zo onzorgvuldig is dat de fout in het eindproduct blijft zitten. In dat geval kan zelfs het kleinste foutje leiden tot storingen, verbroken verbindingen, en zelfs miljoenenverliezen en faillissementen. Zorgvuldig testen is van het allergrootste belang. De volgende vijf voorbeelden tonen aan waarom.
Probleem: Bug in de assessment-code voor financiële risico's
Gevolg: Investeerders dachten per abuis dat risicokredieten zeer lucratieve investeringen waren.
Moody's is een Amerikaanse kredietbeoordelaar. Uit een rapport dat mei dit jaar werd gepubliceerd in de Financial Times, bleek dat het bedrijf zo'n 4 miljard aan CPDO's (constant proportion debt obligations) per ongeluk een positieve waardering had meegegeven, dankzij een bug in de software. Het bedrijf evalueert een groot aantal obligatieschulden van de overheid en kon door de bug geen nauwkeurige risico-analyse geven van een groot aantal obligaties, waardoor investeerders lange tijd hebben geïnvesteerd in risicovolle obligaties die ze aanzagen voor zeer lucratieve investeringen. Uit internetdocumenten van Moody's blijkt dat het bedrijf in februari van 2007 ontdekte dat er een bug aanwezig was in een aantal computermodellen die werden gebruikt voor het waarderen van CPDO's. Hierdoor werden enkele CPDO's 3,4 niveau's hoger ingedeeld dan de bedoeling was. De waarderingen werden pas dit jaar gecorrigeerd. Dat is een kwalijke zaak, want investeerders vertrouwen blindelings op deze waarderingen. Volgens de Financial Times is het probleem veroorzaakt door een zeer kleine bug in de computercode. Een kleine bug die bij velen heeft gezorgd voor een financiële ramp, die zeker in deze tijd beter vermeden had kunnen worden.
Voorkomen? Wanneer software getest wordt die zo belangrijk is als deze software, is het van groot belang zoveel mogelijk verschillende variaties door de formule te halen en iedere keer te controleren of het resultaat volledig klopt. Daarnaast moet de code van tijd tot tijd extern getest worden op rekenfouten.
Probleem: Koppelfout in een verzekeringsdatabase
Gevolg: 202 duizend brieven naar verkeerde patiënten
Het klonk als een geweldig idee. De grootste zorgverzekeraar in de Amerikaanse staat Georgia (3,1 miljoen aangesloten mensen) besloot patiënten informatie te sturen over wat er precies verzekerd was bij hun ziekenhuisbezoeken. Deze EOB-brieven (explanation of benefits) zouden patiënten met serieuze aandoeningen informatie verschaffen over wat er gedekt is en hoe dat betaald moest worden. Het versturen van de brieven zou gebeuren via een automatisch systeem.
De meeste zorgverzekeraars sturen zo'n brief nadat mensen een medische behandeling hebben ondergaan of wanneer ze naar de dokter zijn geweest. Maar het Cross/Blue Shield-systeem van de verzekeraar had zo'n rommeltje gemaakt van de medische gegevens, dat aangesloten mensen brieven kregen met gevoelige medische informatie over andere patiënten. In totaal kreeg zes procent van alle aangesloten mensen van de zorgverzekeraar een brief over een aandoening die zij helemaal niet hadden, met informatie over andere patiënten, inclusief sofinummers etc. Niet alleen heeft dat behoorlijk wat schrikreacties veroorzaakt, de mensen van wie de persoonlijke informatie is uitgelekt moeten nu waken voor diefstal van hun identiteit.
Voorkomen? Het samenvoegen van databases is een riskante bezigheid. Het is daarom van groot belang een uitgebreide reeks tests los te laten op het systeem, om te controleren of gegevens niet door elkaar gehusseld raken. Het aantal testgegevens moet zo groot zijn dat de belasting van de database minstens zo groot is als in de echte situatie. De gegevens moeten daarbij zo zijn samengesteld dat een fout er direct uitspringt.
Reageer
Preview