Auteur: Rik Marselis ● evenement@testnet.org ● @rikmarselis
Het testvak wordt voor vol aangezien, nu de tester nog!
Het testvakgebied blijft in ontwikkeling. De zomerperiode geeft mooi de gelegenheid om eens wat naar de grotere verbanden te kijken. Dertig jaar geleden was testen een onderdeel van het IT-vak dat een ontwikkelaar er even bij deed en waar verder nauwelijks over nagedacht werd. Met het ingewikkelder worden van informatiesystemen nam ook het aantal onacceptabele missers toe. En kwam de behoefte om testen apart aandacht te geven.
Midden jaren negentig was de aandacht vooral gericht op ‘hoe maak je testgevallen’. De eerste testmethoden werden beschreven. Rond de eeuwwisseling kreeg het testvak een enorme boost door het jaar 2000 probleem. We deden heel veel testprojecten en daarbij ontstond het besef dat het organiseren van een testproject toch wat anders was dan een ontwikkelproject. Specifieke testmanagementaanpakken hielpen de testmanagers om hun werk beter en efficiënter te doen. En om de testinspanning gevarieerd in te zetten, op basis van het gelopen risico (‘no risk – no test’ werd 10 jaar geleden op TestNet bijeenkomsten geroepen). Daarbij bleek wel gaandeweg dat verschillende testmanagers hun eigen voorkeuren hebben en bij grotere organisaties leidde dat tot een wirwar aan verschillende manieren om het testen te organiseren.
Vanaf 2005 ontstond dan ook de behoefte om testbeleid en testorganisatie apart te benoemen en te regelen. Het testvak was volwassen geworden, auteurs met allerlei achtergronden publiceerden vele boeken, artikelen en papers over het testvak, op deze drie niveaus van aandacht: Testmethode, Testmanagement en Testbeleid. Daarmee is de piramide van functies (operationeel, tactisch en strategisch niveau in de organisatie) helemaal afgedekt. Dus zijn we klaar met het vakgebied, zou je denken. Als je TestNet al een tijdje volgt weet je natuurlijk dat er allerlei interessante deelgebieden van het testvak zijn, zoals testdata, testomgevingen, testtooling en ga zo maar door, die hun eigen aandacht kunnen gebruiken, het vak blijft in ontwikkeling. Maar wat merk ik nu opeens aan alle kanten? Door die aandacht voor testmethoden, aanpakken, beleid en dergelijke is er te weinig nagedacht over degene die het allemaal moet doen; de tester!
Onder invloed van de Agile stroming en de Context Driven subcultuur staat de tester de laatste tijd, terecht, volop in de spotlights. Want waar we traditioneel een groot testteam hadden met allerlei specialisten die samen elk probleem wel voor elkaar boksten, staat de tester er in een Agile team vrijwel alleen voor. Natuurlijk is een Agile team een team, dus heeft de tester collega’s om samen een klus mee te klaren. Maar de tester is wel de enige in het team die van testen zijn vak heeft gemaakt. En dus wordt de tester geacht om op alle testvragen een antwoord te hebben. De tester van vandaag moet dus een multi-specialist zijn. Een hele opgave. En kan iedereen dat zomaar? En wil iedere tester dat zomaar? En is dat eigenlijk wel efficiënt en effectief?
Gelukkig leven we in een tijd waarin alle informatie makkelijk toegankelijk is en contacten met vakgenoten snel zijn gelegd. Via onze vereniging TestNet beschik je over een enorm netwerk van kennis en ervaring. En dat is precies waar we op dit moment zijn beland: middenin de netwerksamenleving waarbij het belangrijk is dat je de fundamenten van je vak beheerst, zodat je een probleem dat zich aandient herkent en je kunt inschatten welke informatie je nodig hebt om het op te lossen. Vervolgens gebruik je de moderne communicatiemogelijkheden om die informatie op te sporen en toe te passen in je eigen situatie. Waarbij we niet moeten vergeten dat grotere organisaties nog steeds baat hebben bij een groepje specialisten die de testers in hun teams ondersteunen op specifieke gebieden zoals testtooling of testdatamanagement. Zo komt het dat de belangrijkste kwaliteit van de tester van vandaag is: de kunst om informatie te zoeken, te beoordelen en precies die elementen toe te passen die in haar/zijn specifieke situatie zorgen voor een efficiënte en effectieve beoordeling van de kwaliteit en risico’s van het testobject. Al die kennis die de afgelopen decennia in boeken is vastgelegd is een mooie basis.
Maar de tester zelf is de enige die het verschil kan maken. Elke tester moet dus continue bewust met haar/zijn vak bezig zijn, continue leren en verbeteren. En zo het respect vergaren dat een professionele tester verdient. Dan wordt ook de tester voor vol aangezien.
Testen is een vak, de tester is de spil waarom het vak draait!
NieuwsMagazine
Rik,
Ik ben het met je eens dat het eigenlijk allemaal om goede testers draait en niet zozeer om methoden en technieken. Het heeft weinig zin om “klikgeiten” aan te nemen waar je ook zelf nadenkende (echte) testers voor had kunnen hebben.
Ik denk dat de kwaliteiten van een tester altijd wel op het vlak van communicatie hebben moeten liggen gezien ze de spil van een team zijn. Immers kunnen zij de klantwens interpreteren en evrtalen naar datgene wat er uiteindelijk ontworpen en gebouwd is. En waar de kennis niet aanwezig is, daar komt communicatie weer om de hoek kijken (het opzoeken van de mensen die deze kennis wel hebben).
Ik denk dat de ontwikkeling van de tester als persoon zelf op dit moment nog belangrijker is dan het handhaven van de tester op papier.
Grt,
Reinder
Rik, prima column weer! zet me wel aan het denken.
Ik vraag me onderhand af of we als testers juist niet meer generalist moeten worden en het specifieke vak van tester aan het vervagen is.
Juist in agile en DevOps teams zie je dat de nadruk van testen meer op de componenttest komt te liggen. Daarbij komen technieken als TDD (dit is een development techniek, geen testen!) steeds meer voor. Deze technieken vragen “test skills” van ontwikkelaars, immers zij zijn degenen die daarmee moeten werken en de testgevallen moeten bedenken.
De voorbeelden die je geeft als specialismen (tooling, testdatamanagement) vind ik nou net geen specialistische testtaken, eerder functioneel en technisch beheer. Ik denk dat we als testers juist veel meer niet-test expertise moeten gaan krijgen en minder moeten denken dat we een apart vak hebben.
Chris,
interessant, jouw reactie zet míj weer aan het denken.
Ik denk dat je twee dingen over het hoofd ziet.
Ten eerste zijn juist de testskills bij componenttesten (of unittesten of whatever de gangbare term op het moment is) onontbeerlijk: testers denken net iets creatiever dan wat degenen die het gemaakt heeft. Sla de handen ineen, denk “no man is an island all by himself” en wees verbaasd over het resultaat.
Ten tweede kunnen testers enorme bijdragen leveren bij gebruikersacceptatietesten.
De specifieke manier van denken en handelen van testers (en ja, dat hebben ze) vragen om een vak apart en niet om een versplintering onder andere vakken.
Martine,
Natuurlijk heb je gelijk dat juist bij het testen van componenten test skills noodzakelijk zijn. Ik ontken ook zeker niet dat testers die skills hebben. Maar is het niet zo dat:
1 – Bij agile (en dus de faco scrum) het accent nog meer komt op testen van componenten – dus eerder accepteren van software?,
2 – de testers de afgelopen decenia zich maar zeer weinig hebben bemoeid met dat testen van componenten? en
3 – de markt (de huidige manier van ontwikkelen van systemen) vraagt om schapen met vijf poten?
Ik merk in de praktijk dat als er testers worden gevraagd, bij de aanvraag een waslijst van niet-test gerelateerde zaken staan zoals Ervaren in SQL, XML, Soap, Java, .Net een hele trits tools en ga zo maar door. En het liefst nog allemaal tegelijk!
We kunnen proberen vol te houden dat testen een vak apart is, de praktijk gaat een andere weg in. Doorbordurend op mijn eerste reactie: de tester wordt meer ontwikkelaar en zal dus niet-test skills moeten aanleren, net zoals de ontwikkelaar steeds meer tester wordt en dus zal moeten leren testen.
Volgens mij denken niet alleen testers creatiever maar doet iedereen dat als hij over het testen van iets denkt. Het nadenken over testen van zaken dwingt je gewoon tot creatiever te zijn. Dat geldt op elk stadium in het process van business analyse tot programmering.
Ja, testen blijft een vak maar of het zo apart moet blijven?
Mooi verhaal, kan me er goed in vinden.
Nog wel een aanvulling, behalve de kennis die een tester nodig heeft, blijft het sociale aspect, de zogenaamde soft-skills, ook een belangrijk punt hierin.
Je kan nog zoveel kennis hebben, maar als je bij de eerste de beste bevinding van je stoel springt en door de gangen gaat lopen roepen dat je een fout hebt gevonden en dat die blokkerend is en dat er dus een Nogo is voor de aankomende release (liefst nog iets met ‘prutsers’ in de zin erbij), dan is de kans nog steeds erg klein dat je voor vol wordt aangezien.
Testen, het blijft een mooi vak.
Misschien beter: test, het blijft een mooi vak in ontwikkeling.
Hmm.
Die ga ik onthouden.
🙂
Helemaal mee eens, Rik! De mens maakt het verschil.