Alleen in een team

Als tester ben je met enige regelmaat de enige tester in een team. Dit geeft soms communicatieproblemen, vooral als het gaat om problemen, waar je als tester tegenaan loopt. Je bent de enige met het probleem. Daarnaast begrijpen anderen in het team niet altijd hoe belangrijk of groot een probleem is, als ze het probleem al begrijpen.

Scrum of Agile werkt op dat gebied ook niet altijd mee. Het team staat centraal, dus problemen van een individu kunnen daardoor minder belangrijk worden. Zowel de retrospective als een backlog refinement zijn voornamelijk bedoeld voor communicatie, die voor het hele team van belang is. Niet alleen voor jou als tester.

Deze situatie mag en moet niet inhouden, dat er voor jouw problemen geen plaats is. Tegelijkertijd is het ook niet de bedoeling dat jij "de uitzondering in de groep" wordt. Oftewel de persoon, die gewoon geloofd moet worden als het om problemen gaat. Terwijl de rest van de groep enige overtuigende argumenten moet hebben. Hoe pak je dit aan?

Gebruik teamargumenten

Als het mogelijk is, gebruik dan geen argumenten, die alleen van toepassing zijn op testen. Zeg niet "Dit maakt het voor mij moeilijker om te testen". Zeg "Door dit probleem kan ik minder stories in de sprint testen". Argumenten rond "meer testen in de sprint", "sneller testen in de sprint", "betere kwaliteit van het op te leveren product" of rond andere teamdoelen werken beter dan argumenten, die alleen jou als tester treffen.

Gebruik concrete cijfers

Omdat niet-testers vaak moeite hebben om zich in testproblemen te verplaatsen, kan het zeker handig zijn om te spreken in concrete cijfers. Denk hierbij aan voorbeelden als 

• Als we dit probleem oplossen, kan de test van 4 uur terug gebracht worden naar 2 uur
• Wanneer we dit anders aanpakken, kan ik zeker 25% meer stories in de sprint testen
• Dit probleem kost mij elke dag zeker een uur

Gebruik testargumenten in 1-op-1 gesprekken

Soms is er gewoon geen teamargument. En zijn er geen overtuigende concrete cijfers te maken. Dit kunnen bijvoorbeeld veelvoorkomende, kleine problemen zijn, die je steeds opnieuw 10 minuten kosten. 10 minuten, die je niet kan missen, als je net geconcentreerd met iets belangrijks bezig bent. Maar een tijdsbesteding, die nou niet direct een team kan overtuigen. Of een communicatie, die niet lekker loopt, waardoor je iets 3 x moet vragen, in plaats van 1 x. Niet dat het veel tijd kost, maar het is wel iets wat je steeds in de gaten moet houden. Wat een probleem kan zijn, als je het drukker krijgt.

In elk team zijn mensen, waarmee je over testen kan praten. Vaak de Scrummaster of een teamleider. Maar er zijn in elk team ook mensen, die geïnteresseerd zijn in een goede samenwerking, tevreden collega's, kwaliteit van een product of zelfs in testen. Afhankelijk van het onderwerp kan je je probleem met zo'n persoon bespreken. Dit kan zijn om te kijken hoe je het team kan overtuigen. Maar een concrete oplossing kan ook het resultaat zijn.

Besef ook dat het overtuigen van het team niet altijd nodig is. Veel weerstand tegen het bespreken van "niet belangrijke" problemen, komt doordat het bespreken tijd kost. En niet iedereen kan of wil tijd steken in problemen, die voor hem of haar niet van belang zijn. Als je echter met een concreet voorstel komt, dat je team niet of nauwelijks tijd kost, zal je vaak geen tegenwerking tegenkomen.

Benoem je problemen, ook als je ze niet bespreekt

De neiging kan zijn om je problemen voor je team te verzwijgen. Ze hebben er toch geen aandacht voor. Hoe begrijpelijk ook, dit is niet verstandig. Zorg ervoor dat je team op de hoogte is van de belangrijkste problemen, waar jij als tester tegenaan loopt. Maar geef tegelijkertijd aan, dat dit wat jou betreft niet meteen opgelost hoeft te worden. Bespreken van een oplossing kan op een ander moment.

Het benoemen van onbegrepen problemen kan een afstand tussen jou en het team creëren. Maar het verzwijgen van problemen doet dat met 100% zekerheid. Je zal 100% zeker nooit een oplossing vinden en dat feit kan zeker bij jou spanning gaan veroorzaken. Maken dat je niet lekker werkt in het team. En dat zal alsnog een afstand creëren tussen jou en je team. 

Blijf onderdeel van het team, zonder jezelf te vergeten

Zorg ervoor dat je in een team voor jou problemen de argumenten vindt, die je teamgenoten kunnen begrijpen en accepteren. Zoek argumenten, die aansluiten bij algemene team doelen en beschrijf ze bij voorkeur in concrete getallen. Als dit niet mogelijk is, zoek iemand, die je kan helpen. Bespreek het probleem alleen met deze persoon. Een eventuele oplossing kan dan aan het hele team voorgesteld worden. Maar het allerbelangrijkste: verzwijg je problemen niet. Ook al zijn het problemen van jou alleen... elk probleem van jou is uiteindelijk ook het probleem van het team.

Reactief en proactief testen: wat is het en waarom is het beide nodig?

Reactief en proactief testen: het zijn geen officiële testtermen. Toch merk ik dat ze voor mij steeds meer een belangrijk onderwerp worden. Wanneer test je op basis van incidenten, wanneer op basis van strategie? En waarom is beide nodig?

Bij reactief testen test je op basis van "wat moet er nu getest worden". Hierbij moet je denken aan gebouwde story's, gemelde bugs. Maar ook op basis van klachten en zorgen van klanten, managers, helpdesk, collega's. Je reageert met je testen op wat er in je omgeving gebeurt.

Bij proactief testen test je op basis van een strategie. Dit kan een testtechniek zijn, een risicoanalyse, een analyse van de fouten gevonden in de afgelopen maand. Het grote verschil: hoewel de opgeleverde story's en bugs en ook de klachten en zorgen meetellen, zijn ze niet doorslaggevend. Je kan besluiten om een bug niet te testen of een klacht te negeren.

Ik weet: de scheiding is niet zo strikt. Je kan reactief een story testen, maar deze story vervolgens proactief testen met behulp van een gekozen testtechniek. Of je kan op basis van een proactieve risicoanalyse besluiten om alle bugs reactief te testen. Het belangrijkste is: je hebt als tester een andere rol. Bij reactief doe je wat er van je gevraagd wordt: testen wat getest moet worden. Bij proactief doe je wat er van je verwacht wordt: de kwaliteit bewaken.

Je kan niet altijd de hele omgeving negeren als tester. Opgeleverd werk moet getest worden. Bugs moeten gecontroleerd worden. En klanten of managers hebben eisen en verwachtingen. Als de prioriteit hoog genoeg is, kan je niet als tester zeggen: kan best, maar ik test het niet, want het komt niet overeen met mijn strategie.

Maar je kan ook niet altijd zeggen: ik test gewoon alleen wat er van me gevraagd wordt. Waarom? Dat heeft te maken met een vaak vergeten balans. Iedereen kent de balans van tijd v.s. kwaliteit. Als je minder tijd krijgt, gaat over het algemeen de kwaliteit achteruit. Maar zo is er ook een balans tussen kwaliteit v.s. kwaliteit. Je hebt als tester maar x uur in de week. Als je deze aan programma A besteed, kan deze niet naar programma B. Als je deze aan performance testen besteed, kan deze niet naar functioneel testen. En als je minder tijd kan besteden aan programma B of functioneel testen, is de kans groot dat de kwaliteit van deze applicatie of dit onderdeel gaat afnemen.

Om dit te voorkomen heb je een soort basisdekking nodig. Een soort gegarandeerde minimale tijd of dekking, die een test of een programma of een ander los te testen onderdeel nodig heeft. Dit kan letterlijk tijd zijn. Maar ook een groep eisen, die minimaal getest moeten zijn. Een automatische test, die minimaal uitgevoerd moet zijn. Wat er nodig is, zal je als tester moeten bepalen. En, en dit is het moeilijkste, dit zal onder alle omstandigheden moeten plaatsvinden. Ook als het druk is, ook als het je niet uitkomt, ook als hierdoor een deadline in gevaar komt. Je kan altijd proactief besluiten om meer te testen, maar deze minimale dekking moet plaatsvinden. Zo zorg je ervoor dat de balans nooit teveel doorslaat van A naar B.

Waarom is dit nodig? Vooral in drukke tijden ontstaat de neiging om "per dag" te leven. En als een team onder druk wordt gezet, ontstaat de neiging om "per managerswens" te leven. Je test wat wordt aangeleverd en wat je omgeving van je vraagt. En wat niet wordt gevraagd of wordt aangeleverd, test je niet. Totdat wordt opgemerkt dat in deze opleveringen wel erg veel fouten zitten. Dan opeens wordt het werk geconcentreerd op dit probleem. En ontstaat er precies zo'n zelfde situatie op andere plaatsen. Plaatsen waar jij nu niet test. Zo spring je, als je niet oppast, van de ene critical situation naar de andere critical situation. En zou het dan niet veel beter zijn om een volgende critical situation te voorkomen?

Ja, reactief testen is nodig. Wat opgeleverd is, moet getest worden. En in elke organisaties zijn er nu eenmaal prioriteiten, waar je als tester rekening mee moet houden. Maar je moet wel je testersvaardigheden blijven inzetten. Zorg ervoor dat je alles zo blijft testen, dat je een zekere kwaliteit kan blijven garanderen. Dat de kwaliteit van een oplevering niet alleen afhankelijk is van de externe omstandigheden, maar ook van jou kennis en ervaring als tester. Blijf altijd proactief testen. Het zal niet altijd makkelijk zijn, maar uiteindelijk zal het zowel jou als je organisatie meer rust geven.