Functioneel testen door ontwikkelaars

Testen is een specialisatie, ik zal de laatste zijn om dat te ontkennen. Maar zeker in een Agile omgeving kan je in de situatie komen dat ook ontwikkelaars moeten testen. Bijvoorbeeld als het testwerk te veel is voor de enige tester in het team. Of je gaat als enige tester in het team op vakantie. En eerlijk is eerlijk: ontwikkelaars zijn meestal geen slechte testers. Tenslotte is het testen van hun eigen code een vast onderdeel van hun werk. Een echt goede ontwikkelaar kan niet een echt slechte tester zijn Toch stappen veel ontwikkelaars in valkuilen, die ervaren testers kunnen ontwijken. Hoe zorg je er als tester voor dat ontwikkelaars beter gaan testen?

Er zijn twee belangrijke varianten die je hierbij kan volgen. Welk pad het juiste is, hangt af van jezelf en van je werkomgeving. Als je bijvoorbeeld goed kan uitleggen of als je een team moet begeleiden waar je zelf geen deel van bent, dan zal de nadruk liggen op het coachen. Maar als je team of het bedrijf nog erg veel denkt in gescheiden disciplines of je voelt je geen coach, kan je altijd nog teruggrijpen naar een vorm van testvoorbereiding. Maar waarschijnlijk komt het erop neer dat je beiden moet proberen en ontdekt welke van de twee manieren of welke combinatie jou het beste bevalt.

Testvoorbereiding

Het doel van de testvoorbereiding is niet veel anders dan we als testers gewent zijn: je schrijft van tevoren de testscripts en/of de testcases, zodat de test later uitgevoerd kan worden. In de testvoorbereiding verwerk je dat deel van jouw specialistische kennis, die een ontwikkelaar vaak niet heeft. Het probleem bij deze methode is het opbouwen van een voorsprong. Jouw testvoorbereiding moet klaar zijn, voordat de bouw gereed is. En die tijdsperiode is bij een Agile methode soms erg kort. Zeker als je ook nog een extra voorsprong moet hebben om bijvoorbeeld een vakantie te overbruggen.

Als je de voorsprong wil behouden, zal je soms als tester een moeilijke keus moeten maken. Het kan nodig zijn om je voor een bepaalde periode alleen te richten op de testvoorbereiding. Het testwerk komt dan volledig bij de ontwikkelaars te liggen. Als het nodig is, neem dan deze keuze: het doel is niet dat jij de test uitvoert, het doel is dat er goed getest wordt.

Belangrijkste nadeel van deze methode: je blijft altijd lang bezig met de voorbereiding. Het werkt wordt nooit minder, omdat de ontwikkelaars niet beter leren testen. Maar het voordeel is dat je deze methode altijd kan toepassen, ongeacht je eigen vaardigheden, het bedrijf waar je werkt of het team waar je deel van uitmaakt.

Coaching

Op het gebied van coaching heb ik zelf ervaring op twee verschillende gebieden: procesmatig en inhoudelijk.

Procesmatig ligt de nadruk op principes die ervoor zorgen dat het testproces constant en goed uitgevoerd wordt. Zelf houd ik minimaal de volgende twee principes aan:

1. De functionele test wordt niet uitgevoerd door de ontwikkelaar die de code geprogrammeerd heeft
2. De functionele test wordt zo dicht mogelijk op de bouw uitgevoerd

Belangrijk is om momenten te vinden waarop je deze principes kan controleren of  in herinnering kan brengen. Denk hierbij bijvoorbeeld aan de daily standup of de retrospective.

Maar daarnaast kan het ook verstandig zijn om de functionele testvaardigheden van ontwikkelaars beter te krijgen. Bijvoorbeeld door ze bepaalde testtechnieken te leren of bepaalde testprincipes. Mijn eigen favoriete methode is de "Drie meest voorkomende fouten" methode. Hierbij gebruik je je ervaring als tester om te bepalen wat bij jou in het team de drie meest voorkomende fouten zijn. Vervolgens bepaal je voor jezelf hoe jij als tester specifiek op deze fouten test. Dit samen kan je in een document, een presentatie of iets dergelijks samenvoegen. Wat je dan vervolgens met de ontwikkelaars kan delen.

Om de coaching goed uit te voeren heb je veel medewerking nodig, zowel van je team als soms van je bedrijf. Maar als het lukt, betreft het wel een investering die op een bepaald moment niet meer nodig is. En ter geruststelling: je zal jezelf niet snel overbodig coachen.

Blijf betrokken

Als het ook maar enigszins mogelijk is, blijf als tester zelf ook testen. En kijk naar de bevindingen die gevonden worden. Vooral als ze uit productie komen. Of je nu kiest voor testvoorbereiding en/of coaching, gebruik je kennis als professionele tester. Kijk welke bevindingen gemist worden en kijk welke bevindingen veel gevonden worden. Gebruik deze kennis om je testvoorbereiding en/of je coaching nog beter te laten worden. Als je een echt goede tester bent, dan kan je altijd een volgende keer het functioneel testen beter laten verlopen. Ook als de functionele test door ontwikkelaars uitgevoerd wordt.