Het uitgangspunt binnen Agile is dat er aan het eind van een sprint (“productieperiode” van een aantal weken) een werkend product wordt opgeleverd. Maar wat is de definitie van een werkend product en hoe kan je dat garanderen. Dit wil je als team natuurlijk aantoonbaar maken. De mate van werkend wordt vastgelegd in de Definition of Done. Een (deel)product kan op het oog probleemloos werken, maar na oplevering verstoringen veroorzaken in het (business)proces. Testen kan zorgen voor de aantoonbaarheid.
Ik merk bij discussies over het invullen van testen binnen een Agile omgeving dat geworsteld wordt met de beantwoording van bovenstaande vraag. Zet je een vaste tester in een team, krijgt iemand de spreekwoordelijke “pet” op van tester, bepaald het team zelf de invulling of vul je het testen niet binnen het team in maar buiten het team?
Het “juiste” antwoord lijkt niet te bestaan en is afhankelijk van de situatie en omgeving waar je in zit. De keuze wordt bepaald door vele factoren, als grootte en samenstelling van het team, specialistisch product of niet, belang van het gebruik van het (deel)product, plaats en belang van het product in de keten, type product, aantal teams dat werkt aan het (deel)product, is het team onderdeel van een train of niet, volwassenheid van het team, (inhuur)budget en eigen verantwoordelijkheid van het team. Daarnaast moeten we niet de financiële-, reputatie-, gevolg- en operationele risico’s/schade vergeten bij fouten na oplevering. Natuurlijk hangt het ook af van de organisatie zelf, de industrie waar het bedrijf zich in begeeft en de testvolwassenheid van de organisatie. Worden er bijvoorbeeld al (geautomatiseerde) regressietesten uitgevoerd.
Maar de keuze wordt ook bepaald door hoe het team is samengesteld. Is het een team met louter ontwikkelaars, een mix van disciplines of meer DevOps gericht.
De rol van de product owner en scrummaster heeft ook grote invloed op het maken van een keuze over de invulling van het testen. Hoe goed worden de user stories beschreven en wordt daar de testbaarheid in het achterhoofd in meegenomen? Zo niet, wordt dit dan wel tijdens de sprintplanning uitgevraagd? Allemaal vragen die je moet stellen om te komen tot de voor dat moment de beste invulling.
Het in kaart brengen van alle factoren en hun zwaarte kan helpen om een invulling te kiezen. Tijd voor testen is ook altijd een factor welke bepalend kan zijn op het testen. Testen wordt nog wel eens als sluitpost gehanteerd, daarmee nog niet zeggend dat er niet goed getest wordt.
En als je deze dan hebt gekozen, zal iedere keer tijdens de retrospective bekeken moeten worden of er bijstelling nodig is. In de retrospective kijkt het team terug op de uitgevoerde sprint en bepaald samen naar welke verbeteringen meegenomen worden naar de volgende sprint.
Het Agile team heeft een eigen verantwoordelijkheid voor het opleveren van (deel)producten. Maar hoe ver reikt deze verantwoordelijk? En wanneer wordt er ingegrepen, wanneer uitwijst dat (deel)producten niet foutloos zijn? Dat is een interessante discussie waar op een later moment ook een post over geschreven kan worden.
Dan ook kijken naar de uitvoer van het testen. Testen uitgevoerd door ontwikkelaars heeft ook andere insteek dan testen door de “agile tester”.
Ontwikkelaars kijken over het algemeen meer naar de “goed” situatie, terwijl de agile tester de insteek neemt vanuit het ontdekken van fouten. De agile tester zal meer een testaanpak nemen, de ontwikkelaar meer code review en wat relatief makkelijkere testen uitvoeren. Ieder zo zijn of haar specialisme? Of deden we daar niet meer aan in multidisciplinaire teams?
Iedere situatie zal een andere aanpak vragen. Er is niet één aanpak die altijd past. Uiteindelijk gaat het om een combinatie van factoren en welke van de factoren het zwaarst weegt, wat de doorslag geeft. En nogmaals, de invulling die gekozen wordt op basis van deze weging kan bij verandering in de situatie anders uitslaan en zorgen voor een aanpassing van de aanpak. Het is zaak te blijven evalueren en bijsturen waar nodig!
Wat is jouw ervaring? Hoe vul jij het testen binnen je (agile) team in en wat is de afweging om dat zo te doen? Wat is je ervaring en wanneer kies je ervoor om een vaste tester in het team te zetten en wanneer niet? Wordt er ook buiten het team nog getest na oplevering?
We zijn heel benieuwd naar je reactie en komen graag in contact!
Auteur: Robin Heemskerk