Testen als onderdeel van potentially releasable

Ik heb tijdens mijn carrière alleen in Agile- en Scrum-projecten gewerkt, en ken de Waterval-werkwijze alleen van horen zeggen. Toch zijn uitspraken als 'over de schutting gooien' mij niet bepaald vreemd. Zo lag mijn rol ‘binnen’ het team meerdere keren vooral buiten het team. Want pas nadat het team klaar was met ontwikkelen en aan de slag ging met nieuwe features en fixes, mocht ik mijn werk doen. En deed ik een bevinding, dan ging die op de backlog. Met als gevolg dat die bevinding pas op zijn vroegst de volgende sprint werd opgepakt. Mijn hertests vonden dan weer na die sprint plaats, zodat we uiteindelijk maanden verder waren voordat we naar productie konden.

Deze manier van werken is natuurlijk niet handig. Bovendien is het niet de manier die in de Scrum Guide wordt beschreven. In de Scrum Guide komt meerdere malen de term potentially releasable voor. Wat er opgeleverd wordt in een sprint hoeft niet in productie (want daar zit het hele beheerverhaal vaak nog achter), maar moet wel in productie kúnnen. Oftewel, het product moet helemaal klaar zijn.

Omschakeling
Om te weten wat het team en de product owner hieronder verstaan, kan het team een Definition of Done opstellen. Als het team inderdaad een product moet opleveren dat in productie zou moeten kunnen, dan hoort testen daar ook bij. Maar dat betekent wel een omschakeling in de werkwijze en de teamsamenstelling ten opzichte van wat ik gewend ben (eerst ontwikkelen en dan testen buiten het ontwikkelteam). De omschakeling die nodig is, licht ik hieronder verder toe.

Voor het opleveren van een product – met nieuwe functionaliteiten/fixes – dat het vereiste testproces heeft doorlopen, moeten de planning en samenwerking goed zijn. Als tester kun je niet tot het einde van een sprint wachten eer de ontwikkelaars iets opleveren, want wat als je dan nog iets vindt? En als ontwikkelaar kun je niet al het testen overlaten aan de testers en moet je blijven communiceren over wat er gebouwd wordt.

Dan is het toch beter om de Scrum Guide te volgen in plaats van het verzinnen van een eigen oplossing. Daarin staat dat in het team alle rollen vertegenwoordigt zijn, maar dat er geen andere titels zijn dan developer. Daarnaast zijn er geen subteams en is het hele team verantwoordelijk voor al het werk dat gedaan moet worden.

Tijdens het ontwikkelen van bijvoorbeeld een nieuwe feature, moet testen vanaf begin af aan onderdeel zijn van het proces. Dit houdt het volgende in:

• Tijdens de refinement wordt gekeken naar de acceptatiecriteria en de testbaarheid van de story. Is alle benodigde informatie aanwezig? Is het überhaupt wel te testen? En wat voor invloed heeft dat op de schatting? Het kan zijn dat een story puur door het testwerk opgesplitst moet worden, omdat er bijvoorbeeld speciale infrastructuur nodig is.
• Bij de planning moeten de specialiteiten van de beschikbare teamleden meegenomen worden bij de commitment op de stories. Dit geldt voor zowel het testen als voor de ontwikkeling.
• Tijdens de sprint moet vanaf het begin van het oppakken van een story het testen onderdeel zijn van het werk. Dit kan bijvoorbeeld het voorbereiden van tests zijn (door het maken van testcases), het alvast automatiseren van tests of het aanpassen van de regressietests. Het team kan ook kiezen voor Test Driven Development (TDD), waarbij de tests eerst geschreven worden en daarna pas de code, totdat de tests slagen. Daarnaast kan er gekozen worden voor pair-programming als werkwijze, waarbij iemand met test-expertise en iemand met ontwikkelexpertise samen een story opleveren. Het is erg belangrijk om bij het opleveren rekening te blijven houden met niet alleen de testen van de story zelf, maar ook de regressietesten en eventuele security-, integratie-, keten- en performancetests. Het komt vaker voor dat de laatste soorten tests geen onderdeel uitmaken van de sprint, omdat ze teveel tijd kosten door allerlei afhankelijkheden die een groot risico kunnen zijn voor het halen van de sprint.
• De regressietesten daarentegen moeten wel tijdens de sprint worden uitgevoerd. Hiermee moet niet tot het einde van de sprint gewacht worden (tot de meeste stories zijn opgeleverd), omdat er dan geen tijd is voor het oplossen van bevindingen en hertesten. Daarom moeten de regressietesten eigenlijk per story worden uitgevoerd, maar dat is niet mogelijk als het te lang duurt om ze uit te voeren. Daarom is het optimaliseren van de regressietestset heel belangrijk. Niet alleen moet hierbij rekening gehouden worden met hoe lang iedere test duurt en bijvoorbeeld het uitvoeren van testen in parallel, maar ook of alle testen wel echt nodig zijn in de regressietest. Het is normaal om bij het opleveren van een story meer tests te hebben dan later in de regressietestset terechtkomen. Een goede richtlijn voor de optimale grootte van een regressietestset is ongeveer een uur uitvoertijd. Dit is een set die je zonder teveel belemmeringen kunt uitvoeren na een build, nachtelijk en ook nog op het laatste moment. Als de set groter wordt, wordt het al lastiger om de set na een build uit te voeren, omdat er dan teveel wordt opgehouden door de test. Daarnaast wordt het ook steeds lastiger om de testset op het laatste moment uit te voeren.
• De maximale grootte van de testset is echt wat je nog in een nacht kan uitvoeren. Dan heb je nog de optie om iedere nacht te testen in plaats van na iedere build, zodat je op de hoogte blijft van de status van het product als geheel.
• Tijdens (en na) een sprint is het testen (net als het ontwikkelwerk) de verantwoordelijkheid van het hele team. Dit betekent niet alleen dat iedereen moet letten op het testen, maar ook dat iedereen zou moeten kunnen testen (net zo goed als ontwikkelen). Natuurlijk heb je specialisten in je team, maar in de basis moet iedereen het werk kunnen oppakken. Uiteindelijk komt dit de kwaliteit en opleversnelheid alleen maar ten goede: hoe meer en hoe eerder getest wordt, hoe minder tijd je later hoeft te steken in het fixen van bevindingen.
• Bespreek met de product owner hoe hij een story opgeleverd wil zien. Kijk kritisch naar het bewijs dat geleverd moet worden. Is het echt nodig om voor iedere sprint een testrapport op te leveren? Of is het misschien al genoeg dat de testresultaten te achterhalen zijn en dat hij vertrouwt op de expertise van het team, met de afspraak dat er geen falende tests zijn? Testrapporten schrijven kost vaak veel tijd, en de vraag is of ze echt iedere sprint nodig zijn.

Door de Scrum-‘regel’ dat er iedere sprint een potentially releasable product wordt opgeleverd, wordt er een andere werkwijze gevraagd van alle teamleden. Er moet minder traditioneel in hokjes gedacht worden, en testers en ontwikkelaars moeten nauw samenwerken, waardoor de twee werelden dichter bij elkaar komen. Samen, als team, lever je dan een product op dat meteen waarde kan leveren voor de product owner.

Deze blog verscheen eerder op www.centric.eu/craft
Sara Raap-van Bussel is werkzaam bij Centric en actief als Craft Expert.