Gij zult geen aannames doen
7 juli 2019 

Gij zult geen aannames doen

Waarschijnlijk heb je als tester vaak tegen anderen gezegd of van anderen gehoord: “Je mag als tester geen aannames doen”. Een mooie uitspraak. Het is echter zo dat iedereen aannames doet, dus ook testers en mensen die andere rollen vervullen binnen de IT.

Het is dus van belang dat je je er van bewust bent dat je aannames doet en oefent met het checken van aannames.

Wat zijn aannames

Er is sprake van een aanname wanneer je iets voor lief neemt zonder bewijs ter ondersteuning. Je neemt iets aan voor waar, zonder daar enig bewijs voor te hebben.

Definitie
De encyclopedie zegt over aannames het volgende; “Aanname; iets wat je denkt of vindt zonder het te weten”. Het wordt, vooral in wetenschappelijke teksten, gebruikt in de betekenis ‘veronderstelling en hypothese'.

Bij verborgen aannames gaat het erom dat we denken zoals het hoort, dingen doen omdat we ze altijd zo deden, zonder er ook maar bij stil te staan om ze te checken.

Een aanname ontstaat door de interpretatie die we aan iets geven. En die interpretatie ontstaat weer vanuit onze ervaringen uit het verleden.

We zien, horen of lezen iets en we geven er direct een betekenis aan. Al onze zintuigen zijn er op gespitst om in milliseconden een interpretatie te maken van wat we denken waar te nemen. Is het goed of slecht? Welke associaties horen bij dit gevoel of deze gedachte?

Voorbeeld
Jaren lang heeft de mensheid gedacht (aangenomen) dat de aarde plat was.

Dat we interpretaties maken is goed, want zo houden we ons leven overzichtelijk en hoeven we niet alles te checken of het wel is zoals we denken.

Soms is het handig om aannames te checken. In het werk van een software tester is dat heel belangrijk. Onjuiste aannames kunnen namelijk schade opleveren zoals, misvattingen, verspilling, herstelwerk, stroef lopende en budget overschrijdende projecten, conflicten, slechte samenwerking, ontevreden klanten, etc.

Onderstaand een aantal voorbeelden

Voorbeeld 1

Stel het volgende requirement
De resultaten op de lijst moeten gesorteerd worden op belangrijkheid.

Wellicht heb je al andere rapporten getest waar belangrijkheid betekende sorteren op veld “prioriteit”. De kans is nu aanwezig dat je voor het hiervoor genoemde requirement aanneemt dat ook in dit geval gesorteerd moet worden op veld “prioriteit”.

En dan blijkt later dat in deze situatie de “datum” de belangrijkheid aangeeft. Dit omdat in dit geval de resultaten met de oudste datum als eerste moeten worden afgehandeld.

Als je pech hebt kom je daar pas achter bij de testuitvoering. Je meld een bug omdat de lijst niet gesorteerd is op veld “prioriteit”, maar op veld “datum”. De bug wordt vervolgens afgedaan met “geen bug”. En het wordt nog vervelender als de ontwikkelaar ook heeft aangenomen dat er gesorteerd moet worden op veld “prioriteit”. In dit geval wordt de bug niet ontdekt met testen, maar pas in productie.

Voorbeeld 2

Stel het volgende requirement
De controle moet uitgevoerd zijn voor het einde van het lopende onderzoek. Het einde van een onderzoek is vastgelegd in veld “einde onderzoek”.

Welke van de 2 onderstaande aannames is dan correct:

  1. De controle moet afgerond zijn voor de datum in “einde onderzoek”
  2. De controle moet uiterlijk afgerond zijn op de datum in “einde onderzoek”

Het antwoord is: we weten niet welke van de 2 correct is. Dit omdat we niet weten of op de datum in veld “einde onderzoek” nog controles uitgevoerd mogen worden.

Hier kun je alleen achter komen door het op te zoeken in bijvoorbeeld een definitie document of het na te vragen bij de functioneel ontwerper of product owner.

Het antwoord kan dan zijn: “Einde onderzoek” is de datum waarop het onderzoek volledig moet zijn afgerond. Op deze datum mag niet meer aan het onderzoek worden gewerkt. In dit geval is aanname 1 dus correct.

Het antwoord kan ook zijn: “Einde onderzoek” is de datum waarop het onderzoek uiterlijk moet worden afgerond. Op de datum mag nog aan het onderzoek worden gewerkt. In dit geval is aanname 2 dus correct.

Waarom doen we aannames?

Het voorkomt dat je lange(re) gesprekken met iemand moet voeren waarbij je anderen moet ‘uitdagen', of dat jijzelf wordt geconfronteerd, of veel vragen moet stellen om echt te begrijpen wat er gebeurt of hoe iets werkt; “We weten toch al hoe het werkt?”. Onthoud dan; “assumptions are the mother of all screw ups”.

Vrij vertaald: aannames liggen aan de basis van vele mislukkingen. Ook op het vlak van communicatie.

Maak jij wel eens aannames?

Ben je benieuwd of jij ook wel eens aannames doet, let dan eens op het aantal gesloten vragen die je stelt (vragen die alleen met ‘ja' of ‘nee' te beantwoorden zijn).

Gesloten vragen zijn een indicatie dat er aannames worden gedaan. Wanneer je open vragen stelt (vragen die beginnen met wie, wat, waar, waarom, wanneer, welke en hoe), wordt de kans op aannames direct kleiner.

Een paar tips om aannames te voorkomen

  • Ben je bewust van aannames. Sta er eens een dagje bij stil. Het zal je verbazen hoe vaak ze op de loer liggen.
  • Stel vragen, ook al denk je het antwoord te weten.
  • Vraag door als iets niet duidelijk is voor je. Veel aannames ontstaan omdat mensen geen vragen durven te stellen.
  • Vul nooit voor iemand anders in dat de informatie duidelijk is. Toets dit.
  • Geef bij (ingewikkelde) informatie altijd een duidelijke context.
  • Verplaats je in de ander en spreek zijn taal
Over de schrijver
Ik ben sinds 1983 werkzaam binnen de ICT. Ooit begonnen als Cobol en Credit programmeur en vervolgens de wereld van kwaliteitszorg en testen in gerold. In 1990 ben ik betrokken geweest bij de ontwikkeling van TMap® De jaren daarna heb ik vele functies vervuld binnen het testwerkveld. Waarbij coaching en doceren mij altijd erg is bevallen. Bij Cygnus ben ik met name verantwoordelijk voor het ontwikkelen van content en opleidingen. Heb je een testinhoudelijke vraag of wil je sparren over het stoppen van software fouten bij de bron? Neem dan gerust contact met mij op. Uiteraard ben ik ook beschikbaar voor consultancy opdrachten en coaching.
Reactie plaatsen

arrow_drop_up arrow_drop_down