Over Agile Testen, Agile Test Management, Test Coaching en Test Automatisering
In organisaties waar is gekozen om systeemontwikkeling Agile uit te voeren, ontstaat snel de vraag hoe de kwaliteit van het product inzichtelijk te maken. Hoe te testen. In hoofdlijnen zie je twee uitersten: alles testen in de sprints en volop investeren in het automatiseren van testen, of het testen op de vertrouwde manier blijven uitvoeren als aparte fasen buiten de sprints.
Om te kunnen bepalen wat de meeste effectieve aanpak is, moeten we eerst kijken naar de context van het testen. Testen is het beproeven van een product op verschillende aspecten voor alle betrokken stakeholders van het product. Kern is het woord ‘product’.
Ieder product gaat verschillende fasen door, de zogenaamde ‘product lifecycle’. Deze bestaan uit de volgende fases: onderzoek (research), ontwikkeling (development), introductie, gebruik (met daarbinnen een groeifase, volwassenheidsfase, verzadigingsfase en een teruggangfase) en ontmanteling. In al deze fases kan, en moet, er getest worden, maar het testen ziet er wel anders uit per fase.
Afbeelding 1: Product Lifecycle
Als we Agile werken, willen we de doorlooptijd van de onderzoeks-, ontwikkelings- en introductiefase zo kort mogelijk houden. We willen immers zo snel mogelijk feedback krijgen van de gebruikers. Het kort houden van deze fase helpt ook om de investeringskosten te beperken. Daarom wordt er zo snel mogelijk een ‘Minimal Viable Product’ (MVP) ontwikkeld en uitgerold naar de gebruikers. Afhankelijk van de minimale grootte en de minimale benodigde complexiteit van het te ontwikkelen product, zijn er enkele tot vele ontwikkelsprints nodig voordat we de bruikbaarheid kunnen laten toetsen door de gebruikers. De eerste MVP die dat mogelijk maakt, wordt het ‘Minimal Testable Product’ (MTP) genoemd.
Tijdens de ontwikkelingsfase is het al slim om de te bouwen productfeatures (User Stories / Product Backlog Items) om te zetten naar acceptatietesten en het liefst deze direct te automatiseren om zo al een regressie testsuite op te bouwen. Dit kan een taak zijn van een van de teamleden (een tester of een programmeur), eventueel ondersteund door een Agile Test Coach. Die kan helpen met het introduceren van test-first ontwikkelen, bijvoorbeeld met behulp van TDD (Test Driven Development), ATDD (Acceptance Test Driven Development) en/of BDD (Behaviour Driven Development).
Het laten testen van zo’n MTP door gebruikers vereist enige coördinatie en voorbereiding. We kunnen dit vergelijken met een traditionele GAT (Gebruikers Acceptatie Test). In Agile zullen we het uitvoeren van die testen echter wel anders voorbereiden en uitvoeren. Het door potentiele gebruikers laten testen voor de eerste release is zeker nodig, ook als je Agile ontwikkelt. Dit levert namelijk feedback op die kan leiden tot nieuwe User Stories die op de Product Backlog kunnen. Deze geeft inzicht of de geteste versie van het MVP al voldoende goed is om te promoveren tot ‘Minimal Marketable Product’ (MMP) en deze te releasen naar alle gebruikers. De potentiele gebruikers die de Agile GAT uitvoeren zijn dus essentieel in deze fase.
Vaak is er behoefte aan iemand die deze testsessie coördineert. Iemand die de gebruikers leert hoe testen uit te voeren, bevindingen vast te leggen en de gebruikers helpt om de testsessies effectief af te bakenen ten opzichte van de globale gebruik-scenario’s. Meestal noemen we degenen die dit doet een Agile Test Manager.
Vanaf het moment dat het product een MMP is geworden, en daadwerkelijk wordt gebruikt door de gebruikers, ontwikkelt het ontwikkelteam door. Het product is dan in de introductie- en gebruiksfase. Feedback van gebruikers komt dan via de Product Owner op de Product Backlog terecht. Om zeker te stellen dat eerder opgeleverde functionaliteiten blijven werken bij volgende opleveringen, is het hebben van een goed dekkende regressietestsuite onmisbaar. De eerder ‘investering’ daarin betaalt zich nu terug.
In de gebruiksfase moeten ook incidenten adequaat worden opgepakt en resulteren in acties om herhaling te voorkomen. Dan wordt het raadzaam om de (vaak aanwezige) afstand tussen beheerders en ontwikkelaars van het product te verkleinen, en over te gaan naar het invoeren van DevOps (Development en IT Operations samen in één team).
Als de keuze is gemaakt om via DevOps te werken, kunnen ook de testen die vanuit beheerperspectief nodig zijn worden geautomatiseerd. In dat stadium zullen concepten zoals ‘Continuous Integration’ en ‘Continuous Delivery’ worden geadopteerd. Als dat goed is ingeregeld gaan de ontwikkel- en beheerkosten omlaag en kan er worden geïnvesteerd in het ontwikkelen van een nieuwe product, voordat het huidige product via de teruggangsfase in de ontmantelingsfase belandt. In die ontmantelingsfase kan, afhankelijk van het soort product, weer coördinatie nodig zijn om zeker te stellen dat het product succesvol wordt verwijderd. Meestal is dat zowel project- als testmanagement.
Afbeelding 2: Adaptief Agile Testen
Testen uitvoeren en coördineren vinden we dus in alle fasen van een product terug, ook als er op een Agile wijze wordt ontwikkeld. Maar wie die testen uitvoeren en hoe die testen eruit zien is afhankelijk van de fase waar het ontwikkelproces zich bevindt, de context van het product en de volwassenheid van de ontwikkelteams. Om de ontwikkelsnelheid te vergroten, om zo snel mogelijk feedback te krijgen, is het essentieel om zoveel mogelijk te testen in de sprints zelf en daarom ook om te investeren in het automatiseren van testen.
Om te kunnen bepalen wat de meeste effectieve testaanpak is moet dus goed gekeken worden in welke fase van de ‘product lifecycle’ het product zich bevindt: Adaptief Agile Testen.
Jaap Schuttevaer, 7 november 2016