Samenwerken is een begrip waar maar weinig mensen moeite mee hebben. Natuurlijk is het belangrijk, het is gewoon gezond verstand en iedereen doet het. Maar in veel testtrajecten is het niet vanzelfsprekend. Althans, wel tussen testers onderling maar zo gauw het gaat over andere disciplines dan klinken er al gauw bezwaren. Maar samenwerken heeft heel veel voordelen, en ook voor traditionele teams. Vanuit mijn ervaring in agile projecten bespreek ik mogelijkheden tot samenwerken die iedere tester in ieder traject zou moeten uitvoeren, of het nu een agile of traditioneel project is. Ik hoor graag jullie eigen ervaringen!
Samenwerken met de ontwerper
Boriz Beizer zei het al jaren geleden: The design isn’t done until the test cases are ready. Wanneer een tester naar specificaties kijkt, interpreteert hij ze vaak heel anders dan de ontwerper zelf of de ontwikkelaar. Dat noemen we bevindingen. Maar iedereen weet dat achteraf constateren en oplossen peperduur is. Daarom is het dus essentieel dat de tester en de ontwerper on speaking terms zijn. De ontwerper beschrijft wat de klant wil en de tester reflecteert daarop hoe het systeemgedrag het beste kan worden omschreven, zodat de ontwikkelaar precies weet wat hij moet programmeren. In de dialoog tussen ontwerper en tester gaat het om inhoud (het goede systeem) en vorm (is het systeem goed). Dat vergt wat van beiden! Het begint natuurlijk met het besef dat er een gezamenlijk belang is dat de disciplines overstijgt. Daarnaast is er een individueel belang: beiden kunnen hun werk beter (lees: effectiever) doen wanneer je met elkaar werkt. Net als in een voetbalteam moet een aanvaller soms meeverdedigen om de wedstrijd te winnen.
Samenwerken met een ontwikkelaar
Veelal zijn ontwikkelaars en testers gekenmerkt als elkaars tegenstanders. Wij zouden onafhankelijk moeten zijn en ons niet laten beïnvloeden. Maar: dan kan een ontwikkelaar ook niet zeker weten of hij zijn werk goed doet. Want wij testers hebben meer informatie dan hij over het testobject, namelijk onze testgevallen. Die vertellen ons heel veel over hoe het systeem werkt, maar waarom delen we dat niet met ontwikkelaars? Dan leveren ze een object op dat in ieder geval aan de kwaliteitseisen voldoet! De ontwikkelaar bouwt het dan in een keer goed, en jij kunt je richten op de échte testgevallen – die testgevallen die de ontwikkelaar niet whitebox kan testen. Win-win dus, want je zult veel minder test-and-fix cycles hebben.
Samenwerken met een gebruiker
Persoonlijk vind ik de acceptatietests altijd het leukst in het testen: in contact komen met de mensen die het systeem daadwerkelijk in hun bedrijfsvoering gaan gebruiken. Vaak krijg je dan een beter beeld over wat ze nu echt nodig hebben en hoe ze het gaan gebruiken. En die informatie kun je ook eerder krijgen! Door al in een vroeg stadium eindgebruikers bij het test- en ontwikkelproces te betrekken krijg je als team (!) meer zicht op wat echt belangrijk is. Misschien kun je niet nieuwe requirements toevoegen, maar je kunt wel laten zien dat je iets doet met het commentaar van gebruikers. Er vindt immers nog bugfixing plaats uit ‘jouw’ testfases, dus het is eenvoudigweg een kwestie van prioriteren. Door met een delegatie van de eindgebruikers te werken voorkom je dat je bestookt wordt met ideeën. Het gaat er immers om het goede systeem goed op te leveren. Vanuit dat perspectief kunnen zeker ervaren eindgebruikers een mooie aanvulling op onze kennis zijn. Jij leert van hen, en zij leren wat van het team over het systeem. Dat is samenwerken!
En… heb ik je kunnen overtuigen van de toegevoegde waarde van samenwerken in het testen?
———————————–
Anko Tijman is werkzaam bij Ordina als testconsultant en Partner Agile Testen.
Anko,
Dat samenwerken loont weten we inderdaad allemaal dat staat inmiddels wel vast. Vroeg genoeg contact hebben prima. Dit is echter je tweede column over samenwerken, heb je voor ons niet wat cijfers? Niet samenwerken versus wel samenwerken, Agile versus waterfall ontwikkelaars versus testers..
Het feit dat je in je eerste zin zegt dat samenwerken loont en dat niemand zal verbazen bevat al het gegeven dat we het allemaal zelf hebben ervaren en dus ook doen.
Mijn punt is eigenlijk volgens mij wordt er prima samengewerkt maar spelen er hele andere krachten waardoor we ons succes inperken.
Ik ben benieuwd naar de cijfers en jou visie hierop…
Andreas,
Mijn punt is: iedereen zegt het, maar we doen het juist vaak *niet*. Enerzijds omdat we niet geleerd hebben hoe het moet vanuit de vakinhoud (vandaar een aantal tips over samenwerken vanuit een multidisciplinaire gedachte) en anderzijds inderdaad omdat er andere krachten in het spel zijn.
Ten diepste gaat het mis omdat het Angelsaksische organisatiemodel wat wij hier hanteren dit niet support. Ieder z’n eigen eiland, zeg maar. Of dat nou afdeling Verkoop of het testteam is… Wil je je organisatie gaan veranderen, dan zul je op andere waarden moeten gaan sturen. Door bijvoorbeeld Samenwerken (waar niemand bezwaar tegen heeft) altijd als driver voor je acties te definieren, jaag je niemand in het harnas en is het duidelijk wat je waarom wilt. Dat doe ik ook :-)
Een leuke quote in dit geheel:
‘The ant is an individual stupid, but collectively intelligent animal. Man is the opposite’. – Karl von Frisch
Daarnaast is er een wezenlijk verschil tussen samen werken en samenwerken ….. In dit kader moeten we dus samen werken aan samenwerken. Denk daar maar eens over na.