Column: Testen is meer dan proberen
Chris Verhoef
Stel ik doe het licht aan en uit. Heb ik dan het lichtknopje getest? Nee, dan heb ik geprobeerd of het lichtknopje de stroomdraden en de lamp zijn aangesloten zodat – als ik het aan- en uitdoe – het licht aan- en uitgaat. Voor een test heb ik 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 teststrategie hebben. En ik moet zaken in de steigers zetten zodat ik de test kan uitvoeren, en de resultaten kan analyseren.
Als je niet de lamp maar het systeem wilt testen, dan vervang je de lamp door een meetinstrument – een veldsimulator – dat precies dezelfde karakteristieken 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 vijftig keer met vijftig verschillende schakelaars van een bepaald type. De resultaten kun je statistisch verwerken en zo kun je tot een uitspraak komen over de levensduur van dit type lichtschakelaar. Uiteraard moet je bijhouden bij wat er gebeurt goed en fout gaat.
Je ziet dus dat er een wereld van verschil zit tussen het licht een keer aan- en uitdoen, 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 om te gaan. 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: het merendeel van de producten zit binnen de marge, de garantie is een vangnet voor een paar blindgangers. Op die manier worden vrijwel alle producten op allerlei manieren uitputtend getest. Op de stekker van mijn broodrooster staan al zo’n tien aanduidingen.
Hebt u ooit dergelijke aanduidingen gezien op uw software? Ik wel: ‘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 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 reviewt, het voortbrengingsproces niet audit, en het product niet test, is garantie een verlieslatende businesscase. Zover komt het echter niet: Er zijn allerlei veiligheidsbepalingen voorgeschreven en als je niet door de keuringsinstituten heenkomt, 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 achilleshiel is, en dat merk je pas als het te laat is. Je wordt geacht een integrale prestatie 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 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 hogesnelheidslijn, de overgang van strippenkaart naar OV-chipkaart, de betrouwbaarheid van de Maeslantkering. En dit zijn er nog maar een paar. Zolang de engineers ad hoc blijven proberen in plaats van systematisch en rigoureus te testen, niet echt reviewen en auditen, en zolang de bestuurders dat toestaan, verandert 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 ruggengraat zal de lijst alleen maar toenemen. Op die manier zul je niet eens het software-equivalent van een eenvoudig lichtknopje binnen redelijke tijd en kosten en met de gewenste functionaliteit leveren.
Reacties
Plaats een reactie op dit artikel