Agile testen is niet nieuw meer. Organisaties brengen al jaren nieuwe of gewijzigde software naar productie met een tempo waar je soms van gaat duizelen. Agile ontwikkelen heeft zo’n aantrekkingskracht, dat bedrijven al heel snel beweren ook op deze manier te werken, terwijl de realiteit is dat de betrokkenen gewoon lekker waterval werken. Ze houden de werkzaamheden wel bij op een kanban board in Jira. Ik ken de kracht van agile en beveel het in de juiste context graag aan. Maar ik zie, vooral op het gebied van testen, een valkuil ontstaan die op den duur een bom kan leggen onder het succesverhaal van flexibele software ontwikkeling…
Code heeft voorrang op documentatie
Wat mij betreft de grootste valkuil van agile is dat code voorrang heeft op documenteren. In het manifest staat dat goede code wordt geprefereerd boven uitgebreide documentatie. Dat betekent iets anders dan helemaal geen documentatie. Maar dat is helaas wel wat ik in de praktijk heel vaak zie gebeuren. En juist voor testen is het vastleggen van wat je gaat doen, aan het doen bent en hebt gedaan van groot belang. Het manifest wordt hier bewust (of onbewust) verkeerd uitgelegd. Developers hebben doorgaans onvoldoende ruimte om te documenteren en de tester moet heel stevig in zijn schoenen staan als zij of hij hierop blijft hameren om dit alsnog voor elkaar te krijgen. Het ontbreken van (test)documentatie maakt de uitkomst van testen onbetrouwbaar en werkt op den duur zeer inefficiënt.
User stories
Soms lijkt het team wel op een roedel labradors. Springend van opwinding en vol ongeduld wachten ze op de product owner om te horen wat er deze sprint ontwikkeld mag worden. Voordat er is uitgelegd wat het precies is, begint het team te bouwen. Hoe vaker dit gebeurt, hoe vager de stories worden die de product owner namens de business aan het team voorlegt. Er zijn nog veel meer oorzaken die voor onvoldoende heldere stories zorgen, maar veel van die oorzaken hebben dezelfde achterliggende gedachte. Agile vraagt flexibiliteit van het team en de teamleden kennen het systeem zo goed, dat ze aan een half woord voldoende hebben. En de tester mag de basten in de voegen repareren. Want als er een productie issue is, weten we welke vraag als eerste wordt gesteld…
Testautomatisering
Hallelujah! Testautomatisering wordt over het algemeen als wondermiddel verwelkomd. Of we zeggen dat agile een synoniem is voor automatiseren. Dan komt het vanzelf goed. De werkelijkheid is helaas weerbarstiger. Het automatiseren van tests is en blijft een stap in volwassenheid. Op het moment dat CI/CD van toepassing is, kan het heel sterk werken. Maar als het team met onvoldoende concrete user stories werkt, is de kans nog groter dat ‘garbage’ met een sneltreinvaart naar productie wordt gebracht. En juist in een agile omgeving, waar de tijd in een sprint kostbaar is, moet je goed nadenken waar je als team en dus ook als tester je tijd aan besteedt. Automatiseren kost doorgaans veel tijd en blijft dat ook kosten. Het onderhoud van een geautomatiseerde testsuite wordt in een business case helaas nogal eens over het hoofd gezien.
"Als flexibiliteit te ver wordt doorgevoerd, kan het zijn dat de ontwikkeling van software in de knoop raakt."
Flexibel
De achterliggende boodschap van deze blog? Agile vertaalt naar het Nederlands betekent letterlijk ‘flexibel’. Maar dat slaat nog niet altijd op de methodes van ontwikkelen en testen. Daarmee wordt wel bedoeld, dat een team zo behendig is dat het snel en adequaat in kan springen op een veranderende vraag van de business. De kern van agile voor de werkwijze van een team ligt veel meer in transparantie en voorspelbaarheid. En daarbij speelt juist structuur een belangrijke rol. De tester speelt daarin zelfs een cruciale rol. Als flexibiliteit namelijk te ver wordt doorgevoerd, kan het zomaar zijn dat de ontwikkeling van software in de knoop raakt.
Aan teams de boodschap elkaar daar scherp op te houden. Laat de retrospective daar nou net voor bedoeld zijn. Blijft het lastig om gestructureerd te werk te gaan, kunt u overwegen om eens een gesprek te voeren met een gespecialiseerde partij van buiten de organisatie. Ik weet er nog wel een voor u!
