Op 2 oktober organiseerde TestNet een najaarsevenement met ‘Agile’ als centraal thema. Het evenement onderstreepte wat uit eerder onderzoek al bleek: Agile is bijzonder hot in testland. Het thema lag dan ook voor de hand, maar de sprekers kregen voor dit evenement wel een nieuwe opdracht mee.
De afgelopen jaren is binnen de testcommunity veel gepubliceerd en gepresenteerd over Agile, door Agile goeroes en door testexperts. Vaak ging het over de Agile basisregels, het manifesto, en dan specifiek de Scrum-aanpak, die op dit moment bijna synoniem lijkt aan de term Agile. Als er al een link wordt gelegd naar testen gaat het dikwijls over de mindset en de softskills die een tester nodig heeft. De evenementencommissie van TestNet heeft haar sprekers daarom specifiek opdracht gegeven om de brug te slaan naar het testvak: praktijkverhalen, succes- en faalverhalen en vooral best practices.
Het afgelopen evenement heeft echter opnieuw duidelijk gemaakt dat achter de sterke, maar abstracte basisprincipes van Agile een onmetelijke wereld van onontgonnen gebied ligt, waarin generieke waarheden niet of nauwelijks bestaan.
Simpele vragen als ‘is er nog plaats voor de testmanager binnen Agile?’; ‘Hoe organiseer ik een ketentest binnen mijn sprints?’ of ‘Waar positioneer ik non-functionele testen?’ zijn niet generiek te beantwoorden. Als je blijft doorvragen krijg je antwoorden met daarin typeringen als:
– Je zou kunnen proberen om…
– Bij ons hebben we …
– Afhankelijk van de context kun je…
De kracht van Agile is meteen ook haar uitdaging: de context van het project/de organisatie is bepalend voor de inrichting van de softwareontwikkeling, en daarmee het testen.
Het lijkt alsof testers, meer dan andere disciplines, worstelen met deze uitdaging. Testers zijn en masse op zoek naar hun plaats in het landschap, naar vaste waarden, generieke practices en succesverhalen over tools en technieken en hoopten die op het najaarsevenement te vinden.
Waarom deze zoektocht? Ik zie drie hoofdredenen:
Beperkte toepasbaarheid testmethodieken binnen Agile
De meeste testers in Nederland zijn geschoold vanuit een methodische aanpak (TMap, TestFrame, et cetera), waarin de methode uitgebreide handvatten (door de een uitgelegd als richtinggevend, door de ander als dogmatisch) biedt voor fasering, strategie, activiteiten, organisatie, tools en technieken. Dat geeft veel testers houvast en (schijn)veiligheid: ‘Het gras is groen, water is nat en testuitvoering komt na testspecificatie’. In Agile projecten is een deel van deze kennis niet toepasbaar, of enkel situationeel.
Vervaging van rollen
Een ander aspect is dat in Agile de traditionele softwareontwikkelingsorganisatie vervaagt. Teams worden multidisciplinair. Ontwerpers, ontwikkelaars en testers zijn betrokken bij elkaars werkzaamheden. Ik heb dat mooi horen zeggen: rollen verdwijnen, specialismen blijven. Ontwikkelaars hebben echter een prettig voordeel: om te programmeren is technische kennis nodig, die anderen niet gauw kunnen overnemen. Voor testers geldt dat hun kennis voor een groot deel gestoeld is op methoden die binnen Agile maar deels toepasbaar zijn. Testers moeten, als ze niet beschikken over relevante Agile-ervaring, terugvallen op gezond boerenverstand, improvisatietalent en flexibiliteit, maar vinden daarin hun gelijken in ontwerpers en ontwikkelaars. Testers vinden het dus moeilijk om in een Agile-setting de specialist te zijn.
Beperkte aanwezigheid van testbasis
Een derde aspect is dat testers lang strijd hebben gevoerd voor een behoorlijke procesvolwassenheid van requirements, documentatie, versiebeheer, releasebeheer, et cetera. Deels om meer aan de linkerkant van het V-model te kunnen testen, deels omdat documentatie de vanzelfsprekende input was voor een goede test aan de rechterkant van het V-model. Agile zorgt voor een herijking van de wijze waarop deze processen worden ingevuld, onder andere omdat Agile vaak wordt aangegrepen om fors te besparen op de hoeveelheid (en helaas ook regelmatig de kwaliteit van) documentatie. Veel ontwerpers en ontwikkelaars zijn daar niet rouwig om: voor een ontwerper is documentatie slechts een middel om kennis over te dragen, ontwikkelaars zien documenteren doorgaans ook niet als het meest interessante deel van hun werk. Testmethodieken leren testers dat documentatie het fundament van de testspecificatie is. In een Agile-setting moeten testers dus op zoek naar andere manieren om informatie te halen en te toetsen, waarbij de nadruk niet ligt op allesomvattende documentatie, maar op interactie met mensen. Niets zo dynamisch als dat.
En juist in die dynamiek ligt de overlevingskans van de testprofessional. Een van de weinige generieke zaken waarover bijna iedereen het eens is, is het archetype van de Agile tester: een uitgekiende combinatie van de juiste hard skills (een zo groot mogelijke rugzak vol ervaringen en technieken, die je afhankelijk van de context kunt inzetten) en soft skills (adaptiviteit, snel leren en analyseren, vaardig vragen) die nodig zijn om te herkennen welke situatie vraagt om welke tools en technieken.
Dat gaat de komende jaren zorgen voor een survival of the fittest waarin de kanjers zich onderscheiden van de krentenbollen. De kanjers zijn die testers en die werkgevers die bereid zijn zich te verdiepen in nieuwe tools en technieken, die situaties uit de praktijk analyseren, en met elkaar bepalen welke oplossing in welke context nuttig is gebleken, of juist niet. Maar vooral ook die testers en werkgevers die in staat zijn om situationeel mee te veranderen met de vraag.
En ook al zullen de grondleggers van oude methoden graag anders beweren, generiek toepasbare best practices voor Agile testing hoeven we volgens mij voorlopig niet te verwachten.
Goed stuk! Zoals agile methodieken door hun korte feedbackloops pijnlijk duidelijk maken of aan de doelstelling van de (SMART) business case kan worden voldaan, maakt het ook pijnlijk duidelijk dat test professionals zich niet (meer) kunnen verstoppen achter tradiotionele test methodieken en -technieken. Men zal vindingrijk, en out of the box moeten denken over wat de juiste testaanpak in een bepaalde context is. Professionals die enkel een kunstje hebben geleerd zonder de gedachte achter de techniek of het agile gedachtengoed te doorgronden zullen onherroepelijk door de mand vallen.
Beste Peter, ik ben het met je eens dat een (quote) “agile tester een zo groot mogelijke rugzak vol ervaringen en technieken, en soft skills als adaptiviteit, snel leren en analyseren, en vaardig vragen moet bezitten”.
Alleen jouw afsluitende zin begrijp ik niet zo goed. Is het niet zo dat het agile manifesto (4 waarden, 12 principes) zelf niet anders is dan een verzameling best practices? Notabene gebaseerd op ontwikkelmethoden (o.a. RAD, DSDM, XP, FDD) uit de vorige eeuw. En dat organisaties uit een agile aanpak als scrum alleen die aspecten pakken die ze interessant c.q. passend vinden?
Als je dan naar tientallen scrumprojecten kijkt hoe daar met testen wordt omgegaan, zijn er verrassend veel parallellen te ontdekken. Anders gezegd; in veel organisaties/projecten is men voor bepaalde testuitdagingen tot dezelfde oplossingen gekomen.
Denk aan: testautomatisering van de regressietest is gewenst, praat als tester met de product owner om user stories helder (op de backlog) te krijgen en registreer alleen bevindingen als ze niet in 1 dag kunnen worden opgelost, enz.
Dat zou je dan toch de best practices voor agile testen kunnen noemen?
Goed stuk Peter. Het maakt ernstig duidelijk hoe testers vaan Theoretisch zijn opgeleid (mea culpa).
Het wordt nu eindelijk eens tijd om de geleerde technieken en methoden toe te passen in de praktijk van Agile. Maar dat was het in het verleden ook. Ik zie veel Agilisten die zich proberen te verschuilen achten het context driven karakter van Agile, om daarmee aan te geven dat technieken niet meer gebruikt kunnen worden (ik bemerk dat in dit stuk ook weer). Ik vind dit vergelijkbaar met de redenatie, dat de timmerman de hamer wel thuis kan laten, want we hebben tegenwoordig toch veel prefab. Of we hebben toch allang de elektrische schroevendraaier uitgevonden voor dit soort klussen. Natuurlijk onzin, zoals we allemaal weten.
Daarom: De professionaliteit van de tester is niet af te lezen aan de hoeveelheid technieken die hij/zij in zijn/haar gereedschapskist heeft liggen. De professionaliteit zit hem erin dat de tester in staat is het gereedschap te gebruiken en uit te breiden. Die denktrant moet worden bijgebracht in trainingen. Niet de techniek zelf is heilig, maar de manier van denken. Het gaat dan dus niet om theoretisch in de ankers te gaan, vanwege het ontbreken van een testbasis, het gaat er in Agile om, om zodra info vrijkomt, de geleerde manier van denken toe te passen, waardoor er kwalitatief goed getest wordt. Dat aspect mis ik te veel in Agile-discussies.
Hallo Leo,
Dank voor je reactie! Ik denk dat ons verschil in inzicht deels een definitiekwestie is. Voor mij is een ‘practice’ een methode, activiteit, tool, ervaring, techniek die contextafhankelijk in de praktijk inzetbaar is. Ik zie een ´best practice´ als een methode, activiteit, tool, ervaring, techniek, die zich zo generiek bewezen heeft dat deze als benchmark en nagenoeg zonder uitzondering inzetbaar is. Ik ben het in dat opzicht eens met de definitie van het begrip zoals Bach en Bolton die omschrijven.
We zijn het absoluut eens dat er vele testoplossingen zijn die binnen Agile inzetbaar zijn, ik denk echter wel dat het moeilijker wordt om deze oplossingen binnen Agile generiek toe te passen. Dat betekent dat het inzetten van tools en technieken meer sensitiviteit, flexibiliteit en improvisatietalent van de consultant vergt.
Voor mij is het manifesto trouwens noch practice, noch best practice: Het manifesto is een mindset die ik bij het inzetten van practices als leidraad en toetsingskader meeneem.
Peter,
In je stuk schrijf je dat testers, meer dan andere disciplines, worstelen met de uitdaging. Niet alleen testers worstelen hiermee, maar ook architecten, business analysten en projectmanagement.
De rode draad uit je verhaal is voor mij het zoeken naar zekerheden in een agile omgeving. In een agile omgeving bestaan de zekerheden; dit zijn echter andere zekerheden dan in een niet agile omgeving. Ik noem het vooruitzicht dat een gewenst product geleverd wordt binnen een afgesproken tijdspanne. De weg naar het eindproduct is onduidelijk en niet vooraf bepaald.
Mijn advies is, hou het einddoel voor ogen, zoek niet naar de zekerheden over hoe je daar wilt komen maar ga mee met de flexibele weg die je er naar toe leidt.
Wanneer je de switch naar de mindset kunt maken, zul je plezier ervaren in een agile omgeving en zul je als tester ‘overleven’. Mocht je deze switch niet kunnen of willen maken, blijf dan vooral opereren in een niet agile omgeving.