Aan het begin van mijn carrière werd ik in twee maanden klaargestoomd voor het testvak: dit bestond voornamelijk uit het TMap boek uit het hoofd leren en het certificaat halen. Toen ik dat certificaat binnen had, was ik klaar om als tester de markt te betreden. Nu, 5 jaar verder, heb ik ervaring met het schrijven van een testframework in C#, en bestaan mijn dagelijkse werkzaamheden voornamelijk uit het maken van systeemtesten in Java. Er is voor mij veel veranderd in de afgelopen jaren.
Maar niet alleen voor mij. Ik hoef alleen maar naar onze eigen Academy te kijken waarin we cursussen ‘Java voor testers’ en ‘Javascript voor testers’ aanbieden. En deze cursussen worden goed bezocht. Uiteraard zal ik als Praegustator wijzen op de kwaliteit die wij onder andere in onze cursussen leveren, maar er is ook veel vraag naar uit de markt. Een interessante ontwikkeling.
Als ik het TMap boek van 5 jaar geleden erop nasla, wordt er gesproken over het ontwikkelteam en het testteam. De waterval was de “hoofdstroom” waarop softwareontwikkeling dreef. Nu valt te beargumenteren dat dit 5 jaar geleden al oud nieuws was: maar dat is wat me door een voornaam testbedrijf als de waarheid werd geleerd. Er is blijkbaar het een en ander veranderd. Testers moeten technischer worden: ze moeten tegenwoordig blijkbaar weten wat een ontwikkelaar doet.
Nu slik ik dit persoonlijk als zoete koek: voordat ik testland betrad, had ik al enige jaren ervaring met programmeren. In mijn opleiding heb ik 4 of 5 cursussen gehad van een half jaar waarin mij het programmeervak werd bijgebracht. Kunnen programmeren als tester in een agile team heeft enorm veel voordelen: Testen kunnen technischer opgezet worden, het begrip tussen ontwikkelaar en tester neemt toe, en op stille testmomenten kan de tester zich wellicht wagen aan het oplossen van een bug. Alleen maar voordelen dus?
Nou, nee. Het risico van deze denkwijze is dat de tester zich steeds meer gaat gedragen als een ontwikkelaar. De balans verschuift van een focus op softwarekwaliteit naar een focus op softwarelevering. De tester moet het team leren de vraag te stellen: Is het echt goed genoeg wat we nu leveren? Daarnaast komt bij de tester de focus te liggen bij de techniek en dus minder op de functionaliteit. De blackbox die getest werd, wordt geopend en begrip van de inhoud brengt inlevingsvermogen in wat de maker gedaan heeft. En dat leidt mogelijk af van het uiteindelijke functionele doel.
Een tester zal dus veel baat hebben bij begrijpen wat een ontwikkelaar doet; maar dat is niet geheel zonder risico’s. Ik ben ervan overtuigd dat de tester, die zich kan inleven in de (eind)gebruikers, die de functionele eisen scherp heeft en staat voor kwaliteit, net zo waardevol is als de tester die als techneut vrolijk mee code aan het schrijven is.
En net zoals je na 2 maanden TMap leren geen volwaardig tester bent (wat was ik naïef toen), word je geen techneut na 4 avonden Java leren (al zijn onze cursussen een goede start!). Zowel programmeren als testen is een vak waar je jaren ervaring in moet opdoen voordat het geleerd is. En niet elk vak is voor iedereen. Ik denk dat we meer techneuten in testland nodig hebben; maar dat maakt de functionele testexpertise zeker niet overbodig.
Vijf jaar geleden werd ik in twee maanden klaargestoomd voor het testvak. En wat de technische testoplossingen ook zijn; ik probeer wat ik geleerd heb in die twee maanden niet te vergeten. Want wat ik ook doe in mijn werk; op de eerste plaats ben ik een tester. Schoenmaker, blijf bij je leest!
