mijn kijk op

Mijn visie op: aannames in het software testen

In het vakgebied van software testen zijn aannames heel vaak een bron van discussie. Hoe komt het nou dat er zulke grote verschillen in perceptie kunnen bestaan over zaken die eigenlijk een feit zouden moeten zijn? Aannames kunnen snel gemaakt zijn, maar later voor grote problemen zorgen. De tijd en moeite die het dan kost om de fout te herstellen en terug te draaien kan een enorme kostenpost worden. Hoe voorkom je nou dat zulke fouten in de software sluipen? Een gedetailleerde blik op het totale plaatje is dan wel zo gewenst.

Wat is nou precies een aanname?

De grap is dat als je zoekt met Google op de term 'aanname Wikipedia', dat je niet gelijk terechtkomt op een website waarin letterlijk de term 'aanname' staat uitgelegd. Je wordt doorverwezen naar een pagina 'vertrouwen', met als ondertitel: '(Doorverwezen vanaf Geloven (gedrag))'. Meer succes heb je wanneer je zoekt op de term 'Hypothese - Wikipedia'. In ieder geval, een aanname is iets wat je denkt of vindt zonder het zeker te weten.

Waarom is het onderwerp van discussie binnen het software testen?

Aannames kunnen voor grote problemen zorgen. Echter de paradox is dat software die onder ontwikkeling is nooit perfect is, het is niet af. Soms is het beginstuk van een module gereed en ook het eindstuk, maar het middendeel moet nog geprogrammeerd worden. Dat is een lastige situatie, al helemaal als de projectleider het testen graag "gisteren af wilde hebben". Dus om het systeem te testen wordt er soms met 'stubs and drivers' gewerkt. Zij vullen het middendeel tijdelijk in totdat de rest geprogrammeerd is. In deze situatie doet een software tester tijdelijk de aanname dat het afgebouwde middendeel dezelfde werking zal hebben als de 'stub of driver'.

Een ander voorbeeld is dat je soms niet weet hoe iets moet worden, maar dat je alvast bouwt in de richting van dat je denkt hoe het zal moeten zijn, op basis daarvan worden er aanpassingen gedaan. Dan heb je iets waarmee je kunt werken en er valt al iets te bekijken, net zoals een bord vol met eten gemakkelijker in te schatten is of het zal smaken dan een bord waar nog helemaal niets op ligt. Een andere aanname kan zijn dat een belangrijke persoon binnen de organisatie een uitspraak heeft gedaan over de werking van een module of object in het informatiesysteem, deze persoon is aan het eind van de week pas weer bereikbaar (voor het gemak van het voorbeeld heeft hij even geen mobiele telefoon of e-mail). Dan kun je met de handen over elkaar gaan zitten, of je kan zijn uitspraak naar beste eer en geweten inschatten en alvast die kant op bouwen (en testen).

Kortweg gezegd: er zijn momenten dat je als software tester wel tijdelijk aannames moet doen, omdat je anders met je armen over elkaar kunt gaan zitten, je kunt dan simpelweg niet verder met het testen. Om een ander voorbeeld hiervan te geven: stel dat je een auto rijdt en je benzine raakt op, dan ga je tanken. Ik heb nog nooit iemand met een pipetje en een laboratorium-kit metingen zien doen of de brandstof wel daadwerkelijk diegene is als dat op de pomp staat. Nee, we gaan er van uit (we doen een aanname) dat dit het juiste type brandstof is. Zo is het ook in het software testen. Soms moet je wel aannames doen, er is alleen een heel belangrijk principe in het testen, namelijk dat je aannames altijd moet verifiëren. In het geval van de auto, als deze 300 km goed rijdt dan zal het tanken waarschijnlijk wel goed gegaan zijn. Start de auto niet eens of slaat deze na een korte afstand rijden af, dan heb je misschien Diesel getankt en moest het eigenlijk Euro 95 ongelood zijn.

Aannames binnen en buiten het testen

Mensen van het software test-team kunnen aannames doen, maar op andere niveau's kan dit natuurlijk ook. Deze beleidsbeslissingen hebben dan niets met software testen te maken, maar kunnen toch voor problemen zorgen en zijn toch ook een aanname. Bijvoorbeeld als men er van uit gaat dat er geen Europese wet bij komt, terwijl dat na verloop van tijd toch zo is. Of als men inschat dat de concurrentie een bepaalde stap niet zal maken en deze dat uiteindelijk toch doet. Zo zijn er veel voorbeelden te bedenken van aannames die op andere niveau's zijn gemaakt. De discussie is dan ook wel eens, "dit is een aanname gemaakt door testers vs de testers hadden dit onmogelijk kunnen weten".

Het ontstaan van aannames

Duidelijke communicatie (of het gebrek daaraan) kan een grote bron zijn van het ontstaan van aannames. Bedenk maar eens op hoeveel manieren de zin: "morgen is er geen concert in het park" kan worden opgevat. (Het concert is niet morgen maar wel zaterdag, er is geen concert maar wel een circus, het is niet in het park maar wel in het stadion, etc.) Zo is het ook met het opstellen van requirements. Ze kunnen dubbelzinnig beschreven zijn en mensen kunnen hier (bewust of onbewust) aannames over doen.

Aannames ontstaan dus op verschillende niveau's en het is soms een grijs gebied op welk niveau de aanname ontstaan is. Ze kunnen soms ook dieper liggen, net zoals dat iemand een incongruente uitspraak kan doen. Een mooi voorbeeld in de IT is: 'IK BEN NIET AAN HET SCHREEUWEN!' want hoofdletters worden in het chatten (en digitaal/online schrijven) vergeleken met schreeuwen. Deze zin is dus tegenstrijdig.

Op dezelfde manier is ook de (Engelse) opmerking: 'Assumptions are the mother of all f*ck-ups' vrij incongruent. Er zijn wel meerdere, ergere dingen waardoor een bedrijf schade kan lijden. Wat te denken van mensen die moedwillig de boel saboteren of de concurrentie die een super idee doet, of... de bottom-line is: kijk uit met het roepen van zulke stellige dingen. Aannames kunnen ook in aannames zitten! Het zal niet de eerste keer zijn dat iemand binnen een organisatie iemand anders iets verwijt, terwijl na verloop van tijd blijkt dat hij zelf degene was die fout zat. Kortom, voorzichtigheid is geboden, een gewaarschuwd mens telt voor twee.

Roep dus niet te snel tegen een tester dat hij aannames doet, want vaak weten ze heel erg goed waar ze mee bezig zijn, ze vullen de gaten en verifiëren zo spoedig mogelijk zodra het kan. Bedenk dat er altijd twee kanten aan een medaille zitten.

Lees verder

• De kracht van functionele testers
• Software testen in ITIL
• Uitleg over softwaretest-rollen
• Software testen in Scrum
• Mijn visie op: verband paradoxen en illusies met testen