Dit is alweer mijn derde blog in de serie over softwarekwaliteit en -fouten. Het eerste blog ‘Waar softwarefouten toe kunnen leiden’ was een algemene inleiding tot het tweede blog waarin ik beschreef waarom er nog altijd softwarefouten worden gemaakt. Of ze nu het gevolg zijn van een beperkte focus op productrisico’s of een requirement ‘verkeerd’ geïnterpreteerd is, softwarefouten zullen er altijd zijn…
Voorkomen blijft natuurlijk altijd beter dan genezen. Daarom moeten we er in de software-industrie voor zorgen dat de productrisico’s, en de dekkingsgraad hierop, voldoende in kaart zijn gebracht en dat we afdoende risicomitigerende maatregelen nemen. Als Software Kwaliteitsspecialist voel je die verantwoordelijk uiteraard des te meer.
Een risico bestaat uit faalkans en schade (risico = faalkans * schade). De faalkans is de kans dat de software niet correct werkt en de schade wordt bepaald door de businessrisico’s die de organisatie loopt. In de meeste trajecten voert men wel een formele of informele product sisico analyse (pra) uit om deze eenheden te benoemen en vast te stellen. Maar ik kom nog altijd situaties tegen waarbij men zich niet van te voren op de hoogte stelt van het mogelijke risico.
Enfin, je ziet dus dat risico wordt bepaald door deze twee factoren, waarbij schade de factor is die vaak op voorhand wel te voorspellen is. De faalkans daarentegen is wat minder stabiel. Hoe vaak zie je niet dat de kwaliteit van de producten tijdens een bouw- of implementatieproject te kort schiet. Het aantal defecten in de software neemt toe en daarmee neemt ook de faalkans toe. Verschillen in ervaring en kwaliteit van ontwikkelaars, minder of meer complexe functionaliteiten of het continu wijzigen van architectuur en functies liggen hieraan ten grondslag.
In de basis bepalen met name de fase waarin je een pra uitvoert en de middelen die de testmanager tot zijn beschikking heeft hoe klein (of groot) de risicobandbreedte is. De kunst is dan ook om het proces zo in te regelen dat de bandbreedte van het risico zo klein mogelijk gehouden wordt door vroegtijdig een gedegen pra uit te voeren. Dit is zoals het in de praktijk ook wel gangbaar is. Maar naar mijn bescheiden mening is dat te beperkt. Immers, halverwege het project zal de inschatting uit de initiële pra waarschijnlijk deels achterhaald zijn en zullen nieuwe risico’s zijn geïntroduceerd.
Eigenlijk zou een pra continu uitgevoerd moeten worden, zodat de testinspanning voortdurend gericht kan worden op de grootste risico’s. Ik pleit dan ook voor een aanpak waarbij je de verschillende producten (denk hierbij aan requirements, functioneel ontwerp, technisch ontwerp, softwarecode, documentatie) continu, grotendeels geautomatiseerd toetst en de uitkomsten terug de pra in laat stromen. Door het inzetten van een dergelijke continue product risico analyse, ofwel een dynamische pra zorg je ervoor dat met een minimale inspanning een eventuele mismatch voorkomen kan worden. Met wederom het grote en bekende voordeel dat je bevindingen eerder in de ontwikkelcyclus constateert en daarmee de herstelkosten naar beneden brengt. Op deze manier kan de business case voor een continue product risico analyse door een integrale aanpak van software- en productkwaliteit al snel een overtuigende business case opleveren.
Een dynamische pra is niet enkel voor de project/testmanager zeer nuttig. Het is ook waardevol voor de klant die vanuit zijn regierol inzicht en grip wil hebben op de kwaliteit en aansluiting op de requirements van tussentijdse producten die de softwareleverancier oplevert. Ik ben van mening dat het alleen maar ten goede komt aan het testvak als de blackbox in software ontwikkeling wat meer wordt geopend!
De software-industrie doet er in mijn ogen dan ook goed aan om haar klanten mee te nemen in dit tussentijds toetsen van kwaliteit. Het zorgt uiteraard voor wat extra druk op de afgesproken mijlpalen (producten worden pas geaccepteerd als de kwaliteit en aansluiting met de requirements voldoende is). Maar tussentijds toesten van kwaliteit zorgt er uiteindelijk voor dat de klant vanuit zijn regierol vroegtijdig inzicht en grip krijgt op het project. Met daarbij het vertrouwen dat men het afgenomen en gewenste systeem voor hun gebruikers opgeleverd krijgt. En dat is heel wat waard!
Een pra biedt een uitstekende basis om actief te sturen op de testaanpak en te rapporteren in de vorm van productrisico’s en wijzigingen hierop.
Fijn dat de PRA weer eens belicht wordt. Ik kan het ook niet meer dan eens zijn met de stelling dat, net als een ontwikkeltraject, de PRA niet statisch is. Regelmatig zal bekeken moeten worden welke risico's er zijn en of de onderkende risico's nog steeds dezelfde grootte hebben. Als aanvulling op het artikel: ook de schade verandert. Veranderende belangen van de business of ontwikkelingen bij concurrenten kunnen grote impact hebben op de schade die bij de risico’s gedefinieerd was.
Het artikel voelt wel aan alsof het vanuit de watervalgedachte is geschreven. In goedlopende SCRUM-trajecten is de continue PRA al ingericht. Elke sprint wordt er opnieuw gekeken naar risico’s en zal de testinspanning beïnvloed worden.
Al met al, goed dat de continue PRA onder de aandacht wordt gebracht.
Jeroen Mengerink | 7 juli 2013 00:38 
Lees ook