Testen is meer dan proberen

Stel ik doe het licht aan en uit. Heb ik dan
het lichtknopje getest?  Neen, dan heb je
geprobeerd of het lichtknopje, de
stroomdraden en de lamp zijn aangesloten
zodat als ik het aan en uit doe, dat het
licht ook aan en uit gaat.  Voor een test
heb ik in ieder geval een doel nodig
(functies, eigenschappen en
randvoorwaarden).  Lichtgeven, duurzaamheid
van de schakelaar of de lamp,
brandveiligheid van de gebruikte materialen
in verband met inductievonken, en zo
verder.

Naast dat doel moet ik ook een test
strategie hebben.  En ik moet zaken in de
steigers zetten zodat ik de test kan
uitvoeren, en de resultaten kan analyseren.
Bijvoorbeeld de duurzaamheid vergt een
opstelling waar een automaat in korte tijd
75000 keer de knop omzet.  We gaan er even
van uit dat je maximaal tien keer per dag
het licht aan en uit schakelt, wat dus 3650
keer per jaar is, en dat moet toch wel
twintig jaar mee, dus afgerond 75000 keer
moet het ding zeker meegaan.

Als je niet de lamp maar het systeem wilt
testen dan vervang je de lamp door een
meetinstrument---een veld-simulator---dat
precies dezelfde karakeristieken heeft van
een lamp, uiteraard geijkt, maar die ook
gekoppeld is aan de automaat zodat
bijgehouden kan worden of bij aanzetten door
de automaat, het licht ook daadwerkelijk
aangaat en omgekeerd.

Dat zet je dan aan, en je herhaalt dat 50
keer met 50 verschillende schakelaars van
een bepaald type.  Vervolgens kun je de
resultaten statistisch verwerken en zo tot
een uitspraak komen over de levensduur van
dit type lichtschakelaar.  Uiteraard moet je
bijhouden wat er gebeurd goed en fout gaat.

Je ziet dus dat er een wereld van verschil
zit tussen het licht een keer aan en uit
doen, en bijvoorbeeld zo'n
duurzaamheidstest.  Zo kun je ook een
stresstest uitvoeren, bijvoorbeeld door een
te hoog voltage op de schakelaar te zetten,
of juist fysiek te ruw met de schakelaar
omgaan.  Dit om te bezien hoe de schakelaar
tegen allerlei vormen van overbelasting, dus
stress, bestand is.

Door alle testen kan de leverancier ook een
bepaalde garantie afgeven, en deze weet dan
ook dat de wet van de grote aantallen
werkt:  er kan altijd iets misgaan, maar het
merendeel van de producten zit binnen de
marge, zodat de garantie een vangnet is voor
een paar blindgangers.

Op die manier worden vrijwel alle producten
om ons heen op allerlei manieren uitputtend
getest.  Op de stekker van mijn broodrooster
staan al zo'n tien aanduidingen, waaronder
de bekende Kema Keur.  Op mijn
lashandschoenen staan de EN 12477, de EN
407, en de EN 388.  Drie normen maar liefst
op een paar lashandschoenen.

Heeft u ooit dergelijke aanduidingen gezien
op uw software?  Ik wel, hier een
voorbeeld:  'The software media is
distributed on an "As IS" basis, without
warranty.  Neither the authors, the software
developers, nor the publisher make any
representation, or warranty, either
expressed or implied, with respect to the
software programs, their quality, accuracy,
or fitness for a specific purpose.'  Deze
ISO-norm kende u vast nog niet maar hij is
behoorlijk standaard.  Vooral dat laatste
stukje: geen garantie dat het een specifiek
doel dient.

Waarom zo'n verregaande antigarantie?  Omdat
de software niet formeel geverifieerd is?
Omdat je niet met wiskundige precisie kunt
garanderen dat alles altijd goed gaat?  Dat
kan ook niet bij een lashandschoen of
broodrooster.  Dus daar kan het niet aan
liggen.  Het ligt vaak aan een groot gemis
aan audits, reviews, en tests.  Als je het
ontwerp van je broodrooster niet reviewed,
het voortbrengingsproces niet audit, en het
product niet test, is garantie een
verlieslatende business case.  Zover komt
het echter niet: er zijn allerlei
veiligheidsbepalingen voorgeschreven en als
je niet door de keuringsinstituten heen komt
mag je je producten niet eens verkopen.

Een van de nieuwe risico's van besturen is
dat je verantwoordelijk bent voor een
omvangrijke investering waarin software de
achileshiel is, en dat merk je pas als het
te laat is.  Je wordt geacht een integrale
systeemprestatie te leveren met de
resultaten van die investering maar dat lukt
niet wegens een uit de rails gelopen
softwarepoot.

Let maar eens op, bij vele van dit soort
investeringen blijkt de oplevering van naar
behoren werkende software de
inbedrijfsstelling van het totaal dominant
te bepalen.  De lancering van een nieuw
model auto, de ingebruikname van de hoge
snelheidslijn, de overgang van strippenkaart
naar OV-chipkaart, de volledige opensteling
van de A73-tunnels, de betrouwbaarheid van
de Maeslantkering, de invoering van allerlei
wet- en regelgeving, de totstandkoming van
het Electronisch Patienten Dossier, en dito
Medicatie en Kind Dossiers.  En dit zijn er
nog maar een paar.

Zolang de engineers ad hoc blijven proberen
in plaats van systematisch en rigoreus te
testen, niet echt reviewen en auditen, en
zolang de bestuurders dat toestaan veranderd
er niets.  Zonder adequate IT-regie te
voeren; zonder te eisen dat er
daadwerkelijke reviews, audits, en tests
uitgevoerd worden; zonder af te dwingen dat
naar audit-, review-, en testbevindingen
geleefd wordt; zonder de geconstateerde
problemen aan te pakken, en waar nodig aan
de noodrem te trekken; ja zonder die
ruggegraat zal de lijst alleen maar
toenemen.  Op die manier kun je niet eens
het software-equivalent van een eenvoudig
lichtknopje binnen redelijke tijd en kosten
en met de gewenste functionaliteit leveren.

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.