De impact van agile op testen

Wat zijn de gevolgen van de agile trend voor het testvak, de testers en het testproces? De vraag is al eerder gesteld en belangrijke delen van het antwoord hebben anderen en ikzelf al gegeven in diverse publicaties en blogs. In deze bijdrage zet ik dit op een rijtje en laat ik nog eens zien hoe waardevol het W-model in deze discussie is.

Mijn verhaal is nog niet uitgekauwd, hermetisch en compleet (voor zover je dat ooit kunt zijn), maar vooral om jou als lezer te verleiden jouw mening te geven zodat we met elkaar tot gerijpte inzichten kunnen komen.

Volgens mij zit de grootste impact van agile en scrum voor de tester op deze drie vlakken:

1. de psychologische spagaat2. regressietesten, geautomatiseerd testen3. combinatierollen

Laten we ze alle drie eens langslopen.

1. De psychologische spagaat

Wat ik daarmee bedoel? Ik zeg het simpel en ongenuanceerd: als tester ben je niet op deze wereld om vrienden te maken. Je wordt geacht onafhankelijk te zijn, je moet tegen de heersende group think in kunnen gaan en impopulair nieuws durven brengen.

De psychologische spagaat zit hierin dat je in een agile team wél geacht wordt vrienden te maken en bij wijze van spreken voortdurend te knuffelen met je teamleden. Je bent samen verantwoordelijk voor het resultaat, souffleert elkaars zwakke plekken en houdt elkaar bij de les. Een tester die zich nadrukkelijk onafhankelijk opstelt loopt het levensgrote risico om buiten de groep te vallen en daarmee niet optimaal te functioneren als agile teamlid.

Voor wie denkt dat dit spijkers op laag water zijn: ik heb de afgelopen jaren diverse concrete gevallen meegemaakt van testers die ernstig in de problemen kwamen. Ik heb huilende testers gesproken die een uiterst ongelukkig buitenbeentje waren in hun team. Ik heb ook testers in het beklaagdenbankje zien staan voor een stuurgroep: “waarom heb jij laten gebeuren dat we dit ernstige probleem hebben in productie”. Wat de laatste betreft: die tester zei letterlijk dat hij het probleem had geconstateerd en geregistreerd (met een nummer erbij) maar dat het team had besloten om er niets mee te doen omdat het in de praktijk toch niet zou optreden. De tester ging daar onder druk van het team en hun ogenschijnlijk sterke argumenten in mee. Met uiteindelijk zeer vervelende gevolgen.

Kortom: een agile tester is een relationeel en communicatief geniet.

2. Regressietesten, geautomatiseerd testen

Agile is ‘design a little, build a little, test a little’. Die incrementele aanpak houdt in dat continue of in elk geval zeer frequent getest moet worden. Niet alleen de nieuw gebouwde functies, maar ook reeds bestaande functionaliteit en bestaande componenten. Elke nieuwe build vergt immers een herhaalde test of er niet onbedoeld fouten zijn ontstaan in onverwachte hoeken.

Dit betekent dat regressietesten nog meer dan voorheen een belangrijke component van het werk zijn. En creatieve agile teams houden natuurlijk niet van saai repeterend werk. Terwijl testers zich tot voor kort konden veroorloven om geautomatiseerd testen nog maar even uit te stellen, is het bij agile werken bijna onontkoombaar geworden.

Kortom: Een full-time testrol wordt een luxe en de tester die zich niet grondig heeft georiënteerd op geautomatiseerd testen en de bijbehorende tools is van weinig waarde in een agile context.

3. Combinatierollen

Volgens de officiële Scrum Guide kent een scrumteam maar één rol, namelijk die van ontwikkelaar (developer), waarin alle benodigde competenties zitten. Een fulltime en dedicated inzet als onafhankelijk tester ligt dus veel minder voor de hand. Dat geldt nog sterker voor testmanagers, omdat in de agile filosofie managers überhaupt ongewenst en verdacht zijn. En ik zie ze ook zelden of nooit: testmanagers in scrum teams.

Voor testers betekent dit dat we ons nog veel breder moeten oriënteren op aanpalende disciplines dan we al gewend waren. Dus als tester moet je ook een beetje business analist,

programmeur, infrastructuurspecialist en beheerder zijn. Overigens vind ik dit persoonlijk winst: een tester moest altijd al breed georiënteerd zijn en met alle betrokken partijen inhoudelijk kunnen schakelen.

Kortom: de agile tester is niet ‘slechts’ een goede tester maar een breed ontwikkelde ICT professional met business affiniteit.

Tot zover de drie belangrijkste. Ik wil er nog een paar aandachtspunten aan toevoegen.

Testware wordt beweeglijker

Het systematisch uitwerken van requirements via acceptatiecriteria en testdoelen naar logische en fysieke testgevallen is in een agile context minder voor de hand liggend. Alles wordt situationeel, exploratief en -jawel- context driven, maar wat mij betreft zonder de gekunstelde lading die de context driven ‘school’ hieraan heeft gegeven. Persoonlijk vind ik dat helemaal niet erg maar ik zie dat traditionele testers krampachtig proberen oude documentatieconcepten en topzware structuren te creëren die helemaal losgezongen zijn van de realiteit van het scrumteam. De terechte impact van agile is dat ze deze strijd verliezen.

Test Driven Development

Testen vooraf in plaats van achteraf is natuurlijk fantastisch. De hierboven beschreven regressietesten zijn veel kansrijker als de testgevallen ‘upstream’ en niet ‘downstream’ worden ontwikkeld. TDD is geen testfeestje maar een developmentfeestje: het hele concept is bedacht door development en testers hebben hier nauwelijks aan bijgedragen. Het is wel heel goed voor de multifunctionele samenwerking tussen testers en de rest van het team.

Overigens speelt TDD zich vooral op een technisch vlak af. Op het niveau van keten en acceptatietesten (ATDD) staat het nog in de kinderschoenen. Hoe dan ook: de impact van agile is dat testen vroeger in het proces aan de orde is.

Vertrouwen in het team

Dit is een belangrijke pijler van agile. Toch zijn veel managers nog erg gevoelig voor ‘Better safe than sorry’ en ‘Vertrouwen is goed, controle is beter’ (‘trust but verify’). Testers moeten hier tussendoor laveren: ze moeten managers opvoeden om het agile team te vertrouwen. Tegelijkertijd zijn ze verantwoordelijk voor de andere kant van de medaille: ze moeten actief de risico’s opzoeken en die leidend laten zijn voor de teststrategie. De verantwoordelijkheid hiervoor is meer naar het agile team gedelegeerd. Tip: kijk eens naar de AgRAM aanpak voor agile risicomanagement.

W-model

Tot slot: de communicatie, de discussie en het samen tot werkafspraken komen rondom bovengenoemde thema’s vraagt om een open houding. Belangrijk is dat de impact genuanceerd en niet zwart-wit is: meestal is er sprake van testactiviteiten binnen het agile team, waarbij de agile principes leidend zijn. Als de risico’s groot zijn dan zal er in veel gevallen ook sprake zijn van onafhankelijk testen buiten het scrumteam, dus na de sprintoplevering. In het W-model zie je dat terug onder de streep respectievelijk boven de streep. Dit model kan enorm helpen om de discussie te faciliteren en voor elke situatie de goede balans te creëren tussen agile productiviteit en velocity enerzijds en risicobeheersing en onafhankelijk testen anderzijds.

Auteur: Egbert Bouman