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

Probleem: Bugs in een update van de website

Gevolg: Grote financiële verliezen en ontevredenheid bij klanten

Kledingconcern J. Crew had een website die voorzien moest worden van een upgrade. Op 28 juni van dit jaar werd de website van het bedrijf 24 uur offline gehaald om de upgrade uit te kunnen voeren. Het was het begin van een wekenlange periode van problemen met de website die veel klanten voorgoed heeft weggejaagd. Veel klanten waren simpelweg niet meer in staat te bestellen, maar klanten die dat wel voor elkaar kregen, stonden voor een verrassing toen het pakketje in de bus viel. Een man die een paar poloshirts had besteld, ontving drie kindershirts en een rekening van 45 dollar plus 9200 dollar verzendkosten.

Als gevolg van de fout moest het bedrijf dure email-marketingcampagnes afzeggen en liep het aantal klanten drastisch terug. Er moesten kortingen gegeven worden, geld moest worden teruggestort en er werden duizenden excuses verstuurd aan klanten die de verkeerde spullen kregen. De gevolgen voor het bedrijf zijn aanzienlijk. De storing heeft gevolgen gehad voor de financiële resultaten van het tweede én derde kwartaal van dit jaar.

Voorkomen? Als het succes van uw bedrijf afhankelijk is van uw website, dan moet de functionaliteit van de site koste wat kost zo uitvoerig mogelijk worden getest voordat deze live wordt gezet. Breng het hele team naar kantoor, bestel een stapel pizza's en laat iedereen overal, maar dan ook echt overal op klikken. En zorg vooral voor een backup van de oude site, voor als het alsnog helemaal mis gaat.

Probleem: Anoniem toegang tot overheidsdatabase toegestaan

Gevolg: Gegevens van gevangenen en bewakers op straat

Een fout in de database van een website zorgde ervoor dat iedereen die de website van the Department of Corrections in Oklahoma bezocht, toegang kreeg tot de volledige database die behoort tot de Sexual and Violent Offender Registry (het systeem waarin geweldplegers en plegers van zedendelicten worden geregistreerd). En dat was niet eens het grootste probleem. Iedereen met een beetje SQL-kennis kon nieuwe waarden toevoegen aan het systeem, waarmee in potentie de levens van onschuldige mensen verwoest zouden kunnen worden.

Het meest genante aan dit verhaal is nog wel dat journalist Alex Papadimoulis van dailywtf.com melding had gedaan van het probleem, waarna het probleem werd verholpen… door SQL-queries gevoelig te maken voor hoofdletters. Oftwel, er konden nog steeds waarden worden toegevoegd, alleen moest nu precies de juiste opmaak worden gebruikt.

Voorkomen? Wanneer je een interface bouwt voor een database met gevoelige informatie van honderden of zelfs duizenden mensen, moet je niet bezuinigen op je personeel. Het bouwen van beveiliging in een website moet altijd worden gedaan door ervaren programmeurs. Dat was hier niet het geval. Goede mensen kosten meer geld, maar de problemen die kunnen ontstaan als je hierop gaat besparen, kosten veel meer.

Probleem: Contactgegevens blootgelegd tijdens databasemigratie

Gevolg: Gegevens over maîtresses verzonden naar echtgenotes van klanten

Vreemdgaan is al riskant genoeg en de kans op ontmaskering is groot. Het helpt natuurlijk niet als de bank ook nog eens roet in het eten gooit. Dat is precies wat er gebeurde toen een aantal belangrijke klanten van een bank ontdekte dat de bank afschriften verstuurde naar hun huisadres, met daarop alle details van transacties en handelingen. Normaliter zou dat geen probleem zijn, ware het niet dat de bank in kwestie zich gespecialiseerd had in het wegsluizen van geld om bepaalde zaken aan de aandacht van echtgenoten of echtgenotes te onttrekken. Klanten van de bank kregen normala gesproken een aangepast afschrift thuis, en het volledige afschrift op een ander adres.

Het bedrijf voerde een upgrade uit van de portal voor zijn klanten, waarbij er iets mis ging met de migratie van de database. Het thuisadres van de klanten werd gebruikt voor het verzenden van de volledige afschriften. Afschriften waarop hotelrekeningen stonden, dure sieraden en riante etentjes. De bank verloor een groot aantal klanten ter waarde van in totaal 450 miljoen dollar.

Voorkomen? Het probleem werd naar alle waarschijnlijkheid veroorzaakt door een techneut die de aard van het bedrijf niet helemaal begreep. Het is van groot belang technici te laten weten wat precies de aard is van het systeem waar ze aan werken, zodat dit soort fouten voorkomen kunnen worden.

Probleem: Tekst uit de testronde blijft in het eindproduct staan

Gevolg: Belangrijke klanten 'not amused'

Het verhaal gaat dat Computer Weekly in 1993 (reeds) een verhaal publiceerde over een niet nader te noemen financiële instelling die 2000 van zijn meest vermogende klanten een brief stuurde om ze uit te nodigen gebruik te maken van bepaalde extra services. Een van de testers zou tijdens het testen de fictieve voornaam ‘Rich’ en de evenzo fictieve achternaam ‘Bastard’ hebben ingevoerd – en die naam bleef prompt staan in de uiteindelijke mailing ('Dear Rich Bastard'). Helaas is dit verhaal niet meer te verifiëren. Maar dat je moet oppassen met dat soort grappen, is wel duidelijk.

Een zijn meer dan genoeg andere leuke voorbeelden die wel te controleren zijn. Op afschriften die beleggers in 1988 van de Wells Fargo-bank ontvingen, stond bijvoorbeeld de volgende ‘reclame-slogan’: “You owe your soul to the company store. Why not owe your home to Wells Fargo? An equity advantage loan can help you spend what would have been your children’s inheritance”. Dat je als tester in zo’n geval beter niet meer op je werk kunt verschijnen, leidt geen twijfel, maar de schade die zo’n grap aanricht bij een bedrijf is vele malen groter.

Voorkomen? Bij Wells Fargo geldt sindsdien een simpele regel: als er test-tekst gebruikt moet worden, dan is dat ‘Test, één, twee, drie’ – en niets anders. Testen is geen grap. Bereid je voor op Murphy’s law.