Blog

Murphy’s law en software testen

Geplaatst op 29/04/2021

Door: Nico van Mourik, Consultant bij ViQiT

Hou jij ook van een goed verhaal? Ik wel. Dat betekent dat ik in het afgelopen ‘coronajaar’ veel podcasts heb beluisterd tijdens mijn wandelingen. Hierbij luister ik graag naar wetenschappelijke podcasts. Door mijn collega Lennart werd ik gewezen op een leuke: ‘The infinite monkey cage’. De laatste aflevering die ik luistere ging over wetten die eigenlijk geen wetten zijn. Niet in de wetenschappelijke context in ieder geval. Eén van de bekendste is wel Murphy’s Law. Er zijn wetenschapers die geprobeerd hebben om via een mathematische formule te bewijzen.

Het leuke is dat, toen ik dit beluisterde, ik gelijk moest denken het werkgebied waar ik werkzaam zijn. Waarom dat is zal ik proberen uit te leggen.

Murphys’s law en IT

Eerst even over Murphy’s Law. Voor iedereen die in de IT werkt of met IT oplossingen te maken heeft, moet dit toch een gevoel van herkenning oproepen! “Als het ergens mis kan gaan, dan gaat het ook mis”. Dit is toch wel het kenmerk van een gemiddeld IT project, nietwaar? Nu is deze wet geen natuurkundige wet. Dus academisch bewijs dat dit altijd opgaat is er niet, hoewel er een leuke poging is gedaan door een Canadese wetenschapper. Als je vergelijkingen leuk vindt dan zou ik dit artikel vooral eens lezen.

De wet wordt toegeschreven aan Edward A. Murphy en hij maakte de originele opmerking die gericht was op de teamleden waar hij mee werkte: “if there’s any way they can do it wrong, they will”. En dat sluit dan weer behoorlijk goed aan op de IT wereld. Want IT is en blijft mensenwerk en dus maken we allemaal  ook de bijbehorende fouten.

Hoeveel we ook testen, hoe goed de kwaliteitsmaatregelen zijn, hoe briljant de mensen zijn die er aan werken: uiteindelijk gaat er altijd iets mis.

Wat kunnen we hier dan mee?

Het leuke aan de eerder genoemde vergelijking voor Murphy’s Law is niet dat hij altijd uitkomt (de vergelijking nog niet geprobeerd? Toch even doen😊), maar dat het de kern blootlegt van deze wet: het is geen bewijs, maar een ‘call to action’ voor de betrokkenen. Als je weet dat jij en je teamleden altijd een manier zullen vinden om het fout te doen, dan kun je ook maatregelen nemen om het aantal fouten zo klein mogelijk te houden en de impact zo beperkt mogelijk.

ik bedoel dit als volgt: in de originele vergelijking worden er 4 parameters benoemd, op basis waarvan de situatie beoordeeld moet worden:

  • (I)mportance
  • (C)omplexity
  • (U)rgency
  • (F)requency

In andere artikelen (hier bijvoorbeeld) spreken ze zelfs over 6 parameters en voegen ze ook nog “(S)kills” en “(A)ggravation” toe. Zelf ben ik wel gecharmeerd van deze toevoeging. Zeker omdat ik zelf deze elementen vaak gebruik voor een inschatting van de risico’s van een project, een programma of een situatie.

Een voorbeeld

Stel je voor: je start op een verbeterprogramma bij een klant waar ze de vraag van hun klanten en de producten van de leveranciers veel beter, sneller en goedkoper op elkaar willen laten aansluiten. Jij gaat starten in het IT deel van hiervan, want de doelstellingen kunnen alleen bereikt worden wanneer goede IT oplossingen worden geïmplementeerd. Natuurlijk kan de organisatie niet even worden stilgelegd, dus tijdens de verbouwing blijven we gewoon open. Daarnaast past de huidige organisatiestructuur ook niet meer bij de dynamische wereld van nu. Oh ja, gezien de wens om de  concurrentie een tik uit te delen moet het klant deel al dit jaar worden geïntroduceerd; de marketing campagne voor de introductie wordt al ontworpen ‘as we speak’. Of jij even de QA en test activiteiten kan organiseren. Pfoe.

Een korte check op deze 6 parameters helpt dan vervolgens om een beeld te krijgen van de ernst van de risico’s

Importance

Hoe belangrijk is het? Het lijkt heel belangrijk. Maar of dat ook werkelijk zo is, is niet op basis hiervan vast te stellen. Want bij een beetje doorvragen in de eerste week, blijkt dat de organisatie de absolute marktleider is in een markt met een beperkt aantal aanbieders. Daarnaast is het voor nieuwe aanbieders moeilijk om binnen een jaar een beetje voet aan de grond te krijgen. Natuurlijk is het belangrijk. Ze willen niet voor niets veel investeren in een dergelijk project, want de concurrentie zit ook niet stil. Maar het voortbestaan van de organisatie hangt er niet volledig van af.

Complexity

Hoe complex is de betreffende oplossing. Heel erg complex! De activiteiten, informatiestromen en verantwoordelijkheden gaan over diverse afdelingen binnen de organisatie. Een aantal onderdelen van de gekozen IT oplossing is volkomen onbekend binnen de organisatie en zijn technisch gezien behoorlijk innovatief. De kans dat hierdoor iets mis gaat is behoorlijk.

Urgency

Dat is een lastige! Zoals bij importance al gezegd: het voortbestaan van de onderneming hangt er niet direct van af. Maar toch is het gevoel van urgentie groot. Want de afgelopen jaren is de concurrentie wat sneller gegroeid dan wij. Door deze oplossing aan de klanten te bieden kunnen we laten zien dat we geen ouderwets clubje meer zijn, maar dat we juist een modern, digitaal  opererende organisatie zijn die met hun klanten meedenkt en snel en flexibel kan inspelen op vragen. Probleem is alleen: daar is de organisatie niet helemaal op ingericht. Dus het gevolg van de urgency in de klantgerichte portal, is dat het (nog) niet helemaal aansluit bij de rest van de organisatie.

Frequency

Hoe vaak gaat het gebruikt worden? In dit geval is dat 24×7. Want de klant portal is gewoon continue bereikbaar. Het is niet de verwachting dat dit ook zo gebruikt gaat worden, maar dat weet je vooraf niet. De kans dat er iets mis gaat is dan ook behoorlijk groot. Zeker als door de marketingcampagne er ook nog nieuwe klanten bijkomen. Deze ken je nog niet en ze kennen jou ook nog niet, dus dat betekent meer kans op fouten in de servicebeleving.

Skills

Welke mensen werken eraan? Is er een gespecialiseerd team hier mee aan de slag? Er zijn een groep technische experts van buiten aangetrokken. Die kennen de branche niet echt, maar ja daar heb je dan de interne specialisten voor die parttime aan het project zijn toegewezen. De beste, meest ervaren krachten zijn daarvoor ingezet. Probleem is wel dat de communicatie tussen beide groepen wat stroef verloopt. Net het onderwerp, waardoor de meeste fouten ontstaan in projecten!

Aggravation

Hier bedoelen we mee de ergernis of frustratie die opgeroepen wordt wanneer iets mis gaat. Ofwel: hoe irritant is het wanneer dit risico optreedt? Dit is bijzonder hoog! Zowel extern bij de klanten, als ze niet hun orders kunnen plaatsen of hun vragen kunnen stellen, maar ook intern. Want als je je klanten niet makkelijk en soepel kunt helpen en daardoor de frustratie over je heen krijgt, dan wordt de kans dat zaken misgaan alleen maar groter.

En nu verder…

Okay, je hebt nu een beeld van hoe waarschijnlijk het is, dat er iets mis kan gaan. Die is bijzonder groot. Maar deze conclusie op zich is interessant, maar nog interessanter is wat je hieraan gaat doen. Want: de inschatting is de basis voor een ‘call to action’

Dus wanneer je duidelijk hebt welke risico’s er zijn en welke parameters er op van toepassing zijn, wat kun je dan doen om de afbreuk risico’s te verminderen?

Kun je door de urgency te verminderen meer tijd ‘kopen’ en zo de complexity beter beheersen? Of kun je dit bereiken door andere skills aan het project toe te voegen? Of allebei? Is er een manier om de aggravation te verminderen als er onverhoopt iets mis gaat? Of verhoogt dit juist weer de complexity? En een belangrijk ander onderdeel: je kunt nooit alle fouten voorkomen, dus hoe bereid je je voor op de dingen die mis kunnen gaan? Je kunt je ‘contingeny’ maatregelen alvast benoemen en inrichten.

Geen makkelijke antwoorden te vinden natuurlijk. Maar door het inzicht kun je wel een inschatting geven van de kans dat zaken mislopen en je voorbereiden op wat er mis kan gaan. Heb je dan een volledig beeld? Nee natuurlijk niet. Maar met behulp van een wet die geen wet is, heb je wellicht een startpunt om de juiste risico inschattingen te maken.