De effectiviteit van testen

De meeste mensen denken dat je test om nog wat
foutjes te vinden.  Als dat gebeurd is, ben je
klaar.  Klaar is een relatief begrip: heb je
dan aan je inspanningsverplichting  op het
gebied van testen voldaan, of is het systeemcomplex
klaar voor de praktijk zonder al te veel
problemen?  IT-problemen met nieuwe systemen
worden in de volksmond ook wel kinderziektes
genoemd, verwijzend naar een onschuldige maar
nodige weerstandsverhogende fase waar je nu
eenmaal door heen moet.

Ook weeffoutjes is een populair euphemisme.
Daarmee reageerden twee ziekenhuizen waar 1.2
miljoen gegevens door Karin Spaink gelicht
waren een paar jaar geleden.  En wat blijkt?
Niks onschuldigs:  het Bureau Bescherming
Persoonsgegevens heeft onlangs gerapporteerd
dat er in vier jaar tijd helemaal niets is
verbeterd op dit gebied in de zorgsector.

Testen is er dus niet voor niets.  Er zijn vele
soorten testen, en elk type heeft zijn plaats
en functie.  Een paar om de gedachte te bepalen:
de unit test, de functionele acceptatie test,
de regressie test, de integratie test, de
systeem test, de gebruikers acceptatie test
(voor 1 klant), de low-volume beta test (minder
dan tien klanten), en de high-volume beta test
(meer dan 1000 klanten).  En allemaal zijn ze
nodig om op verschillende momenten in de
voortbrengingsketen fouten te detecteren om
erger te voorkomen.

Een veel gemaakte fout is bijvoorbeeld om een
systeem te accepteren van een leverancier als
het een gebruikers acceptatie test doorstaan
heeft.  De vraag is echter: als die test slaagt,
en als die test helemaal goed is uitgevoerd,
hoeveel fouten zijn er dan gevonden?  Uit
benchmark gegevens blijkt dat je door een GAT
hooguit tussen de 25 en 35 procent van de fouten
zult vinden.  Een GAT is dus niet handig als
acceptatiecriterium.  Vooral niet als er geen
andere tests of preventieve maatregelen zijn
genomen.

Maar het scheelt wel heel veel geld:  grote
in-house informatiesysteem trajecten hebben
als grootste kostenpost het vinden en verbeteren
van fouten.  Dat loopt bij systemen in de orde
van de miljoenen regels code op tot 50% van de
kosten.  Er zijn twee vragen:  waarom is dat
zoveel, en wat is het kwaliteitseffect als je
veel zou testen?

Kosten door fouten lopen zo hoog op omdat er
door de bank genomen geen preventieve maatregelen
genomen worden om ze voor te zijn.  Testen is
niets meer dan een vangnet voor problemen die
eerder zijn ontstaan.  Voorkomen is dus echt
beter dan genezen.  Maar stel nu dat je heel
veel zou testen, levert dat dan wel een foutloos
systeem op?

Een stelregel is dat je gemiddeld bij elke vorm
van testen zo'n 30% van de reeds gemaakte fouten
kunt vinden.  Dat telt niet linear op, want
met verschillende tests vind je natuurlijk ook
een aantal fouten vaker dan eens.  Om 95% van
de fouten te vinden moet je door meer dan tien
teststadia heen.  Bij grote systemen gaat dat
in de papieren lopen.  Dus is het begrijpelijk
dat men bij naderende deadlines of lege
schatkisten het testen overboord gooit.  Het
wordt er uiteraard niet beter op en dat lezen
we elke dag in de krant.

Als je echt kosten wilt besparen is het verstandig
om testen te combineren met reviews.  Sinds
jaar en dag is al bekend in de software
engineering literatuur dat de goedkoopste en
beste methode om fouten te vinden niet testen
is, maar reviewen.  Met een formele ontwerp
review komt 65% van de ontwerpfouten boven, en
elke formele code inspectie levert je 60% van
de bugs.

Een uitzondering is high-volume beta testing,
waarbij meer dan 1000 klanten een nieuw systeem
intensief gaan gebruiken.  Daarmee spoor je 60
tot 85% van de fouten op.  Nu is dat aardig
voor een release van een monopolist of open
source pakket, maar minder toepasselijk voor
Internet bankieren.  Sommige bancaire systemen
krijgen duizenden virusaanvallen per dag te
verduren, dus dat high-volume beta testing mag
juist geen bakken met fouten aan het licht
brengen, die moeten er echt al uit zijn.

Voor systemen die het meteen moeten doen, is
te weinig testen eigenlijk geen optie.  Toch
zie je---uitzonderingen daargelaten---over het
algemeen een vrij lakse houding ten aanzien
van zowel testen als preventie door reviewing.
De gevolgen zijn voorspelbaar.

Een fout in het eisen en wensenpakket kan
dooretteren tot het systeem in productie gaat.
Sterker, je kunt nog tests ontwerpen die de
foute eis testen zodat je zeker weet dat de
fout goed uitgeprogrammeerd is.  Uiterst
effectief is dan ook de review van het eisen
en wensenpakket.  Op elke bladzijde staat
wel een grove fout.  Het kost vrijwel
niets om die fouten te vinden en te verbeteren.

Testen en reviewen samen is een probaat
middel om fouten zoveel mogelijk te vinden
meteen daar waar ze gemaakt worden, en wat
nog overblijft meteen daarna af te vangen.
Op die manier groeien we naar betrouwbare
systemen toe.

X

Meer weten over de wondere wereld van ICT
in Jip en Janneke taal? Ga dan naar de
knipselkrant van Chris Verhoef

Prof. dr Chris Verhoef is hoogleraar informatica
aan de Vrije Universiteit in Amsterdam en
wetenschappelijk adviseur voor overheid en
bedrijfsleven.  Hij schrijft regelmatig een
column in AG II.  Hij is te bereiken via email:
x@cs.vu.nl.  Deze tekst is copyright SDU.  Niets
van deze uitgave mag zonder schriftelijke
toestemming van de uitgever worden overgenomen of
worden gepubliceerd.