Kritiek leveren behoort onvermijdelijk tot het takenpakket van testers. De manier waarop dat gebeurt, kan nog wel wat aandacht gebruiken, vindt Rik Teuben van detacheringsbureau VX Company.
De techniek is belangrijk, maar de manier waarop de tester met zijn collega's omgaat, verdient minstens evenveel aandacht. Volgens Rik Teuben, technisch manager testing bij detacheerder VX Company, moet de tester zich meer verdiepen in de menselijke kant van het testvak. 'Het gaat om communicatie, argumentatie en het verwerken van informatie.'
De tester zit in een lastige positie, vindt Teuben. Niet alleen omdat het testvak niet altijd even serieus genomen wordt, maar ook omdat het leveren en aannemen van kritiek niet makkelijk zou zijn. "De tester wordt geacht feedback te geven op een product dat nog te wensen overlaat, maar mag ook weer niet te kritisch zijn", aldus Teuben, die sinds 1991 in het testvak zit. "Het is verdraaid lastig een goede tester te zijn en het is dan ook niet verwonderlijk dat niet alle testers in staat zijn op een goede manier kritiek te leveren. Dat is niet bedoeld als verwijt; het trainingsaanbod richt zich vooral op vakkundigheid en niet op communicatie tijdens het testen."
Kritisch bekijken
Volgens de technisch manager testing is het daardoor voor veel testers een uitdaging te blijven geloven in hun werk. Net als de programmeur wil de tester een goed eindproduct leveren, maar om dat te bereiken, moet hij dat product eerst kritisch bekijken. Logisch, zegt Teuben, 'maar je moet er wel tegenkunnen'. Om de kans op een goede samenwerking te vergroten, zou de tester zich meer moeten richten op de verbetering van het testproces en de effectiviteit en de doeltreffendheid ervan.
De afgelopen jaren is daar weinig aandacht aan besteed, aldus VX Company's manager. Teuben: "De testwereld heeft zich voornamelijk gericht op procesverbetering en toolondersteuning en zich onvoldoende bekommerd om de effectiviteit van de testers zelf. Daardoor is de effectiviteit van het testen de laatste decennia fors verbeterd, maar is de aandacht voor de invloed die testers zelf kunnen hebben, achtergebleven."
Communicatie
Communicatie zou een belangrijk aandachtspunt zijn. Voor ict'ers in het algemeen, maar voor de tester misschien nog wel meer. "Die moet feedback geven, argumenteren en veel informatie verwerken." Als voorbeeld noemt Teuben het testproces dat in het begin formeel is, maar later vaak een informeler karakter krijgt. "Daarmee moet je rekening houden", aldus Teuben. "Naarmate het proces vordert, moet je als tester bijvoorbeeld meer rekening houden met de gevoelens van de mensen met wie je werkt. Doordat de tester kritiek moet leveren, heeft hij ook te maken met emoties."
De tester zou daarom moeten leren hoe hij positiever kan zijn in zijn communicatie. Teuben: "Hij moet vechten vóór kwaliteit, in plaats van tégen een slechte programmeur."
Hoe ga jij hiermee om?
Ben jij juist een held in het geven van feedback? Of kan je nog wel wat lessen gebruiken? Reageer!
In mijn beleving hebben veel testers hun vakgebied op een voetstuk geplaatst en schatten zij het belang van hun activiteiten en bijdrage in het ontwikkelproces veel te hoog in.
Als een groot aantal testers eens zou leren om zichzelf wat bescheidener op te stellen is er al heel veel gewonnen naar mijn mening.
Helaas is de praktijk dat er nog heel veel fouten gemaakt worden in de ontwikkeling van software (in requirements, ontwerpen en uiteraard in de software zelf). Ik weet niet precies wat Frans wil zeggen met het voetstuk, maar testen is een essentieel onderdeel van het ontwikkelproces. Niet belangrijker dan alle andere onderdelen, maar wel essentieel.
Ik herken de situatie die Frans schetst niet. Waarom zou een tester zich bescheidener moeten opstellen? Wellicht heb je slechte ervaringen met enkele testers? In veel gevallen zou een tester zelfs vaker op zijn strepen moeten gaan staan. Wel, zoals Rik hierboven terecht schetst, met enige takt en aandacht voor de relatie!
Er staat in het artikel: “Net als de programmeur wil de tester een goed eindproduct leveren”. Volgens mij is naast goede communicatie ook goede teamgeest en onderling vertrouwen heel belangrijk. Als programmeur en tester elkaar vertrouwen geven en van elkaar weten dat ze alletwee hetzelfde willen, dan kan zelfs een misstap in de communicatie makkelijk rechtgezet worden.
De tester doet zijn bevindingen niet agresief of defensief maar gewoon assertief.
quote: Hij moet vechten v??r kwaliteit, in plaats van t?gen een slechte programmeur.”
Dit klopt helemaal, maar dat een “”slechte” programmeur zich aangevallen voelt heeft niets te maken met de tester maar eerder de constatering dat die werkelijk een slechte programmeur is. Een goede programmeur vecht namelijk ook voor kwaliteit
Natuurlijk zijn goede onderlinge relaties in een team van groot belang en kan dit ook leiden tot synergie, maar op zich zou het bespreken van bevindingen onpersoonlijk moet zijn. Het systeem voldoet wel of niet aan de specificaties. Ik zie niet in waarom er dan gevochten moet worden.
Wat echter ook wel eens voorkomt is dat testers op basis van hun eigen visie bevindingen opvoeren, die los staan van de beschreven functionaliteit.
Om dat soort zaken te voorkomen, maar vooral om tot betere producten, bespreek ik direct al vroege versies van het FO met de testers. Al voordat deze door de business geaccordeerd zijn. Win-win-situatie: beter FO, minder “onterechte” bevindingen.
Definieer “een eigen visie”. Het interpreteren van functionaliteit naar eigen inzicht? Dat levert meningsverschillen op. Maar zijn die meningsverschillen nutteloos of ongewenst? Ik denk het niet. Het helpt wellicht een andere denkwijze of een andere oplossing. Voor hetzelfde geldt heeft de persoon wel een efficientere en effectievere manier om iets aan te pakken. Of gewoon een onduidelijkheid in het FO geconstateerd. Het zou zonde zijn om die manier dan te laten liggen. Ik heb liever die “creatieve zeikerd” in het team dan iemand die alleen maar braaf het FO napluist.
Ik heb overigens nog geen enkel project meegemaakt waarin de requirements niet meer wijzigde nadat er een klap op de specs gegeven was. Ook al heb je de producten nog zo grondig doorgespit als maar kan, gewijzigde inzichten blijf je houden. Moet een tester dan kritisch blijven? Natuurlijk! Moet een tester dan taktisch blijven? Natuurlijk… net zoals ieder ander projectlid!
Men hoeft het niet altijd met elkaar eens te zijn. Zolang men het maar constructief oplost. Wanneer een tester nieuw is binnen een project zal dit anders gaan dan wanneer de tester al wat langer binnen een project zit. Geleidelijk verandert ook de manier van communiceren. In het begin wat formeler en later wat informeler. Dit verhoogt alleen maar de teamspirit.
Laat mij maar die constructieve “creatieve zeikerd” zijn die af en toe even voet bij stuk houdt 😉
Dat is zeker waar, maar hoe goed, punctueel, terughoudend en met beleid feedback en vooral kritiek ook wordt gegeven. Voor ‘de andere kant’ kan het soms de aanleiding zijn om te escaleren.
Niet het geven van kritiek is dan de moeilijke factor maar metname het staande blijven wanneer er op deze kritiek wordt geREaggeerd wordt dan het moeilijke.
Als tester moet je soms over een enorm groot incasseringsvermogen beschikken. Bouwers die beweren dat het toch goed gebouwd is, of dat er verkeerd getest is of te de eis verkeerd (dubbelzinnig) wordt opgevat, dat blijven de moeilijke aspecten.
Niet het geven van de juiste feedback op de juiste manier is altijd het hete hangijzer.
Omgang met emoties, heldere communicatie inderdaad, overtuigingskracht, doorzettingsvermogen, flexibiliteit, feitelijkheid. Veel van deze eigenschappen voor een goede tester komen neer op 1 ding. >>(werk/test)ERVARING<< een project kan ook sterk van informeel naar formeler gaan, maar dat heeft te maken met de branche waarin je werkzaam bent en.. het moment waarop je test (plek waarin je je bevindt in het V-model) mijn ervaring: hoe meer richting de Acceptatie kant (rechtsboven van V model des te formeler het wordt). zo ook: hoe meer er te maken is met levenskritische factoren, hoe kritischer het wordt, des te formeler het wordt.
Sommige mensen zullen dit artikel lezen als ‘wanneer testers beter zouden communiceren zou er veel beter software gebouwd worden’, en dat zou jammer zijn. Het roept vragen op waar we als testers ons mee bezig moeten houden omdat je als professional altijd beter wil, maar als ik zie dat de eerste reaktie die komt, is dat testers zichzelf te belangrijk vinden en zich bescheidener op zouden moeten stellen…ik lees dit als: ‘als de uren voor het testen nu gewoon aan de programeurs werden gegeven zou alles goed komen’.
Dan wordt ik weer bevestigd in mijn gevoel dat er teveel mensen in de IT rondlopen die software ontwikkeling en programeren als identiek zien. Zolang dat blijft kunnen testers op hun hoofd staan, maar zal het efect beperkt zijn.
automated_tester…
Daar ben ik het helemaal mee eens! Software ontwikkeling en programmeren zijn 2 verschillende zaken.
Programmeurs moeten eens inzien dat hun kennis ligt bij het bedenken van hoe iets zou moeten werken, maar niet bij hoe iets fout zou kunnen gaan.
Ontwikkelaars moeten eens gaan inzien dat een project met software testen in eerste instantie duurder lijkt maar op langere termijn vaak meer winst oplevert.
Kortom: testen is voor nerdo’s.