Blog

Testen, agile en voorspellingen: best lastig!

Geplaatst op 1/03/2021

Door: Nico van Mourik, Consultant bij ViQiT

Avondklok, lockdown, 1,5 meter samenleving en thuiswerken. Behalve jezelf suf netflixen is het soms erg leuk om eens door oude foto albums te bladeren. Je ziet jezelf tijdens de lagere schooltijd en op de middelbare school. Je denkt terug over wie je was en ook over wie je wilde worden. Maar pas op: het kan best confronterend zijn als je ziet wie je nu bent.

Dit gaat ook op voor mijn werk. Ik las laatst een stuk terug dat ik schreef voor één van mijn klanten[1]. Het ging over de toekomst van het testteam en de testers binnen een organisatie die agile wilde gaan werken. Nu was ik heel benieuwd of datgene wat ik al die jaren geleden had geschreven in ieder geval een beetje in de buurt zat van de werkelijke ontwikkelingen. Een aantal ontwikkelingen zijn  uitgekomen, maar op sommige onderdelen zat ik er toch faliekant naast.

Agile teams: wat gaan de testers doen?

Laat ik beginnen met het eerste onderdeel wat is uitgekomen: ”Het testen gaat zich 2 kanten op bewegen: enerzijds het geautomatiseerd testen op een zo vroeg mogelijk tijdstip in de ontwikkelcyclus en anderzijds de steeds meer naar de business bewegende UAT. De grote testteams met hiërarchische structuur zijn dan niet meer nodig.”

We zien dat deze ontwikkeling daadwerkelijk heeft plaatsgevonden. Wat ik daarbij wel over het hoofd zag was het feit dat geautomatiseerd testen eigenlijk geen testen meer is. Het is gewoon ontwikkelen en dat betekent dat de ontwikkelaars heel vaak deze testen schrijven. De ‘daadwerkelijke’ testers in de agile teams ontpoppen zich inderdaad steeds meer als de ‘linking pin’ tussen business en IT en worden daarbij vaak de sparring partner van de Business Analist.

Het uitgebreide functionele testen met het gestructureerde ontwerpen van de testcases is inderdaad grotendeels verdwenen.

En waar zat ik echt mis? In mijn veronderstelling dat alle testfuncties zouden gaan verdwijnen: “de testafdeling als zodanig verdwijnt en de test taken worden volledig door de multifunctionele teams overgenomen”.

Mijn overtuiging toen, was dat alles door het agile team zou worden opgepakt. Het is inmiddels mij wel duidelijk dat dit in de praktijk vaak niet zo gaat. De meeste ontwikkelaars in agile teams kunnen prima uit de voeten met het geautomatiseerd checken van de stukken code die zij opleveren. Het testen vanuit de optiek van de business wordt in veel gevallen opgepakt door de business analist in het team als er geen tester in het team aanwezig is. Dit is vaak niet de meest ideale oplossing. Een business analist heeft nu eenmaal vaak een andere insteek dan een tester, maar de business testen worden wel gedaan.  Aan de meer specifieke testsoorten en kwaliteitsmaatregelen wordt in veel gevallen minder aandacht besteed. Denk hierbij bijvoorbeeld aan security testen en performance testen.

De T-shaped medewerker

Idealiter bestaat een agile team uit collega’s met een T-shaped profiel. Je kent ze wel, die ‘unicorns’. Ze zijn gespecialiseerd in 1 onderwerp, maar weten zich ook staande te houden als het over allerlei andere zaken gaat in het team. Ik heb zeker teams gezien waar deze ideale situatie bijna bereikt was. Totdat bleek dat we toch weer even moesten wachten op de volgende sprint omdat dat specifieke onderdeel echt beter gedaan kon worden door dat ene teamlid die een weekje op vakantie was.

Als we kijken naar testen als vak, dan zien we daarbinnen ook een breed spectrum aan specialisaties. Dus als de specialisatie ‘testen’ bij één van de teamleden ligt, dan verwachten we wel heel veel van die ene persoon. Of hebben we dan T-shaped collega’s met een sub-specialisatie? Maar creëer je dan niet een test team binnen je agile team?

Veel organisaties lossen dit op door een team van specialisten te formeren die dan voor alle agile teams aan de slag gaan. Bijvoorbeeld: een team dat alle agile teams ondersteunt bij het inrichten, organiseren, uitvoeren en analyseren van een performance tests. Of een security test team. Of een test data team. Of …., nou ja, vul maar in. Een rol die ook vaak weer terugkomt is die van test manager/test coördinator. Wel is de invulling van die rol vaak heel anders. Kort gezegd: minder aansturen en meer coachen en afstemmen. Je moet je bijna gedragen als een politicus 😊.

Dit gaat zeker op rondom de integratie testen. Want de ideale architectuur waarbij het systeem is opgezet met behulp van volledig autonome delen die ieder verantwoordelijk zijn voor hun eigen integratie is maar op weinig plaatsen echt actueel. Veel, met name grotere, organisaties zitten nog met een forse legacy waar ze niet zo maar van af kunnen. Dat betekende voor het agile werken een enorme uitdaging, met name in de integratie (met name de non-regressie). Vaak hebben deze organisaties mede hierom ook het agile werken wat uitgesteld. Maar ook zij moesten op een gegeven moment wel over naar agile werken. Daarmee werd de afstemming tussen al die teams en de uitvoering van de juiste integratie testen een onderwerp dat lastig door de individuele teams kon worden opgepakt. Veelal is dit de primaire taak van een test manager/ – coördinator.

Testen en agile: hoe gaat het verder?

Wat gaan de ontwikkelingen worden voor testers in een agile omgeving? Tsja, wie het weet mag het zeggen!

Okay, dit is natuurlijk niet goed genoeg. Inmiddels zijn we een stapje verder, hebben we al veel meegemaakt en is ook DevOps niet meer iets utopisch maar steeds normaler geworden binnen organisaties. Dus wil ik me wagen aan een paar voorspellingen rondom testen. Daar gaat ie dan:

      1. De ‘tester’ in een agile/devops omgeving zal zich nog verder gaan bewegen naar een business analyse rol. De traditionele business analist en de business tester zullen meer en meer verweven tot 1 rol.
      2. De testautomatisering als test specialisatie zal steeds meer ‘naar links’ opschuiven en belegd worden bij developers. Ook de verdere ontwikkeling van de tools zal hierbij een rol spelen, doordat deze steeds efficiënter worden wordt het Test Driven Development steeds makkelijker.
      3. De specialistische testen (security, performance, integratie) zullen in de toekomst opgaan in de rol van release engineer. Door de verdergaande opmars van DevOps, worden deze taken verweven met de release management taken.
      4. De test coördinator/ – manager zal in veel organisaties nog wel even blijven, want er is nog zoveel legacy waar we de komende jaren niet vanaf komen dat deze rol nog nodig blijft. Maar uiteindelijk zal deze rol breder worden en richting kwaliteitscoach gaan die namens de organisatie het kwaliteitsbesef in de diverse teams probeert te vergroten.

       

Ik ben heel benieuwd hoe we hier over 10 jaar naar gaan kijken. Het is in ieder geval zeker dat ik ergens mis zal zitten 😊. Zo gaat dat nu eenmaal met voorspellingen. Wat ik wel weet is dat als je in de ‘testelarij’ actief bent: blijf actief aan jezelf werken en kijk breder dan je werk of rol op dat moment. Zorg dat je mee kunt met welke ontwikkeling dan ook. Hé?! Komen we toch weer op die T-shaped medewerker uit!

[1] Het stuk zelf kan helaas niet gedeeld worden i.v.m. vertrouwelijkheid richting de betreffende klant.