Zet een schoen op het toetsenbord maar gebruik wel je hersens

James Bach, spreker op een bijeenkomst over ‘exploratory testing’, weet wel hoe dat komt. "Toen ik in de jaren tachtig bij Apple werkte hadden we al een theorie dat testers anders denken. Maar pas na het bestuderen van een handboek cognitieve psychologie een paar jaar geleden heb ik een antwoord gevonden: testers geloven in problemen. Een tester is iemand die weet dat dingen morgen anders kunnen zijn dan vandaag en anders kunnen zijn dan ze lijken. ‘Ik dácht dat ik mijn telefoon afgezet had, maar ik kán me vergist hebben. Misschien heb ik niet lang genoeg op het knopje gedrukt.’ We geloven in de mogelijkheid dat we door onze eigen technologie voor de gek worden gehouden. Managers, marketeers of ontwikkelaars geloven niet noodzakelijkerwijs in het falen als een normale gebeurtenis. Wij wel." Maar testers mogen dan gelukkig geloven in problemen, ze zoeken er meestal niet op de juiste manier naar, houdt Bach zijn gehoor voor op de ‘Tiende Nederlandse Testdag’. Testers moeten zich niet te veel laten voorschrijven hoe ze moeten testen, maar meer hun eigen hersens gebruiken. Zo vind je eerder de problemen waarvan een softwareproduct werkelijk te lijden heeft. De tester moet tijdens de testuitvoering nadrukkelijk van alles leren over het product en op basis daarvan zijn tests aanpassen. Exploratory testing, zoals de aanpak heet, trekt zich dus niet teveel aan van de gestructureerde en vooraf nogal gedetailleerde benadering van methoden als TMap, die de tester meer in een keurslijf duwt. Een heuristische benadering (heuristiek is de ‘leer van het vinden’) en een dosis eigen intellect helpen de tester, niet een eindeloze serie scripts die anderen voor hem hebben bedacht. Bach en andere voorvechters van het exploratory testen (ET) zijn beticht van geknoei; ze zouden slechts bezig zijn met ‘error-guessing’. Maar ET kent inmiddels een vrij systematische procedure en als iemand tegen Bach zegt dat zijn aanpak niet deugt, dient hij hem graag van repliek. "Ik ga een gevecht niet uit de weg, want al jarenlang is er in de IT verwarring gezaaid over hoe softwareprojecten zouden moeten lopen. De reden is dat velen de menselijke factor in IT willen negeren. De meeste procesverbeteraars leven bij de gratie van regels die anderen moeten volgen; ik ben precies het tegenovergestelde." Er zijn trucjes om snel te kijken of een systeem stabiel is. "Zonder iets te weten van een systeem, kan ik het misschien kraken door velden met een miljoen karakters te vullen. Het maakt indruk op mensen als je een systeem in vijf minuten kunt crashen." Maar zo’n geintje, het equivalent van het plaatsen van een schoen op het toetsenbord, mag niet je enige methode zijn, want dan zou Bach zijn kritikasters in de kaart spelen. Volgens hem komen veel testers weg met weinig productief werk, zolang ze onder het mom van ‘quality assurance’ documenten produceren die er indrukwekkend uitzien. "Die testers werken voor mensen die het testen niet begrijpen en die het verschil niet zien tussen goede testdocumentatie en slechte testdocumentatie. Dit creëert een habitat voor testers die niet veel af weten van het snel vinden van belangrijke problemen in software. En dat is toch de belangrijkste functie van een softwaretester. Het is ook makkelijk om testen te faken. De certificering is alleen kennisgebaseerd en niet gebaseerd op vaardigheden. Er is nog geen examen zoals: vind vijf problemen die we in dit product hebben gestopt. Dat moet er wel een keer komen." Wie Bach het afsnijden van bochten verwijt, krijgt van hem meteen gelijk. "Je moet iedere onnodige bocht afsnijden in ons werk. Een goede exploratory tester is iemand die het verschil ziet en begrijpt tussen een bocht die je kunt afsnijden en eentje die je niet kunt afsnijden. De essentie is: als ik een bocht neem is dat niet omdat iemand me verteld heeft die te nemen, maar omdat ik weet waar ik heen ga en waarom." Vertel Bach dus niet dat hij moet kijken of een programma wel ‘een responsetijd van 300 milliseconden’ heeft, maar laat hem controleren of het ‘niet irritant traag’ is. Bach houdt zijn gehoor van testers voor dat velen van hen al aan ET doen zonder die term te gebruiken. Ze passen immers soms hun testscripts aan en denken dus na over het nut van hun tests. "Jullie moeten alleen nog even leren erover te praten." ET en het testen met scripts sluiten elkaar dus ook helemaal niet uit en Bach stelt dat in een testproject van enige omvang een combinatie van beide benaderingen geboden is. Voorop staat voor Bach het vormen van een ‘community’ waarin verdere uitwisseling van inzichten over exploratory testen plaats kan vinden. "Ik ben niet uit op volgers; ik wil mede-leiders. Men moet het zelf helemaal geloven en van die mensen kan ik weer leren. Ik nodig iedereen dan ook uit op mijn discussiegroep op Yahoo Groups om mee te discussiëren. Exploratory testen zal in grote organisaties geen voet aan de grond krijgen, tenzij het institutionaliseerbaar is. Daarvoor kun je geen procedures gebruiken, maar wel een trainings- en mentor-programma. Je moet ‘kampioenen hebben die andere mensen kunnen helpen." De manier waarop piloten worden opgeleid - door zeer ervaren collega’s - is voor hem het grote voorbeeld. Harko Robroch, consultant van Riscure, mede-organisator van de testdag, ziet het stempel ‘exploratory testen’ al wel gebruikt worden in Nederland, maar dat zegt nog niet veel. "Sommigen gebruiken het als een commercieel label omdat iemand er ooit iets over gehoord heeft en klanten er niet over kunnen oordelen. Het is de verantwoordelijk van de Nederlandse testwereld om iets te doen aan die communityvorming. Het is voor leveranciers nog te aantrekkelijk om veel testcapaciteit te vermarkten, zonder dat daarbij erg op de vaardigheden van de testers wordt gelet." Waar ET al wel veel gebruikt wordt is in de beveiliging. Bach: "Dat is niet zo gek. Hackers werken immers op de manier waarop ik werk. Die laten hun brein fulltime werken. Je moet dus een net-genoeg-strategie gebruiken. Je kunt niet alles doen, dus je gebruikt heuristiek om te proberen je weg te vinden naar een redelijke oplossing in plaats van de best mogelijke oplossing, die veel te duur wordt. Informatiebeveiligingsmensen zijn zo omdat het werkt. Maar op de rest van de testwereld geldt niet dezelfde evolutionaire druk. Er komt veel projectpolitiek bij kijken." Een heikel punt voor testers is vaak het gebrek aan respect dat ze ervaren van ontwikkelaars en Bach ziet ook wel dat die relatie beter moet. Maar testers moeten ook hun hand in eigen boezem steken. "Het klinkt uit de mond van een tester misschien raar, maar testers verdienen vaak niet het respect dat ze willen. Dat is vooral omdat de meeste testers niet genoeg aan hun vaardigheden werken. En als je erop staat dat alle testeisen vooraf in een document voor je uitgespeld worden, voeg je alleen maar werk toe aan het werk van de ontwikkelaars. Dan ben je een last. Ik zeg zelf tegen ontwikkelaars: ‘mijn taak is jou in een goed daglicht te zetten. Ik vind problemen in jouw werk voordat iemand anders die vindt, zodat jij die kunt oplossen’." Verder past de tester bescheidenheid en moet hij geen hang naar status hebben. "Wees als tester niet de kwaliteitsbewaker, want dan word je gek. Wees de koplampen van het project. Verlicht het pad en de staat van het product. Laat de anderen maar besluiten wat ze ermee doen." Bach zegt zijn best te doen door ontwikkelaars te worden gerespecteerd op hún termen in plaats van te eisen dat hij op zijn eigen termen wordt gerespecteerd. "Zo slaap ik ’s nachts ook beter." Dat zelfs de meest onervaren tester hem kan aftroeven, heeft hij ook geleerd. Daarom is het essentieel dat een testteam zoveel mogelijk verschillende mensen herbergt. "Een tester zonder enkele ervaring zei op zijn tweede werkdag dat hij vast wel een fout zou kunnen vinden die ik niet zou vinden. Hij vond er twee. Een ervan zag ik wel maar herkende ik niet als een probleem. De achtergrond van mensen speelt een grote rol. Een testteam is veel sterker als het bestaat uit mensen die meer van elkaar verschillen. Hoe meer verschillen in temperament, afkomst, sexe, talen, technische achtergrond, hoe meer softwarefouten je vindt. Je verkleint zo de kans dat een fout iedereen op dezelfde manier voor de gek houdt en niet opgemerkt wordt. Hoe meer invalshoeken, hoe beter."