Ik heb op het najaarsevent van Testnet van de Testnet Werkgroep Test Tool Management een interessante workshop gevolgt. De titel stond me vooraf al aan, en die werd ook waargemaakt.
Deze werkgroep heeft ook een Whitepaper gepubliceerd over Test Tool Management. Zo kun je er desgewenst zelf ook dieper induiken.
Om je een beetje op gang te helpen bij dezen mijn ervaring van de workshop.
Bij grotere klanten merk je vaak dat er veel test tools in gebruik zijn. Diverse teams gebruiken de tools die zij fijn vinden en als je veel teams hebt, heb je dus vaak ook veel verschillende test tools.
Sommige tools zijn gratis, maar andere zijn wel betaald.
Dit alles kan zorgen voor te veel kosten en te beperkte kennisdeling tussen verschillende teams.
Om dit op te lossen, kan het helpen om te kijken naar de testbehoefte, en daarna pas de juiste tools daarbij te selecteren. Dit i.p.v. te kijken naar welke tools de tester ervaring mee heeft en die te kiezen. In deze 2e situatie krijg je voor veel verschillende teams ook veel verschillende tools.
Je moet je als test consultant ook goed realiseren dat je inzet eindig is en vaak korter dan het gebruik van een tool. Na jou moet de rest van het team en/of je opvolgende tester er mee verder kunnen. Je bent vervangbaar en zult ooit vervangen worden.
Daarnaast zou je als test professional ook overweg moeten kunnen met meerdere tools. Een tool is maar een stuk gereedschap. Jij bent de professional die de klus komt klaren, dat moet je met verschillende tools kunnen doen als goede test consultant.
Aan de hand van 2 casussen werden we gedwongen eerst na te denken wat in die situaties de Behoeftes waren. Daarna gingen we bepalen wat de Requirements waren die hierbij hoorde. Vervolgens bepaalde we de Aanpak en als laatste wat er getoetst moet worden om te bepalen of de pilot voor tool selectie geslaagd is. We volgde dus een net iets andere volgorde dan 1, 2, 3, 4. Je kunt ook eerst met de Aanpak en dan met de requirements beginnen, daar werden we vrij in gelaten.
Eén van de tips die me bij is gebreven is: Mocht je beginnen met het schrijven van een test strategie, neem daar dan ook de test tool keuze in mee. En dus niet welke tool je kiest, maar welk proces je gaat doorlopen om de juiste tool te selecteren. Het begint bij een juiste procedure gericht op behoefte, niet gericht op wie welke tool al kent.
Ik heb zelf bij een vorige klant een tool selectie gedaan, waarbij we ook goed hebben gekeken naar hoe goed de verschillende tools gesupport werden door o.a. de community, waarbij we ook onderzochten hoe recent die tool nog gesupport werd. We maakte daar toen gebruik van Fitnesse. Die leeg een grote community te hebben, maar de meeste berichten die er op fora over gingen waren meer dan 3 jaar oud. Dat voelde als vergane glorie, waardoor we dus ook niet voor Fitnesse hebben gekozen.
Daarbij moet je ook rekening houden met of je de community wel kunt raadplegen bij de klant. Als je bijvoorbeeld bij de Politie of de AIVD een tool selectie doet, dan zul je geen gebruik kunnen maken van de community. Dan kan het een slimmere keuze zijn om te gaan voor een tool waar een grote leverancier achter staat die de juiste support kan leveren.
Ook bij het aannamebeleid moet je rekening houden met welke tools mensen kennen, maar belangrijker nog, hoe goed kunnen mensen zich nieuwe tools eigen maken. Zoals Darwin het zo mooi heeft gezegd: It is not the strongest of the species that survives, nor the most intelligent; it is the one most adaptable to change.
Wie kan zich goed aanpassen naar het gebruik van de tools die jij nu gebruikt en de tools die andere teams bij jullie gebruiken en de tools die je in de nabije toekomst gaat gebruiken?
Kennisnieuwsbrief november 2026
Frontmania '26: een tester in het hol van de leeuw (ontwikkelaar)
