ORDINA BLOGT

De kunst van het heldere denken

  • Erik Hendrikx
  • 19 april 2017

Confirmation bias

Confirmation bias, in het Nederlands voorkeur voor bevestiging genoemd, verwijst naar de neiging van mensen om meer aandacht en waarde te hechten aan informatie die de eigen ideeën of hypotheses bevestigt. Tegelijkertijd is er de neiging om minder aandacht te besteden aan informatie die eigen ideeën tegenspreekt.

Een heel bekend voorbeeld van deze denkfout is de zogenaamde tunnelvisie, die vaak wordt toebedeeld aan politiemensen in een onderzoek. Als aan het begin van het onderzoek de politie een vermoeden heeft van de dader of de oorzaak van een misdrijf en dit vervolgens als de waarheid bestempelt. Bewijzen die deze hypothese staven worden nadrukkelijk vermeld in de rapportage en zaken die tegenstrijdig zijn, worden niet vermeld of verdwijnen naar de bijlagen.

Uit psychologisch onderzoek is voren gekomen dat mensen geneigd zijn bevestiging te zoeken in plaats van te proberen hun hypothese te weerleggen.

Sommige onderzoekers gaan zelfs zo ver dat ze hun data manipuleren, zoals de Tilburgse psycholoog Diederik Stapel of de Zuid-Koreaanse stamcelonderzoeker Hwang Woo-suk. De vader van de evolutietheorie, Charles Darwin, wapende zich tegen de verleidelijkheid van het bevestigingsvooroordeel door elke waarneming, elk feit en elke gedachte die zijn algemene resultaten tegensprak te noteren. Zelf nu bestaan er nog streng christelijke scholen die vreemde kromme redeneringen hanteren om bewijzen van de evolutie theorie te weerleggen ten gunste van het scheppingsverhaal. En recentelijk de nieuwe president van de Verenigde Staten die de indruk wilde wekken dat minstens zoveel mensen waren wezen kijken bij zijn inauguratie als bij zijn voorganger, terwijl de fotobeelden overduidelijk het tegendeel bewezen. Het mag duidelijk zijn dat het uitsluitend zoeken naar bevestiging kan leiden tot allerlei problemen.

Confirmation bas en testen van software
In deze blog wil ik betogen dat een dergelijke (tunnel) visie ook voorkomt in de dagelijkse praktijk van het testen van software en ik durf de stelling aan dat geautomatiseerd testen dergelijke denkfouten stimuleert, terwijl handmatig of exploratief testen ons kan helpen dergelijke denkfouten niet te maken of te voorkomen. Exploratief testen (Engels: exploratory testing) is een benadering van het testen van software die bestaat uit simultaan leren, testontwerp en testuitvoering. Terwijl de software wordt getest, doet de tester kennis op die weer nieuwe testen genereert.

Een belangrijk aspect bij testen is het vaststellen van de norm. Oftewel de vraag: wat is correct? Bij computerprogramma's kan dit zijn vastgelegd in één of meerdere documenten, waaronder een technisch of functioneel ontwerp, een interactie-ontwerp of ontwerp van de grafische gebruikersinterface. Deze documenten vormen samen de testbasis, het geheel van producten waarop de verwachtingen, oftewel het testontwerp, wordt gebaseerd. Er wordt gesproken van 'verwachtingen', omdat er bij software testen niet wordt gekeken of de software goed of fout functioneert, maar of de resultaten overeenkomen met wat er in de testbasis is beschreven en/of wat men 'verwacht'.

Deze verwachtingen zijn opgesteld door de informatieanalist of softwareontwerper. Hij/zij is hierbij uitgegaan van denkbeelden hoe hij/zij zou willen dat de software zou moeten functioneren. Maar kloppen deze verwachtingen en/of zijn deze verwachtingen op een diep genoeg detailniveau gespecificeerd? En kloppen deze verwachtingen na verloop van tijd nog steeds?  Het is belangrijk om tijdens de review van een programmaontwerp of een testontwerp je hiervan bewust te zijn.

Voorkomen is beter dan ….  of gedeelde smart is ….
Bij het vaststellen van testgevallen ga je uit van het gewenste gedrag (de requirements) en zoek je bewijzen om dit gedrag aan te tonen. In hoeverre bestaat hierin ook het gevaar van het bevestigingsvooroordeel?  Ben je hierin ook voldoende kritisch?  Of is er (ook) sprake van een tunnelvisie ?

In de ‘nieuwe’ wereld van DevOps is de scheidslijn tussen ontwerp en test vervaagd. We zijn allemaal Development Engineers. Er is geen overdrachtmoment meer van ontwerp naar test. Het risico bestaat dat de ontwerper zijn werk zelf gaat testen. Met als valkuil weer het bevestigingsvooroordeel.

In de wereld van geautomatiseerd testen ga je uit van een regressieset. Een bepaalde hoeveelheid user stories waarmee je kan aantonen dat de functionaliteit van de ongewijzigde code nog steeds functioneert. Maar wat als de wereld om je heen is veranderd en de code niet?  In de wereld van ‘conformation bias’ zoek je naar bewijzen om een bevestiging te krijgen. Maar wat als je nu het tegendeel als basis gebruikt om aan te tonen dat het nog steeds werkt?  Dus niet (alleen) de happy flow gebruiken als basis voor regressie.

Een manier om de effecten van een bevestigingsvooroordeel te verminderen, is het gebruikmaken van technieken als Pairwise programming en Pairwise review, waarbij je kunt sparren. Hierbij is uit onderzoek gebleken dat het gebruikmaken van meerdere disciplines (of expertises) het beste werkt. Dus bijvoorbeeld een ontwerper en een tester naast elkaar. In grotere agile teams zouden de samenstellingen van koppels regelmatig moeten wijzigen. Het komt de communicatie in het team ten goede.

Een voordeel van pair programming is de directheid: het is onmogelijk om de reviewer wanneer hij of zij zit naast je negeren. In de traditionele ‘review’  gebeurde dit nogal eens. [..]. Koppelen kan ingrijpend zijn, maar het kan ook een niveau van communicatie forceren  die je zou anders nooit bereiken. In tegenstelling wat vaak veronderstelt wordt, levert deze manier van werken op termijn tijdswinst op, omdat de overdrachtsmomenten zijn verdwenen. Het verhoogt ook de onderhoudbaarheid van code en het gevoel dat we samen een stukje werkende code opleveren. Voorwaarde is wel dat de koppeltjes gevormd worden met mensen die ongeveer op een zelfde niveau zitten.