Barry Boehm, een Amerikaanse wetenschapper op het gebied van software engineering, stelde bijna 40 jaar geleden al dat het herstellen van softwarefouten exponentieel duurder wordt naarmate deze ‘defects’ in een later ontwikkelstadia worden vastgesteld. Zelfs anno nu wordt met regelmaat het bewijs voor deze stelling in diverse IT projecten geleverd.
Uw nieuwe badkamer
Bedenk u eens dat u uw huidige, verouderde badkamer compleet gaat vernieuwen. U gaat eerst alles zorgvuldig afwegen, passen en meten en vervolgens maakt u met de badkamerleverancier een keuze voor de indeling, de douche en het bad, wastafel en tegels. De leverancier legt zo veel mogelijk in detail vast in een ontwerp. Omdat de indeling geheel anders is vergeleken met uw huidige badkamer dienen alle leidingen verlegd te worden en in de muren te worden weggewerkt. Vervolgens wordt de badkamer geplaatst en de muren getegeld conform ontwerp. Als ook de kranen zijn geplaatst, zet u het bad aan en u ziet een dun straaltje water uit de kraan. En tot uw schrik ontstaat, op de muur boven het bad, een steeds grotere natte plek…
In bovengenoemd voorbeeld is geen Amerikaanse wetenschapper nodig om aan te tonen dat reparatie van het lek in de verlegde waterleiding goedkoper was geweest als men eerder had getest op lekkages. Net zoals het goed is om al eerder te testen of de stopcontacten op de juiste plaats zitten, kijkend naar het ontwerp. In een vroeg stadium zijn de eventuele herstelkosten voor het rechtzetten van fouten namelijk nog beperkt.
Eenvoudige maatregelen
Een badkamer is qua complexiteit uiteraard niet te vergelijken met een omvangrijk IT project. Toch kunnen eenvoudige maatregelen zowel tijdens de beschreven verbouwing als in een IT project grote (herstel)kosten voorkomen.
In de grafiek hierboven staat de theorie van Boehm afgezet tegen de fasering van een IT project. Hieruit is op te maken dat de kosten om een fout tijdens gebruik van de software vele malen hoger liggen dan het corrigeren van onjuiste requirements.
In het voorbeeld van de badkamer ligt het moment van ‘foutopsporing’ vlak voor de daadwerkelijke ingebruikname. Zo ligt ook in een IT project de focus vaak op de gebruikersacceptatietest. Een goede maatregel om dit tegen te gaan, is door het zwaartepunt van testen te verleggen naar de systeemintegratietest. Door in deze testfase een ‘risk based’ testaanpak te hanteren (zie ook een vorig artikel hierover), worden softwarefouten met de grootste schade als eerste inzichtelijk gemaakt en blijft er de meeste tijd over om deze te verhelpen. Dit zijn meestal tevens de fouten met hoge herstelkosten wanneer deze pas in een later stadium worden ontdekt.
Een andere maatregel ligt in het vroegtijdig aanhaken van testers. Wanneer de testers reeds bij het opstellen van de requirements worden betrokken bij het project, is het mogelijk om de eerste ontwerpen te laten toetsen op testbaarheid. Denk hierbij ook aan bijvoorbeeld eenduidigheid of het voorkomen van verwarring. Deze ‘fouten’ kunnen dan worden verholpen nog voordat de leverancier start met ontwikkelen. Bijkomend voordeel is dat de testers tijdens de eerste fase al veel logische testcases kunnen onttrekken uit discussies over het ontwerp. Dit scheelt tijd in het opstellen van te testen scenario’s.
Advies
Het advies is dan ook om de teststrategie dusdanig in te richten, dat de grootste fouten al in een vroeg stadium worden gevonden (en verholpen). In een eerste fase aanhaken van testers helpt hierbij enorm. Zo kunt u met gerust hart ‘de nieuwe badkamer’ tegemoet zien…
