Fouten in IT komen helaas veel voor. Soms met dramatische gevolgen voor onze veiligheid, maar veel meer uiteindelijk resulterend in ergernis voor bedrijven en klanten. Maar computers maken nooit fouten: Het is 1 of 0, ofwel goed of fout. Simpel eigenlijk, maar waar komen fouten in de IT toch altijd weer vandaan?
Requirements ofwel eisen waaraan een systeem moet voldoen zijn cruciaal voor het voorkomen van fouten. Maar is het nu anno 2014 écht noodzakelijk om alle triviale eisen ook expliciet uit te schrijven? Zo zijn belangrijke eisen op het gebeid van:
- performance
- omgevingsomstandigheden
- betrouwbaarheid
- onderhoudbaarheid en
- beveiliging
zelden volledig uitgewerkt. En het kan voor het ontwerpen van bijvoorbeeld een kassasysteem toch wel verschil maken of deze moet functioneren op een markt in zonnig Afrika, waar de stroom vaak weg valt, of bij de ingang van een stadion, waarbij iedere seconde wachten er één te veel is. Veel ‘standaard’ eisen die aan een bepaald type systeem gesteld moeten worden zijn gelukkig beschikbaar via standaard uitgeschreven normenkaders ontwikkeld door industrie en/of wetgevers. Het voldoen hieraan is vaak noodzakelijk. Vaak zijn eisen voor een systeem niet expliciet beschikbaar wanneer een architectuur of ontwerp wordt opgesteld. Zeker triviale eisen als minimale performance eisen en eisen die aan bediening of onderhoud van een systeem gesteld worden kunnen leiden tot een explosie van budget in de ontwerpfase. En natuurlijk is de vraag stellen relevant: Wie is nu eigenlijk verantwoordelijk voor het impliciet meenemen van de triviale eisen? Bijvoorbeeld de software moet werken in een browser? Of als ik op de knop ‘print’ druk wil ik een printje. Zelfs in een trein of vliegtuig!
Eisen roepen vaak veel vragen op. Een dialoog over iedere eis is vaak cruciaal om de impact en eis te begrijpen. Zo roept een eis als ‘de software moet werken in een browser’ de volgende vragen op:
- Moet de software werken in een browser op een smartphone, tablet of desktop pc?
- Is het de bedoeling dat de gemaakte software onafhankelijk van een specifieke browserversie werkt? Ofwel worden meerkosten geaccepteerd bij gebruik van een nieuwe Microsoft browser? Of voelt de klant zich dan direct opgelicht?
- Dient de software aan webstandaarden te voldoen? Zoals bijvoorbeeld html5, zodat look & feel verschillen tussen verschillende browsers makkelijker op te lossen zijn?
- Dient het werken van de software identiek te zijn in iedere browser voor ieder platform? Inzet van een aparte software laag om dit mogelijk te maken is dan vaak vereist, alleen al omdat de implementatie van webstandaarden, zoals bijvoorbeeld html5, niet identiek is in iedere browser.
Om uiteindelijk fouten te voorkomen bij vrijgave van een systeem is testen noodzakelijk. Primair om de meest ernstige fouten nog op te lossen, maar secundair om de dialoog te starten met de klant over welke vervelende facetten in het systeem nu eenmaal het resultaat zijn van het ontbreken van de juiste requirements, resources, tijd of budget om alles op orde te brengen. Automatisch testen van systemen en software is cruciaal om kosten onder controle te houden en kwaliteit van het testproces los te koppelen van de toevallige oplettende beta-tester. Helaas is automatisch testen van software systemen nog altijd niet een defacto standaard in de IT industrie. Hierdoor betaald een klant vaak via hoge onderhoudskosten de rekening, naast de vaak voortdurende frustratie waarom simpele wijzigen enorme kosten met zich mee brengen. Simpele wijzingen waarop automatisch testen veel voordeel geeft zijn:
- wijziging van hardware
- wijziging van operating systeem
- wijziging van browser
- wijziging van look&feel van een systeem
- wijziging van database of datamodel aanpassing
- toevoeging van nieuwe functionaliteit
- toename van aantal gebruikers
Veel omgevingsfactoren waarin een systeem werkt kunnen bedoeld of onbedoeld invloed hebben op de werking van een systeem. Door automatisch testen is de impact snel te bepalen. Hierdoor kan de levensduur van systemen vaak zonder extreme kosten eenvoudig worden verlengd.
Fouten in een systeem zijn bij grote complexe systemen niet te voorkomen. Wel de wijze om de gevolgen van fouten te minimaliseren. Bij het proces om systemen goed op te leveren is een juiste interactie tussen de vele betrokken disciplines cruciaal. Zo is het ondenkbaar dat requirements engineers niet goed afstemmen met software programmeurs en is het wenselijk dat architecten in de architectuur al oog hebben voor de wijze waarop de verschillende onderdelen automatisch te testen zijn.
Iedere goede programmeur maakt fouten. Deze zijn helaas vaak direct zichtbaar. Maar ook architecten en engineers betrokken bij realisatie van een systeem maken fouten. Veel fouten in de ontwerpfase blijven echter vaak lang onzichtbaar. Maar in een goed ontwerpproces wordt gebruik gemaakt van geautomatiseerde testfaciliteiten om fouten zo snel mogelijk te vinden en op te lossen. Want hoe later in het proces fouten naar voren komen, hoe duurder het repareren van de fouten wordt. Als het nog gebeurt…
