De test bottleneck.

Geschreven door Hylke de Jong

Gepubliceerd op 17 april 2020

Ik hoorde eens een product owner verzuchten tegen zijn team: “Waarom is testen toch altijd de bottleneck?” Het hele team viel stil en keek naar de tester, die wel door de grond kon zakken. 

Waarom wordt testen vaak gezien als bottleneck? Het zit al van oudsher op het kritieke pad en ik had gedacht dat we daar ondertussen wel mee om konden gaan. De opkomst van Agile maakt dat dit thema weer relevanter is dan ooit. Waar voorheen dit pijnpunt alleen tijdens de laatste fase van een watervalproject boven kwam drijven, worden we nu elke sprint weer geconfronteerd met deze situatie.

Het was destijds niet de eerste keer dat ik deze verkapte beschuldiging hoorde en het zal ook wel niet de laatste keer zijn. Gelukkig kunnen we er wel wat aan doen. Te beginnen met het schrijven van een blog…

Het probleem

Ik denk dat de meeste testers zich wel kunnen herkennen in het volgende beeld: er wordt een nieuwe sprint gestart en je hebt nog niet zo veel te doen. De developers zijn nog bezig met de eerste stories. Gaandeweg de sprint worden er zaken opgeleverd en krijg je het ook drukker. Als de laatste dag van de sprint nadert zit de test kolom in Jira inmiddels vol met zaken die ge(her)test kunnen worden. Het is nog maar de vraag of je het allemaal gaat redden. Dit zorgt voor veel stress en dat komt de sfeer en de werkverhoudingen in het team niet ten goede. Zeker niet als men tijdens de retro telkens weer de vraag stelt hoe het toch komt dat test zo vaak niet op tijd klaar is.

Wellicht is bovenstaande een uitvergroting van de werkelijkheid, maar ik denk dat het in de kern wel een probleem raakt waar veel testers mee worstelen. Hoe zorg je ervoor dat het werkbaar blijft?

In essentie zit het grootste probleem in het feit dat testen binnen Agile een proces- en mindset-verandering met zich meebrengt die niet alleen betrekking heeft op de tester, maar op het hele team. Een developer kan zijn oude flow redelijk snel oppakken omdat er, gekeken vanuit zijn oude rol, al vrij snel weer dezelfde output wordt geleverd. Voor testers geldt dit niet. Om een effectieve tester te zijn binnen een kortcyclische ontwikkelmethode heb je hulp nodig van het hele team.

Kwaliteit is een teamverantwoordelijkheid

Niet alleen de tester, maar het hele team is verantwoordelijk voor de kwaliteit van het opgeleverde product. Het lijkt een ontzettende open deur, maar de praktijk heeft mij geleerd dat hier nog veel mee geworsteld wordt. Als men al tot het besef komt dat je niet van één persoon kunt verwachten dat deze alle testactiviteiten (en bijbehorende verantwoordelijkheden) voor zijn rekening neemt, dan nog gaat de gedeelde verantwoordelijkheid vaak niet verder dan dat “iedereen ook af en toe een story oppakt uit de test kolom”. Hoe mooi en sympathiek dit ook lijkt, het is niet effectief. Developers zijn developers omdat ze van coderen houden. Laat je zo’n iemand een feature testen dan zijn toch, nog los van de benodigde skills, de inzet, motivatie en mindset er gewoon niet.

Een veel betere manier is om iedereen testactiviteiten uit te laten voeren op het niveau en op een manier waar diegene zich het meest prettig bij voelt. Developers kunnen namelijk wel degelijk heel goed testen. Ze kunnen unit testen schrijven bijvoorbeeld. Ze weten doorgaans donders goed wat hun code zou moeten doen (als ze dat niet weten heb je de eerste potentiële bug gevoelige code al gevonden), en ze kunnen daar dus ook prima testen voor schrijven.

Op deze manier kan er al een grote bijdrage geleverd worden aan het algehele kwaliteitsproces van het team zonder dat men ver buiten de comfortzone hoeft te treden.

Eén van de punten waar duidelijk is te zien hoe ver een team is met betrekking tot gedeelde verantwoordelijkheid, is op het moment dat er een (productie)bug wordt gevonden. Als er meteen naar de tester wordt gekeken weet je dat men nog grotendeels binnen een oude mindset opereert. Een betere vraag zou zijn: “wanneer of waar hadden we dit voor het eerst kunnen vinden?”. Op die manier maak je heel duidelijk dat bugs niet ontstaan tijdens een testfase en dat er dus hulp van meerdere kanten nodig is om dit in het vervolg te voorkomen.

Testautomatisering is je beste vriend

Testautomatisering is een hot item binnen de IT. Veel organisaties zijn bezig met het implementeren van (verregaande) testautomatisering. Door sommige testers wordt hier nog met argusogen naar gekeken, maar vergis je niet: de toekomst van veel (niet alle!) testuitvoering is automatisering.

En met een goede reden. Automatisering zorgt ervoor dat jij als tester je handen vrij maakt van alle vervelende, saaie en herhalende activiteiten, zodat je je zo veel mogelijk kunt richten op andere zaken. Testautomatisering, mits goed uitgevoerd, zorgt voor snelle en consistente feedback die essentieel is voor het krijgen van inzicht in de kwaliteit. In het kader van wegnemen van eventuele test bottlenecks is testautomatisering onmisbaar. Het is goed om te beseffen dat ook deze last niet alleen op de schouders van de testers hoort te landen. Developers dienen hier ook de handschoen op te pakken door bijvoorbeeld het bouwen van de al eerdergenoemde unit testen.

Het hebben van geautomatiseerde testen is één ding, maar deze worden pas echt effectief op het moment dat ook de uitvoer geautomatiseerd is. Dit kan met behulp van een CICD-pipeline waarin tijdens verschillende fases van het build en deploy proces, op verschillende niveaus automatische testen worden getriggerd. Het hebben van een solide pipeline doet veel voor het algehele vertrouwen in het product. Dit heeft uiteraard tijd nodig om te groeien, maar als dit punt eenmaal is bereikt, is de toegevoegde waarde enorm.

Testen is geen aparte fase meer

De eerste sprints van teams die nog niet zo lang Agile werken, zijn vaak mini-watervalprojectjes die in een sprint van 2 of 3 weken worden gepropt. Dat is niet erg. Alle begin is moeilijk en er moet ook nog ruimte zijn om te groeien. Na verloop van tijd leert men en wordt er ook daadwerkelijk meer Agile gewerkt.

Testen als aparte fase (ook binnen Agile) is echter hardnekkig. Kijk naar het gemiddelde Jira bord, en ja hoor, daar staat hij: de test kolom. Raar genoeg zijn er vaak geen analyse, ontwerp, bouw, en onderhoud kolommen te vinden (kleine hint: als je die wel hebt… ben je dan wel echt Agile bezig?). Uiteraard moet er wel getest worden, dus wat is dan het probleem met het hebben van een test kolom?

In de eerste plaats dekt het de lading niet. Testen is een breed begrip. Vragen stellen tijdens een refinement. Aangeven dat een story te groot is tijdens een planningpokersessie. Melden dat er niet meer in een sprint kan omdat het anders niet testbaar is. Een developer coachen om zelf even te kijken of zijn nieuwe feature het ook doet in IE11. Draag een paar edge cases aan voor een unit test. Monitor productiedata en potentiële crashes. Onderhoud de automatische regressie testen. Een code review doen van een pull request. En, uiteraard, het uitvoeren van exploratory testen. Het zijn allemaal voorbeelden van testactiviteiten die op verschillende momenten tijdens verschillende fases binnen en buiten een sprint worden uitgevoerd. De test kolom zou in feite de breedte van het hele bord en ver daarbuiten moeten beslaan om daadwerkelijk recht te doen aan de werkelijkheid.

Daarnaast geeft het developers ook een (al dan niet) onbewust signaal dat er nog een vangnet is. Het maakt niet uit dat men niet zo goed weet wat er nou eigenlijk bij een feature hoort, of dat er wel erg veel code is gewijzigd of dat je zelf niet helemaal hebt gecheckt of het wel werkt: hierna gaat het naar test, dus die regelen het wel. En daar gaat de gedeelde verantwoordelijkheid waar we het al eerder over hadden.

De testkolom weghalen geeft een duidelijk signaal af. Er is geen laatste vangnet meer. Als je van mening bent dat iets productieready is, moet je het ook meteen durven releasen, zonder tussenkomt van iemand anders. Durf je dat niet? Dan hebben we nog ergens werk te doen.

Dit betekent niet dat er niet meer getest wordt, in tegendeel. Misschien wel meer dan ooit, alleen gebeurt dit op andere niveaus en tijdens verschillende stadia van de sprint. Dit alles met als doel om ervoor te zorgen dat het team een story met de status ready for prod ook daadwerkelijk met vertrouwen durft te releasen.

De lange adem

Niets is zo moeilijk als veranderen. Zeker als er naast gedrag ook nog eens iets als een mindset bij komt kijken. Het vergt geduld, lef en doorzettingsvermogen om bovenstaande in de praktijk te brengen. Het is het echter meer dan waard.

Los van het positieve effect op je eigen gemoedstoestand, zullen ook de snelheid van levering en de kwaliteit in zijn geheel toenemen. Binnen de gemiddelde organisatie is het niet lastig om draagvlak te vinden voor deze voordelen. Maar nogmaals, het daadwerkelijk implementeren vergt een lange adem.

De test bottleneck is weg te nemen. Je moet het alleen vanuit het hele team doen. Dat maakt dat er aan het einde een solide, robuust en schaalbaar proces staat dat past bij een wendbaar Agile team.

Schrijf een reactie

Gerelateerde artikelen