Tijdens een trainingsavond over Rapid Software Testing door Huib Schoots, kwam de vraag waarom testen moeilijk kan zijn. En deze vraag werd gesteld aan senior testers. De verbaasde blikken… hoezo moeilijk? Maar toen we wat dieper in de materie gingen kwamen er toch wel leuke dingen op tafel.
Eigenlijk sta je hier niet zo bij stil als je tester bent. De antwoorden die boven water kwamen waren best verrassend. Het is net als je iemand wil uitleggen hoe je moet fietsen. Want je stapt op de fiets en gaat, toch? Als je stil staat bij waarom testen moeilijk is dan krijg je toch wel een leuk lijstje.
Heb ik iets over het hoofd gezien?
– Tijdsdruk om de sprint te halen
– Tegengestelde belangen
– Het hebben en krijgen van de juiste informatie
– Processen die niet duidelijk zijn
– Problemen in de infrastructuur
– Beschikbaarheid van infrastructuur
– Onjuiste of geen testdata
– Niet bij een/het team horen
– Constante veranderende scope
Er zijn twee punten die ik wil uitlichten omdat die bijzonder zijn in mijn ogen.
De tegengestelde belangen en het niet bij/het team horen.
Je merkt als tester al heel snel hoe(veel) de politiek is in een organisatie. Tijdens de gesprekken die je hebt met de P.O., de ontwikkelaars, de scrum master en andere mensen uit de business krijg je heel veel informatie. Hierdoor krijg je al gauw door wie welke belangen heeft en waarom. Deze belangen kunnen soms zo tegenwerken dat je daardoor je werk niet goed kan uitvoeren. Soms is het zelfs heel blokkerend dat je dan ruimte moet maken voor andere partijen. Dit heb ik zelf meegemaakt bij een opdracht. Ik kan hier niet teveel over schrijven omdat ik discreet wil blijven. Maar laat ik het zo zeggen dat er een heleboel mensen weer konden zoeken naar een andere opdracht en er via de achterdeur al weer nieuwe mensen naar binnen kwamen.
Een andere uitdaging is dat je soms niet als tester bij een team hoort. Je bent dan echt de “waakhond” vanuit het bedrijf. Dit heb ik zelf meegemaakt tijdens een opdracht waarbij ik was ingehuurd om een website te testen. De website werd gebouwd door een externe partij. Dat ik extern was gaf toch een beetje een rare vibe omdat ik de boel kwam “inspecteren”. Je staat er dan toch buiten maar je hebt wel een aandeel in het proces. Gelukkig had ik al wat jaren ervaring dus paste ik mij aan. Je krijgt niet alles mee en je bent niet bij bepaalde meetings omdat dat alleen voor interne mensen is. Dus je valt dan toch een beetje buiten de boot.
Een andere vorm van niet bij het team zijn is dat je niet bij elkaar zit. De huidige werkomgeving is toch dat je veel thuis werkt. Het is dan een uitdaging om aan je informatie te komen. Je kan het net hebben dat je in een team komt dat niet communiceert, weinig met elkaar samenwerkt, allemaal op een eigen eiland werkt en je aan het einde van de sprint maar moet zien hoe het is gebouwd en is getest. Ik heb een opdracht gehad waarbij er opeens ontwikkelaars werk gingen verdelen en die zag je dan pas weer aan het einde van de sprint. Hierdoor was de flexibiliteit van het agile/scrum werken ver te zoeken.
Het is soms net een schaakspel. Ik hoop dat je hier wat mee kunt. Heb je zelf nog punten die je zou willen toelichten over het testen en de uitdagingen? Zet ze dan in de comments!

Geef een reactie