Testen is te veel werk voor middelgrote organisaties
Zij realiseren zich onvoldoende dat zij niet of nauwelijks meer in staat zijn om de kwaliteit van dat informatiesysteem te beheersen omdat het testen daarvan een te tijdrovende en te gespecialiseerde klus is geworden.
De complexiteit van het informatiesysteem begint ermee dat er gewoonlijk meerdere softwarepakketten noodzakelijk zijn die onderling moeten worden gekoppeld. Vervolgens wordt dit geheel aan de buitenwereld gekoppeld – ziekenhuizen met huisartsen en apothekers en binnenkort ook met het landelijk schakelpunt. In deze constellatie wurmen de informatiestromen zich door een spinnenweb van systemen en koppelingen, even onoverzichtelijk als een oosterse kashba van huisjes, slopjes en steegjes, waarin toeristen al snel verdwalen.
Omdat organisaties afhankelijk zijn van hun ICT-oplossingen, is het geen overbodige luxe om bij iedere release opnieuw aan te tonen dat het geheel werkt. Dit onder de specifieke omstandigheden waaronder het informatiesysteem wordt gebruikt, inclusief de koppelingen, niet volgens een laboratoriumsituatie bij de softwarefabrikant voor alleen zijn eigen pakket. Erkende normen voor informatiebeveiliging zoals de Code voor Informatiebeveiliging of de daarvan afgeleide norm voor informatiebeveiliging in de zorg (NEN7510) stellen aan dit werk duidelijke eisen.
Eisen
Om met een eenvoudige eis te beginnen, die door de norm voor informatiebeveiliging in de zorg (NEN7511-1) wordt genoemd: als testgegevens worden afgeleid uit productiegegevens, dan moeten deze geanonimiseerd worden, een eis die rechtstreeks afkomstig is uit onder andere de Wet bescherming persoonsgegevens. Terecht, helemaal voor een instelling voor geestelijke gezondheidszorg maar ook voor ogenschijnlijk simpele financiële administraties van woningcorporaties. Ook bij de laatste gaan namelijk vertrouwelijke gegevens rond zoals informatie over sociale klachten, betalingsachterstanden en inkomensgegevens. Te vaak is echter de relatief eenvoudige software die nodig is voor het anonimiseren van productiegegevens, al te hoog gegrepen. De kerneisen van goed testen zijn beschikbaarheid van acceptatiecriteria die uitgewerkt zijn in testscenario’s met specifieke testsets, goedkeuringsprocedures voor wijzigingen en een testomgeving die gescheiden is van de productieomgeving. Tal van middelgrote organisaties hebben deze eisen maar gedeeltelijk ingevuld. Niet een kwestie van onwil maar veelal van onvermogen want het vele werk is nauwelijks betaalbaar.
Zo ontstaan er risico’s en ongelukken, zoals: correspondentie versturen naar overleden patiënten of huurders, medische gegevens kwijt zijn, maandenlang niet kunnen factureren et cetera. De risico’s worden verder vergroot als gecompliceerde regelingen onder hoge tijdsdruk worden ingevoerd waardoor het testen verder onder druk komt te staan. Zo werden in de gezondheidszorg in hoog tempo de administratief gecompliceerde Diagnose Behandel Combinaties (DBC’s) ingevoerd en is het denkbaar dat er bij tal van instellingen berekeningsfouten worden gemaakt die niet worden opgemerkt. Dat heeft zich al eerder voorgedaan, zelfs bij banken die veel meer geld kunnen besteden aan ICT dan middelgrote organisaties. Volgens een bericht in de Volkskrant ontdekte de ING bank in 2005 dat jarenlang te veel provisie was berekend en 70 miljoen euro moest worden terugbetaald aan klanten.
Checklist
Men kan met een simpele checklist (zie kader) zelf nagaan of in de eigen organisatie de basisvoorwaarden voor goed testen zijn ingevuld. Als dat niet het geval is, wordt er kennelijk op vertrouwd dat de softwareleverancier zijn eigen software afdoende test voordat deze wordt uitgeleverd. In deze verwachting zal men niet alleen geregeld teleurgesteld worden, zij is ook niet realistisch. Iedere organisatie heeft haar eigen verantwoordelijkheid om bedrijfskritische software te controleren alvorens die in productie te nemen en dat geldt a fortiori voor de vele onderlinge koppelingen tussen verschillende softwarepakketten.
Veel softwareleveranciers wijzen daar ook op door in hun algemene voorwaarden te vermelden dat de klant een release automatisch accepteert wanneer hij de software in productie neemt. Voor middelgrote organisaties is het echter lastig om die verantwoordelijkheid te dragen, niet alleen vanwege de kosten maar soms ook door extern opgelegde deadlines, denk aan aanpassing in de wetgeving, nieuw beleid vanuit de overheid of Europese richtlijnen et cetera.
Als men zich realiseert dat de klanten van eenzelfde softwarefabrikant op hetzelfde moment dezelfde testinspanning leveren, is er ook een oplossing voor het geschetste probleem (zie kader). Door deze inspanningen samen te voegen en onder professionele regie te plaatsen, worden de testaanpak en kwaliteit van de software verbeterd voor een acceptabele prijs. Deze aanpak is in feite een professionaliseringsslag die nauwe samenwerking vereist tussen softwaregebruikers en -leveranciers.