Waarom agile testen andere aanpakken vraagt
Agile is al lang geen nieuwigheid meer. De meeste softwareteams werken iteratief, in sprints, met dagelijkse samenwerking. Jongere collega's kennen geen andere manier. En toch hoor je in testgesprekken nog steeds termen die thuishoren in de watervalwereld van de jaren negentig.
Dat is niet vreemd. Wat generaties lang werkte, verdwijnt niet vanzelf. Maar het is wel een probleem.
Hoe we hier zijn gekomen
In de watervalperiode had de testwereld zijn eigen infrastructuur. Mastertestplannen, het V-model, testfasen per projectfase, methodieken zoals TPI en TMM om testprocessen te verbeteren. Er was zelfs een discussie over een W-model als verfijning. Het was een volwassen aanpak, voor een context waarin software projectmatig werd gebouwd, fase na fase, met een aparte testfase aan het eind.
Agile veranderde die context fundamenteel. Software wordt iteratief gebouwd, teams zijn zelfsturend, de klant is continu betrokken en feedback is direct. De vraag is wat er van de oude aanpak in deze context nog waarde heeft.
Wat niet meer past
Sommige concepten zijn zo sterk verbonden aan de watervalaanpak dat ze in een agile context niet goed werken, of ronduit wringen. Een mastertestplan dat de hele testaanpak voor maanden vooruitschrijft, past niet in een omgeving die juist op verandering inspeelt. Logische en fysieke testgevallen die volledig zijn uitgeschreven voordat de bouw begint, zijn al verouderd tegen de tijd dat je ze uitvoert.
Hetzelfde geldt voor rollen als testmanager en testcoördinator die buiten het team staan, voor non-functionals die pas laat in het traject worden getest, en voor regressietesten die als aparte fase worden ingepland in plaats van als doorlopend onderdeel van elke sprint. En de gebruikersacceptatietest als grote poort voor livegang: in een watervaltraject logisch, in een agile aanpak een rem op de feedback die je juist vroeg nodig hebt.
De termen zijn bekend, maar de context waarin ze zin hadden, bestaat voor de meeste teams niet meer.
Wat agile testen wel vraagt
Testen in een agile context is geen afgeslankte versie van traditioneel testen. Het vraagt een andere mindset. Kwaliteit is niet een fase aan het eind maar een doorlopende verantwoordelijkheid van het hele team. De tester denkt mee in refinements, stelt vragen bij user stories voordat de bouw begint, en test parallel aan de ontwikkeling.
Testautomatisering is daarin geen optie maar een voorwaarde. Zonder geautomatiseerde regressiechecks is het onmogelijk om in elke sprint met vertrouwen op te leveren. Exploratory testing vult aan wat automatisering niet dekt: het onverwachte, het randgeval, het gedrag dat niemand heeft voorzien.
Agile werken betekent ook loslaten. Niet alles wat ooit nuttig was, is dat nog. Teams die daar het scherpst in zijn, zijn ook de teams die het snelst en betrouwbaarst opleveren.
