Blog

Testing is here to stay!

Op voorspraak van Agile consultancybureau’s, die veel van Agile weten maar weinig van testen, worden bedrijven steeds vaker geadviseerd om de rol ‘tester’ af te schaffen. Ontwikkelaars kunnen dat werk net zo goed doen, zo beweren zij. Bovendien kan het testen volledig geautomatiseerd worden. Dus waar zijn al die mensen nog voor nodig? Als je al wat langer meeloopt in de testwereld (ik inmiddels > 20 jaar) dan weet je dat dit geluid niet nieuw is. Eens in de zoveel jaar staat er een groep jonge enthousiastelingen op die menen dat alles geautomatiseerd kan worden en dat alles ‘helemaal op de schop moet’. Zo’n instelling past natuurlijk bij de leeftijd en het is goed voor de vooruitgang om ieder decennium je opnieuw af te vragen of het niet allemaal anders moet. Zeker gezien alle technologische vooruitgang is het goed om je af te vragen of het inmiddels wél mogelijk is om de tester door een ontwikkelaar en wat tools te vervangen. Medio jaren ’90 was die belofte er al, maar toen nog niet realistisch. Hoe zouden we er nu voor staan? Het antwoord is simpel: We zijn er nu niet aan toe, en in de toekomst ook niet. Dus Z-generatie: als jullie er over 10 jaar ook weer mee komen lees dan eerste even deze blog … Anders blijf ik bezig.

Het idee dat alle tests te automatiseren zijn is fout.

James Bach (o.a. Rapid Software Testing is door hem bedacht), wereldwijd leider op gebied van software testen, maakt verschil tussen checks en tests. ‘Checks’ zijn verificaties van hetgeen is gedocumenteerd, bijvoorbeeld in user stories. Dit soort checks zijn goed te automatiseren (ook niet allemaal, GUI is en blijft erg lastig te automatiseren omdat deze aan frequente wijzigingen onderhevig is). ‘Tests’ zijn juist díe dingen controleren die NIET zijn gespecificeerd. En als het niet gespecificeerd is, hoe kun je het dan geautomatiseerd testen? Niet dus. In de praktijk blijkt dat zo’n 75% van alle risico’s die ICT systemen lopen voortkomen uit features die NIET zijn gespecificeerd. Dus denken dat door het automatiseren van tests het gehele testvraagstuk op te lossen is, is slechts een oplossing voor maximaal 25% van het gehele vraagstuk. En eigenlijk weten we dit ook wel. De grote problemen die in productie voor komen blijken, na tracing, altijd zaken te zijn die niet gespecificeerd en dus ook onverwacht waren. Altijd! Daarnaast is een automatische test (een check) statisch. Je herhaalt continu dezelfde checks, behalve als je steeds nieuwe checks script en opneemt met Capture & Playback tools. Ergo, je checkt steeds dezelfde gebieden in de software en vindt steeds dezelfde bugs. Het verschil tussen checks en tests wordt ook geïllustreerd door onderstaand figuur.

check-test-ET

In beide gevallen heb je een (zelfde) doel. Als je checkt ben je gefocust op je doel en blijf je binnen de kaders. Maar als je aan het testen bent en iets vreemds ziet, ga je het verder onderzoeken. En weer verder, en weer verder. Je blijft niet alleen maar binnen de kaders denken maar er ontstaat een soort boomstructuur van geteste paden. Er is nog steeds focus op het doel van de test, maar als er onderweg obstakels ontstaan wordt er onderzocht of die blokkerend zijn voor het doel of niet. En dit creatieve proces is NIET te automatiseren. Checks zijn te automatiseren, Tests niet.

Het idee dat ontwikkelaars goede testers zijn is fout.

Testers zijn geheel andere type mensen dan ontwikkelaars. Ontwikkelaars stellen ‘When’ vragen. Testers stellen ‘If’ vragen. Dus waar ontwikkelaars vooral nadenken over het goedpad, denken testers out of the box en vooral hoe het mis kan gaan. Het verschil in focus en intrinsieke motivatie zie je bijvoorbeeld goed bij de Myers-Briggs type indicator voor verschillende persoonlijkheidstypen:MyersBriggsTypes

Ontwikkelaars zitten vooral in het linker-bovenkwadrant (IS) en testers vooral rechtsonder (EN). Ook in teams gedragen ontwikkelaars en testers zich anders. In Belbin Teamrollen: ontwikkelaars zijn vooral Planten en testers Brononderzoekers. Zeggen dat ontwikkelaars het werk van testers kunnen doen betekent dat je met de zachte kant van mensen totaal geen rekening houdt. Natuurlijk kan een ontwikkelaar ook een testtechniek aanleren. En een tester kan ook leren programmeren. Ik ben heel erg voor T-shaped. Maar dat is niet de essentie. De essentie is juist de zachte kant, de houding van een ontwikkelaar versus die van een tester. En die zijn compleet het tegenovergestelde. Uitzonderingen daargelaten …
Daarbij, of wellicht zelfs daardoor, vinden ontwikkelaars testen ook helemaal niet leuk en omdat ze dan ‘toch maar moeten testen’ worden ze minder goede ontwikkelaars. Mensen moeten doen wat ze leuk vinden en waar ze goed in zijn. Dat is iets wat ik in jaren van ondernemen en managen geleerd heb. Mensen excelleren in hetgeen ze leuk vinden, en andersom. Een top-ontwikkelaar is slechts zeer zelden een top-tester en een top-tester is zeer zelden een top-ontwikkelaar. T-shaped bestaat, maar M-shaped is een utopie. Gezien de complexiteit van de vakgebieden kun je niet tegelijkertijd een testspecialist en een ontwikkelspecialist zijn.

Voorbeelden

Deze casus is een paar jaar geleden breed uitgemeten in de pers en op het internet. De belastingaangiftes van ondernemers werden via queues verwerkt die persistent waren volgens de leverancier van het aangiftesysteem. Dat betekent dat er geen aangifte (en informatie over de aangifte) verloren gaat tijdens het inlezen. En daarom werd expliciet gespecificeerd dat de berichten die binnenkwamen nergens opgeslagen hoefden te worden. Er hoefde dus geen ‘check’ plaats te vinden, en dus ook geen geautomatiseerde test. Maar een echte tester kijkt verder. Er bleek, na wat onderzoeken, dat er wel degelijk berichten konden verdwijnen. Het leeuwedeel van de ondernemers moest uiteindelijk opnieuw aangifte doen omdat de aanlevering niet opnieuw gestart kon worden en omdat de binnengekomen aangiftes nergens waren opgeslagen. Een goede tester zoekt daar waar je problemen verwacht en risico´s ziet. En gaat juist dán vragen stellen en verder onderzoeken. Een ontwikkelaar is al sneller tevreden (“it works on my machine”).
Een wat meer alledaags voorbeeld: In een voetbalteam heeft iedereen een positie en een rol. Maar als het nodig is zal de spits meeverdedigen of gaat de keeper mee in de aanval om ‘m in de laatste minuut in de andere goal te koppen. Maar een keeper kan niet 90 minuten lang op het hele veld spelen. En een spits die veel in de verdediging rondloopt zal niet veel scoren. Waarschijnlijk wisselt een trainer binnen no time zo’n keeper of spits.

Wat levert een aparte testrol op?

Door het onderkennen van de testrol en de inzet van testspecialisten zal er meer inzicht in de risico’s verkregen worden, de kwaliteit van de software zal toenemen én de kosten van ontwikkeling zullen teruglopen. Er zijn hier geen benchmarks van bekend, maar eigenlijk weten we dit al heel lang. BOEHM kwam er al mee in de jaren ’70. Door niet te testen, of slecht te testen, nemen de kosten voor software ontwikkeling exponentieel toe. En de imago schade is tegenwoordig een zeer groot risico. Fouten worden breeduit gedeeld op sociale media. Mensen zijn niet meer trouw aan een bedrijf. Doe je het niet goed, dan gaan ze direct naar een ander. Dat geldt voor retail, banken, telecomprovider, energiemaatschappij, verzekeraars, et cetera.
Niet alleen ik vind dat Testen een vak apart is dat door specialisten moet worden uitgevoerd. Dat vindt bijvoorbeeld Worksoft ook, zie https://www.worksoft.com/. Worksoft zit in Gartner’s Magic Quadrant als Leader in Test Automation. Dus ook Gartner ondersteunt deze visie. Automatiseer vooral de checks, maar vervang goede testers niet door ontwikkelaars. Dat gaat je veel klanten kosten …