Waarom testers soms worstelen met Agile of Scrum

Een van de meest onbesproken onderwerpen binnen de testwereld zijn de worstelingen, die testers ondervinden, als ze gaan werken in een Agile of Scrum omgeving. Waar kan je als tester tegenaan lopen? En is dit op te lossen?

Ontwikikelaars
Bij Scrum wordt bijna alleen gesproken over ontwikkelaars. Het Scrumteam bestaat uit ontwikkelaars. Verkeerd vertaalt, houdt dit in dat testers geen of slechts gedeeltelijk deel zijn van het ontwikkelteam. Dit kan verschillende gevolgen hebben. Zo heb ik meegemaakt, dat er met testers geen rekening werd gehouden bij het plannen of bespreken van story's. Ook redenaties, dat in een Scrumteam geen testers nodig zijn, kan ik niet helemaal los zien van deze "Scrum = ontwikkelaars" redenatie.

Voor de duidelijkheid: Een Scrum ontwikkelteam bestaat uit ALLE leden, die bijdragen aan een eindproduct. Het verschil is alleen: binnen Scrum wordt niet gekeken of er een lid is dat kan programmeren, een lid dat kan ontwerpen en een lid dat kan testen. Er wordt gekeken of het team kan programmeren, ontwerpen of testen. Alle leden zijn gelijkwaardig en dienen in alle meetings ook gelijkwaardig behandeld te worden.

Planningspoker
Een veelgebruikte techniek is planningspoker. Hierbij worden story's met elkaar vergeleken op basis van complexiteit. En vaak lijkt de nadruk hier te liggen op de complexiteit van de te bouwen code. Testers kunnen hier zelfs zo van overtuigd zijn, dat ze niet echt meedoen met planningspoker. Ze kopiëren gewoon de waardes van anderen. Want wat kunnen zij nu als testers zeggen over de complexiteit? Of er komt een manier om testen apart te pokeren (eerst alleen code door programmeurs, dan alleen testen door testers), want je kan toch niets zeggen over de andere groep?

De kracht van planningspokeren is het uitwisselen van informatie. Juist door de informatie van twee hele verschillende specialisten (zoals programmeur en tester) bij elkaar te nemen, kan je een goed beeld krijgen van de complexiteit. Een tester kan bijvoorbeeld stilstaan bij de raakvlakken met andere processen, waar de programmeur bijvoorbeeld meer kan aangeven over de complexiteit van de aanpassing in de code. Ook is het zo, dat de complexiteit tussen het testen en het programmeren niet vaak grote verschillen heeft. Als iets 2x zo moeilijk is om te bouwen, is het vaak ook 2x zo moeilijk om te testen. En als laatste argument: een goede programmeur is in staat zijn werk te testen en weet daarom ook hoe complex het testen is. En een goede tester weet in grote lijnen hoe complex code aanpassingen zijn, omdat hij/zij hierbij rekening moet houden met de teststrategie. Ja, als team werkelijk aan planningspoker doen is moeilijk, maar als je het lukt, levert het veel op.

Functionele documentatie
De functionele documentatie wordt steeds vaker teruggebracht. Steeds meer informatie wordt mondeling doorgegeven en besproken. Op zich is daar niets mis mee. Het probleem is alleen, dat deze besprekingen niet altijd met alle betrokken leden zijn. Omdat het vaak de ontwikkelaar is, die het eerst aan het werk gaat, is deze vaak ook de eerste, die gaat overleggen. Met iemand, die antwoorden kan geven, dus niet met de tester. Dat is het meest eenvoudig, snel, enz. Deze informatie wordt vervolgens niet of slecht vastgelegd. En de tester krijgt later de taak om deze informatie alsnog te achterhalen.

Overleggen over de functionele werking moeten bij voorkeur minimaal met de programmeur en de tester gevoerd worden. Als dit niet kan, moet de afwezige direct op de hoogte worden gesteld. Bij voorkeur mondeling, anders schriftelijk. En dit moet gebeuren op een waarneembare manier. Dus niet met een wijziging in een stuk bestaande tekst. Maar met een duidelijke "dit is gewijzigd" mededeling.

Het eind van de sprint
Het meest beruchte deel van Scrum voor testers is misschien wel het eind van de sprint. Met de grote vragen:

• Is het testwerk eerlijk verdeeld over de sprint of is het meeste aan het eind?
• Tot wanneer mag het team in de sprint functionaliteit toevoegen?
• Gaan andere leden van het team mee testen of niet?
• Wat doen de teamleden, die niet mee testen, met de rest van hun tijd?

Als de tester pech heeft, leidt deze fase tot veel werk aan het eind van de sprint, door teveel testwerk. Of door de vele begeleiding, die nodig is om anderen ook te laten testen.

Ik heb mijn voorkeuren, maar waar het hier vooral om gaat, is samenwerken. Als je als tester te maken hebt met anderen, die ook testen, moet je als tester ervoor zorgen, dat je hun testwerk vertrouwd. Dit kan door eenvoudig te testen werk het eerst bij anderen neer te leggen of door via testscripts/testcases alvast het belangrijkste voorbereidingswerk te doen. En heb je zelf veel werk aan het eind, bespreek dan hoe je je hier zo goed mogelijk op kan voorbereiden. Bijvoorbeeld door eerder de informatie te krijgen, die nodig is voor de voorbereiding. Waarmee je tijdens de uitvoering tijd kan besparen.

Samenvatting

Scrum en Agile zijn niet tegen testers, al lijkt dat soms wel. Het grote probleem is dat zowel Scrum als Agile uitgaan van een samenwerking tussen alle teamleden, ongeacht specialiteit, functie of discipline. Ondanks de jaren Scrum en Agile merk je dat deze samenwerking nog te vaak tussen alleen programmeurs of alleen testers is. Ik ben hier verantwoordelijk voor en jij bent daar verantwoordelijk voor. Sommige testers denken zelf nog zo. Anderen werken in een team, waar deze gedachte nog aanwezig is. We moeten leren als team te denken. Dus een probleem van een programmeur, is ook het probleem van een tester. En het probleem van een tester, is ook het probleem van een programmeur. Want alle taken, en daarmee alle problemen, zijn de verantwoordelijkheid van het team als geheel. En niet slechts van 1 persoon. Ik hoop dat iedereen, tester of niet, dat ooit eens zal leren.

Agile testen is testen met openheid, eerlijkheid en respect

Agile testen wordt vaak omschreven als een vorm van testen met testautomatisering, exploritory testing of vermindering van testscripts. Maar voor mij gaat het bij Agile testen niet om de middelen, die je als tester wel of niet gebruikt. Agile testen gaat om de samenwerking. De samenwerking met je team, de samenwerking met je manager, de samenwerking met je klant. Een samenwerking, waarin je als tester open, eerlijk en respectvol wil omgaan met alle betrokkenen. En een samenwerking, waarin je wil dat de betrokkenen zich vrij voelen om open en eerlijk tegen jou te zijn.

Wat houdt open, eerlijk en respectvol in voor een tester? Als tester ben je vaak de enige in een Agile team. Het is daarom van belang dat jen binnen je team open en eerlijk leert praten over de problemen en obstakels, waar je als tester tegenaan loopt. Deze zijn namelijk regelmatig voor je andere teamleden onbekend. Je moet leren om te verwoorden, waarom iets belangrijk voor je is.

Bij het maken van bevindingen moet je respectvol met je teamleden omgaan. Het is je doel om als tester de fouten van het team te vinden. Maar de communicatie hierover, moet niet verwijtend overkomen. Als basis moet je een vorm van communicatie kiezen, die ervan uitgaat dat je teamleden goed werk willen opleveren en fouten niet expres maken.

Agile is erg klantgericht. En dat moet Agile testen ook zijn. Het moet als Agile tester je doel zijn om te testen of er een product gebouwd is, waar de klant blij van wordt. En als je werkelijk een goede Agile tester wil zijn, begin je hier al mee bij de eerste bespreking van de wijziging, vaak al voor de bouw begint. Is dit echt wat de klant wil? Hebben we de klant goed begrepen? Als we dit bouwen, heeft dit nadelen voor de klant? Of misschien voor andere klanten?

En als laatste je manager. Hoewel vaak weggelaten in Agile verhalen, weet ik ondertussen dat de manager een van de belangrijkste factoren is in het falen of slagen van een Agile team. Een manager heeft binnen Agile de moeilijke taak om een evenwicht te vinden tussen het team loslaten en het team sturen. Uit ervaring weet ik, dat als je een team teveel loslaat, er zeker in het begin al vrij snel weinig Agile meer over is. Bij tegenvallers valt een team regelmatig terug op het oude bekende. De oude manier van plannen, de oude manier van overleggen, de oude manier van samenwerken. Maar bij teveel sturing, krijg je net zo min een Agile team. Je krijgt een team, dat in naam zelfstandig beslissingen kan nemen, maar in de praktijk doet wat de manager zegt.

Aan dit goede evenwicht kan je bijdragen door met je manager open en eerlijk te communiceren. Zorg ervoor dat je manager op de hoogte is van de belangrijkste problemen rond testen in het team. En het kan vaak ook verstandig zijn hem of haar op de hoogte te brengen van je plan van aanpak om die problemen op te lossen. Maar besef ook, dat je manager soms doelen heeft, die boven een team uitgaan. Zelfs in een Agile team kan een manager je dwingen tot een taak, een handeling, een tool, waar je zelf niet achterstaat. Dat is het moment om ook richting je manager respectvol te blijven. Je kan wel degelijk open en eerlijk vertellen, waarom jij dit eigenlijk niet wil. Maar toon wel respect voor datgene wat je manager wil bereiken. Misschien weet je zelfs wel een alternatief.

Als je dit leest kan openheid, eerlijkheid en respect heel eenvoudig lijken. Maar ik ken genoeg mensen, die open en eerlijk zijn, maar vaak respectloos omgaan met mensen. Hun open en eerlijke opmerkingen kwetsen mensen en schaden daarmee het vertrouwen. En daartegenover zijn er mensen, die proberen altijd respectvol te zijn. Maar zich daarom niet meer vrij voelen open en eerlijk te communiceren. Zeker als tester, met een uitzonderingsrol in het team en de taak om fouten te vinden, is dit evenwicht soms moeilijker dan je zou denken. Kort geleden ging ik zelf de mist in, door iemand in mijn team respectloos te behandelen. Maar weet je wat het heerlijke is van deze drie? Als je iemand respectloos hebt behandelt, kan je dit vaak oplossen door over de oorzaak hiervan open en eerlijk te zijn. En als blijkt dat je niet open en eerlijk genoeg bent geweest, kan je veel ergernis wegnemen, door respectvol te luisteren.

Het belangrijkste voordeel: openheid, eerlijkheid en respect kan je niet echt goed bij jezelf meten. Het is hoe anderen tegen je aankijken. Agile, en daarmee Agile testen, draait om het team en om samenwerking. En is naar mijn mening dan ook beter meetbaar in een beoordeling, die door het team of door alle betrokkenen gegeven moet worden. Niet in zaken, die (hoe belangrijk misschien ook) uiteindelijk niets te maken hebben met communicatie of groei. Alleen maar met "anders werken". En "anders werken" is niet automatisch "Agile werken".

Agile testen draait natuurlijk ook om kwaliteit. Maar als je respectvol omgaat met je klant, met je manager en met je team, kan je niet anders dan de kwaliteit goed bewaken. Je klant en je manager willen een kwalitatief goed product. En je team en je manager wil een kwalitatief goed proces. En met openheid, eerlijkheid en respect kan je binnen het team de kwaliteit bewaken, het proces bewaken, maar ook jezelf bewaken. Zodat anderen van hun fouten kunnen leren, maar jij ook.