Het testeiland - Veilig van de Agile eisenwereld

Als tester werk je in de Agile wereld in een Agile team. Of twee of drie of vier. Of soms zelfs in nul teams en je bent adviseur. Je doet je werk in een rol, neem bijvoorbeeld functioneel tester. Of juist in meerdere rollen Je moet kunnen programmeren. Of je moet niet willen programmeren. Je moet andere testvaardigheden hebben, zoals performance testen, keten testen. Of je moet dit vooral aan anderen overlaten. Ik merk dat de rol van tester nu per team en per bedrijf erg sterk kan verschillen. En daarmee ook de eisen waaraan je moet voldoen. Wat is het dan heerlijk als je kan zeggen: "Ik ben functioneel tester van applicatie A, dus wat ik doe is applicatie A functioneel testen. Niets meer en niets minder" Lekker veilig op je testeiland. Wel zo duidelijk!

Ik ben zelf ook van mening dat de invulling van de rol van tester in de Agile wereld een stuk duidelijker kan. Tester is niet de meest eenvoudige rol in een Agile team. Het werk is niet altijd dagvullend. Of is meer dan dagvullend. Voor elk team een tester is niet in elk bedrijf mogelijk en twee vaak al helemaal niet. Ook bij Agile komt het vaak voor dat het meeste testwerk aan het eind ligt, de werkverdeling evenwichtig verdelen blijft moeilijk. En daarnaast heb je nog het terechte streven naar onafhankelijkheid van de tester, onder de noemer "Test niet je eigen werk". Als je in zo'n situatie je testeiland hebt gevonden, blijf je daar het liefst eeuwig op wonen.

Hoe de rol van tester beschreven kan worden, er zijn eerlijk gezegd veel ideeën over. Ik heb zelf mijn eigen ideeën, te splitsen in twee onderdelen: je rol en je kennis. Om te beginnen met je rol: naar mijn mening vervul je die rol maar in maximaal één scrumteam. Je bent in maximaal één scrumteam actief als tester, bij andere teams kan je wel betrokken zijn in een adviserende of begeleidende rol. Dit is vooral om conflicterende belangen te voorkomen. Als twee teams allebei je hulp nodig hebben om op tijd het werk af te ronden en je hebt daar de tijd niet voor, wordt je een impediment. Dan wordt het een situatie "welk team is het belangrijkste". Een situatie waar je niet in wil komen, want teams moeten zonder afhankelijkheid van elkaar hun werk op tijd kunnen afronden.

Ook in een adviserende of begeleidende rol moet je daarom geen impediment kunnen worden. Bij deze rol hoort daarom bij voorkeur geen uitvoerend werk, maar zeker geen uitvoerend testwerk. Adviserend heeft daarom de voorkeur. Maar als je specifieke kennis hebt, die het team nodig heeft, dan moet het werk vooral in de testvoorbereiding of testautomatisering liggen. Testscripts schrijven, die vervolgens binnen het team op het door hun gewenste moment uitgevoerd kunnen worden. Testwerk automatiseren, wat vervolgens binnen het team op het door hun gewenste moment uitgevoerd kan worden.

Wat kennis betreft moet het bij jou en je team liggen hoe jullie daarmee omgaan. Je moet in een Agile team starten met één bepaalde specialiteit, vaak functioneel of technsich tester. Je moet daar als basis beginnen met de kennis die voor die specialiteit nodig is. Dat is je testeiland. Datgene waar het team altijd op terug kan vallen en jijzelf ook.

Maar vervolgens moet je bereid zijn ook andere kennis op te doen of in de praktijk te brengen. En het Agile team moet bereid zijn om te kijken naar de beste oplossing voor de gevraagde kennis. Als je in een team bijvoorbeeld geen performancetester hebt, kan deze taak zowel door een tester als door een programmeur uitgevoerd worden. Het is maar net wie het meest geschikt is. De programmeur heeft bijvoorbeeld weinig werk in zijn specialisatie. Of de tester heeft eerdere ervaring met performance testen. Dit kan bekeken worden tijdens het opstellen van de planning. Of besproken worden bij een evaluatie. Wat het beste bij het team past, als je er maar regelmatig naar kijkt. Wanneer die betreffende programmeur of tester vervolgens uit het team gaat, houdt dit niet in dat de nieuwe programmeur of tester automatisch ook de performancetest moet uitvoeren. De situatie is anders, dus het team moet opnieuw kijken wat de beste oplossing is.

De beste oplossing kan ook zijn dat er leertijd gepland moet worden tijdens de planning. Tijd waarin een teamlid, bijvoorbeeld een tester, nieuwe kennis van bijvoorbeeld een tool opbouwt. Zo kan het best dat je als tester leert om te programmeren, bijvoorbeeld om Unit testen te schrijven. En misschien zelfs om stukjes applicatie te bouwen. Hier moet je mee oppassen, maar moet je zeker niet volledig tegenhouden. Wat in zo'n situatie belangrijk is, is dat er iemand anders in het team geschikt is om het door jou gebouwde werk te testen.

Het belangrijkste is dat het bedrijf niet teveel bepaalt welke rollen en kennis jij binnen een Agile team moet hebben. En bereid is om mensen de tijd te geven zich andere rollen en kennis eigen te maken, als het Agile team hierdoor effectiever kan gaan werken. Het team zelf en alle teamleden los, dus ook de tester, moeten bereid zijn nieuwe kennis op te doen. Ook als deze niet direct in hun specialiteit of rol valt. De beste momenten om hierbij stil te staan zijn planningen en evaluaties. Maar het allerbelangrijkste is en blijft om je niet terug te trekken op je (test)eiland. Hoe verleidelijk en veilig dat soms ook is.