Tag: testen

  • Wat maakt testen uitdagend

    Wat maakt testen uitdagend

    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!

  • Het is belangrijk dat er een goede overdracht is

    Het is belangrijk dat er een goede overdracht is

    Wanneer een ontwikkelaar een nieuwe feature oplevert, heeft het echt een grote meerwaarde als er een overdracht plaatsvindt. Er zijn een aantal redenen waarom, en ik ben eigenlijk ook wel benieuwd hoe jij hier als tester of ontwikkelaar naar kijkt.

    De tester krijgt meer inzicht in wat er getest moet worden. Als het goed is, heeft de tester tijdens het refinen en de testvoorbereiding al veel informatie gekregen. Toch kunnen er tijdens de refinement en de oplevering veel dingen zijn veranderd.

    De ontwikkelaar heeft ook nieuwe inzichten opgedaan tijdens het bouwen. Deze informatie is mogelijk nog niet in de PBI/story verwerkt.

    De teamleden leren samenwerken en met elkaar communiceren. Zeker in een DevOps-setting, waarbij er vaak vanuit huis wordt gewerkt, is dit heel belangrijk.

    Door samen door de feature heen te lopen, kan de tester de feature direct valideren. Die ziet misschien nog kleine dingen die net anders kunnen of verbeterd kunnen worden. In plaats van dit te registreren en het later pas te bespreken, kan dat direct met de ontwikkelaar. Kom je er dan niet uit, dan kun je er altijd nog met de P.O. over praten.

    Er is ook sprake van kennisborging. Door de overdracht heeft nu ook de tester de kennis van de feature.

    De ontwikkelaar kan bovendien direct de pijnpunten
    benoemen van de feature en aangeven waar het complex was om te ontwikkelen. Hier kan de testen dan rekening mee houden en eventuele risico’s inschatten.

    Welke punten mis ik hier? Wat denk jij? Laat het weten in de comments!

Disclaimer

De artikelen op deze website zijn geschreven vanuit mijn persoonlijke perspectief. Ik deel hier mijn visie, ervaringen en meningen. Ben je het niet eens met wat je leest? Dat is helemaal oké, je bent vrij om verder te lezen, de dialoog met mij aan te gaan, of simpelweg de website te verlaten en nooit meer terug te komen.

Hier kan je de complete disclaimer lezen