In de ideale situatie dragen alle partijen bij aan de kwaliteit van een systeem implementatie- of realisatietraject en hebben ze een gezamenlijk verantwoordelijkheidsgevoel voor de kwaliteit. Ondanks dat een tester zelf geen toevoegingen of wijzigingen in de software kan aanbrengen om op deze manier de kwaliteit te verhogen, kan de tester wel een zeer belangrijke rol spelen in het ontwikkelen van een kwalitatief hoogwaardig product.
De verstandhouding tussen de tester en ontwikkelaar maakt deze kwaliteitsslag echter in veel situaties lastig. Een goed voorbeeld om duidelijk te maken op welke wijze de rol van tester en ontwikkelaar zich in sommige situaties verhoud, is dat van Murdock en B.A. Baracus in het legendarische A-team. Twee totaal verschillende personen als onderdeel van een team. Ze zijn gezamenlijk verantwoordelijk voor één doel en hebben daar beide een aandeel in. Door het verschil in karakter en werkwijze verloopt de samenwerking tussen beiden soms verre van soepel. Stel je voor dat ze altijd elkaars sterke punten konden benutten en effectief communiceerden?
Dit is uiteraard een geënsceneerde en uitvergrote tegenstelling tussen personen maar het typeert de praktijk van iedere dag. Mensen spiegelen collega’s in een professionele omgeving immers aan zichzelf. Afwijkende karakters of handelswijzen worden vaak als bedreiging of afbreukrisico gezien terwijl niet gekeken wordt naar de positieve effecten die diversiteit kan brengen. Dit uit zich zichtbaar bij testers en ontwikkelaars. Het is dan ook belangrijk na te gaan hoe het komt dat de samenwerking tussen beiden partijen niet altijd ideaal verloopt.
Testers versus ontwikkelaars
Een ontwikkel- of implementatietraject staat vaak synoniem voor de wirwar aan lijntjes tussen sturende, uitvoerende en delegerende partijen. Uiteraard bestaat er een gemeenschappelijke doelstelling voor eindgebruikers, analisten, ontwikkelaars en testers maar in de praktijk blijkt toch vaak dat ieder zijn eigen, vaak tegenstrijdige, belangenafweging maakt. Ondanks dat kwaliteit een gemeen goed is en door alle partijen zou moeten worden nagestreefd blijkt vaak een onevenredige verantwoordelijkheid te liggen bij de ontwikkelaar. Ze dragen een groot deel van de last doordat zij verantwoordelijk zijn voor de noodzakelijke vertaling van ontwerp naar een tastbaar product.
Ondanks dat het logisch klinkt en voor de hand ligt dat projectleden in ontwikkeltrajecten elkaar kunnen aanvullen, zien we vaak een kloof tussen verschillende partijen. Met name tussen testers en ontwikkelaars is deze vaak sterk aanwezig. Niet alleen een kloof in het takenpakket, maar ook in de onderlinge verstandhouding. Communicatie en samenwerking met betrekking tot het ontwikkeltraject verloopt hierdoor vaak stroef of is soms zelfs totaal afwezig. Dit heeft zijn weerslag op de uiteindelijke kwaliteit van het product en zeker ook op de efficiëntie in tijd en geld om een bepaald kwaliteitsniveau te behalen.
De literatuur (Pettichord, 2000) over kloofvorming tussen testers en ontwikkelaars leert ons dat hiervoor een aantal mogelijke redenen zijn:
– De ontwikkelaar heeft het idee ‘gecontroleerd' te worden door de tester.
– De tester heeft het idee een ontwikkelaar op fouten te moeten wijzen en deze te stimuleren zijn werk ‘beter' te doen.
– Eergevoel en prestatiedrang gaan voor het gezamenlijke verantwoordelijkheidsgevoel.
– Er is een verschil in focus. De tester focust enerzijds op wat niet werkt en is sceptisch ten aanzien van de kwaliteit van het (eind)product. De ontwikkelaar focust zich op wat wél werkt en gelooft in het (eind)product. Het is een strijd tussen scepsis en geloof.
– Bovendien is er het veel voorkomende probleem van elektronische communicatie (overigens) onmisbaar. Het is haast onmogelijk om iets dat ‘niet werkt', positief te beschrijven middels e-mail of een bevindingen tool. Het klinkt al snel negatief wanneer feedback wordt gegeven en het is dus moeilijk om een positief gevoel over te brengen via elektronische communicatiemiddelen.
Het is verleidelijk en gemakkelijk om in twee kampen te blijven denken en deze problematiek als onderdeel van de relatie tussen tester en ontwikkelaar te zien. Het is echter veel nuttiger en bovendien een uitdaging om in plaats daarvan ook te kijken naar de rol die wij daar als tester in kunnen spelen. Welke opties hebben we als testers om de kloof met ontwikkelaars te verkleinen zonder daarbij enkel en alleen te focussen op ‘ons domein'.
Geen ‘haantjes’
Ten eerste is het belangrijk de verschillen in kennis, werkwijze en persoonlijkheid te accepteren. Het klinkt misschien wat filosofisch maar het is belangrijk te begrijpen op welke punten je van elkaar verschilt. Pas wanneer we inzien waar de sterke punten van overstaande partij liggen is het mogelijk deze te benutten in het ontwikkeltraject en er van beide kanten voordeel mee te doen. Bovendien is het belangrijk dat alle partijen zicht te allen tijde realiseren dat kwaliteit van het eindproduct het gemene goed is. Dit wordt nog vaak overschaduwd door de strijd tussen de 'haantjes', het persoonlijke eergevoel en de prestatiedrang die de overhand krijgen.
Vervolgens komt eigenlijk alles neer op communicatie tussen beide partijen. Er zijn een aantal manieren om de communicatie tussen tester en ontwikkelaar af te dwingen. Hoewel het soms wat kunstmatig kan overkomen is het essentieel de communicatie goed te laten verlopen en waar nodig te stimuleren. Wanneer een tester zonder navraag bevindingen over het werk van een ontwikkelaar inschiet is het niet vreemd dat deze het idee heeft gecontroleerd te worden door de tester. De metrieken ('scorebord journalistiek') die dit oplevert zijn niet bepaald in het voordeel van de ontwikkelaar.
Een stap in de goede richting is een regelmatige validatie van bevindingen bij de ontwikkelaar. Enerzijds geeft dit de ontwikkelaar de kans parate kennis te etaleren door bevindingen af te wijzen of te accepteren. Aan de andere kant kan deze zich in zijn domein bewijzen door een analyse uit te voeren op de bevinding. Op die manier wordt het trekken van een conclusie, dat iets afwijkt van de specificaties of niet voldoet aan de business requirements, ook eens aan de ontwikkelaar zelf gelaten.
A-team versie 2.0
Zoals we eerder aandroegen kunnen we de relatie tussen testers en ontwikkelaars vergelijken met de relatie tussen B.A. en Murdock van het A-team. B.A. en Murdock hebben echter ook momenten waarop zij elkaar perfect aanvullen en van elkaars krachten gebruik maken. Denk eens aan de talloze keren dat ze als één team een onoverwinnelijk pantservoertuig bouwden. En dat alles met behulp van een lasapparaat, staalplaten, tandenstokers en een dosis vereende inspanning. Tijdens deze scènes werd nagenoeg nooit ingezoomd op gezichten, maar altijd op de handen van de personages. Kortom het inzoomen op wat iemand kan en niet wie diegene is of hoe diegene verschilt van de ander!
Dit betekent niet dat men niet kritisch mag zijn richting anderen of hun werk. De kracht van een tester komt deels voort uit het feit dat hij sceptisch is. Door kritisch te zijn in een ontwikkeltraject kan een constructieve bijdrage geleverd worden aan het verhogen van de kwaliteit. Het is echter belangrijk een positieve houding te behouden ten aanzien van andere partijen. Scepsis mag niet doorslaan in negativiteit! Dit heeft tenslotte zijn weerslag op de relatie met de ontwikkelaar. Leg ook eens de focus op wat wel werkt, positiviteit!
Computable-expert René de Jong heeft deze opinie geschreven in samenwerking met Giel Coomans, test specialist bij Identify.
In de serie het A-team werd B.A. (het haantje) altijd verdoofd omdat hij vliegangst had. En altijd was het eerste plan van Hannibal gedoemd te mislukken waarna plan B ze uit de penarie hielp. Referentie naar kinderserie uit de jaren 80 lijkt me dus niet helemaal passend.
leuke vergelijking van een beetje cliche probleem wat in mijn ervaring eigenlijk alleen maar te maken heeft met de sfeer op een afdeling. Een goede sfeer ‘opent’ de communicatielijntjes.
Korte samenvatting: Tester en ontwikkelaar: HAAL JE EGO UIT HET WERK !
Erg leuk stuk om (weer) te lezen.
Wel richt dit stuk zich voornamelijk op de testuitvoering en de bevindingen.
Het probleem richt zich al bij het testproces. Zo is het testplan soms voor ontwikkelaars een ellenlang geneuzel over iets wat zich in de praktijk ‘toch’ niet voordoet. En dan de wijze van testgevallen aanmaken. Dat gebeurt dan op een erg omslachtige wijze (logische testgevallen, fysieke testgevallen en met een beetje pech ook nog een testscript). En dan nog die onzintesten. Controleren of foutsituaties goed gaan? Er gaat niets fout. En als het toch fout nou jammer dan, had het niet fout moeten gaan. Toch? En dan al die troelala er om heen. De applicatie hoeft in de kern maar een paar dingen te doen. Gaan die testers zich richten op allerhande rapportjes die eruit moeten komen. Alsof ze die rapportjes gaan lezen of begrijpen! Of op schermen die het allang doen, maar er nog niet zo mooi uitzien. Tjonge wat wordt daarmee de kwaliteit verhoogd zeg!
Tja, in TMap ‘Blauw’ werd hier al voor gewaarschuwd. En vele jaren later lijkt, althans op mijn projecten de klok nog volledig te hebben stil gestaan.
Wat tips uit mijn ervaringswereld:
Het kost wat, maar levert heel veel op daar waar het gaat om wederzijdse begripsvorming:
Al je ontwikkelaars op bijv. ISTQB foundation training sturen. Hiermee wordt een stuk meer begrip gekweekt bij de ontwikkelaars daar waar het gaat om het fenomeen testen.
Wat ook kan helpen: zorg dat de ontwikkelaars en testers samen de specs lezen. De één interpreteert het voor het maken, de ander voor het testen. Doordat ze samen hierover discussiëren wordt al snel duidelijk wat er nu gemaakt en getest moet worden. Hebben ze beiden een verschillende interpretatie van de specs, dan is deze dus blijkbaar niet eenduidig of helder.
Zorg daarnaast ook dat je duidelijke regels hebt over het schrijven van probleem-rapportages (en ook de afhandeling hiervan). Zorg dat het op feiten gebaseerd is, en ten opzichte van welke specificatie er een afwijking geconstateerd is. Zorg daarnaast dat er geen emotie in voorkomt, en vermijd suggestieve woorden (die knop werkt alweer niet, het probleem is nog steeds niet goed opgelost) Dit voorkomt veel discussie, en onderlinge irritatie.
Ook de opmerking van Aldo is belangrijk: laat je ego’s eens varen. Je probeert met elkaar een goed product te maken. Het idee is dat je elkaar versterkt in de opzet ontwikkelaar-tester. Wanneer je, zeker als ontwikkelaar, voelt dat je gecontroleerd of aangevallen wordt, moet je eens bij jezelf te rade hoe dat komt. Maak er een sport van dat ze niets kunnen vinden in jouw deel van de code, dat is veel leuker.
Ik maak in mijn praktijk zowel teams mee waarin er tegenstellingen tussen testers en ontwikkelaars, maar ook waar ze intensief samenwerken en elkaar juist versterken. De cultuur binnen de teams, en van de organisatie speelt vaak een belangrijke rol. Een open cultuur waarin mensen elkaar vertrouwen, respect voor elkaar en voor elkaars bijdrage hebben, en waarin er waardering is voor samenwerking maakt het verschil.
Zo’n cultuur kun je samen maken, mits je er regelmatig tijd en aandacht aan geeft, en zelf het goede voorbeeld geeft. Mijn ervaring is dat Agile teams hier vaak bewuster mee bezig zijn. Een agile coach benoemd en bespreekt cultuuraspecten, communicatie en samenwerking regelmatig met de betrokkenen, en zorgt daarmee voor een continue verbetering van de performance. En maakt en passant het werken ook leuker voor alle betrokkenen, wat bijdraagt aan de motivatie en teamspirit!
Voorbeelden hiervan zijn er volop, dus niet meer praten, maar gewoon doen!