Agile: testers op zoek naar vaste grond

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.