Oude (test)gewoontes zijn hardnekkig bij agile ontwikkeling

Veel organisaties worstelen met de transformatie naar agile en vaak worden oude gewoontes meegenomen naar de nieuwe wereld.

Dat geldt ook voor testen. Is er wel plaats voor een tester in een agile team? Of wordt de tester juist een bottleneck in de nieuwe wereld, waar alles sneller, beter en van hogere kwaliteit moet zijn?

Anti-patronen

Uit de oude gewoontes van waterval-projecten zijn een aantal anti-patronen ontstaan. Patronen die ervoor zorgen dat het bouwen van software binnen agile-omgevingen juist nìet versnelt en als bottleneck gezien wordt. Bij bedrijven als als Atlassian en ING zijn testers hierdoor ontslagen. In deze blog beschrijf ik de drie anti-patronen die ik het meest tegenkom in organisaties.

De test lane op het KanBan board

De Testing Lane op het KanBan board, waar de taken van links naar rechts gaan en dus uiteindelijk alles naar rechts op ‘done’ moet komen te staan is een prima systeem. Lekker overzichtelijk, je ziet wat getest is en wat nog getest moet worden. Niks mis mee denk je? Zeker wel! Met een aparte lane voor testen maak je van testen juist weer een fase. Na het bouwen: testen, maar dan mis je een belangrijk doel van testen binnen agile, namelijk ‘fast feedback’ geven.

De testing lane kan soms ook net een iets andere betekenis hebben en gebruikt worden voor een gebruikers-acceptatietest (soms ook als review lane terug te vinden). Ook dan vind ik het geen goed idee, omdat stories dan lang op het bord blijven hangen en iets nog niet af is zonder deze aparte fase. Hiermee werk je agile dus juist tegen!

Is de tester nog nodig?

Heb je een test lane, dan moet je ook een tester binnen het team aanwijzen, zodat deze persoon al die taken oppakt en zorgt dat ze verdwijnen. Nu ben ik er uiteraard niet op tegen dat testers in een team zitten, maar ze moeten niet alleen maar testen in dat team. Met een tester in het team worden andere teamleden vaak kwaliteitslui. Zij denken: de tester vindt de fouten toch wel. Is de kwaliteit slecht dan wordt de tester erop aangekeken. Dat ondermijnt een ander belangrijk principe: het gehele team is verantwoordelijk voor kwaliteit.

Testautomatisering

Naar testautomatisering wordt ook vaak vanuit een traditionele gedachte gekeken. Wij testers beginnen vaak met automatiseren. Prima, maar vaak gebeurt dit op UI niveau met tools als Selenium. Niet goed? Wel, maar dat kan beter.  Deze testen zijn namelijk traag en daarnaast geen ‘Fast Feedback’ voor de ontwikkelaars. Als je testen automatiseert moet je kijken naar de mogelijkheden om dat eerder te doen. Daarbij denk ik aan: Unit- of Integratie-testen. Dus lekker samenwerken met de ontwikkelaar. Of is er een andere oplossing?

Meer weten over hoe je de patronen kunt doorbreken?

Hoe je de beschreven patronen het  beste doorbreekt, vertel ik op basis van mijn ervaringen als Agile Test Consultant tijdens de TMap Dag 2016 op 6 oktober 2016. Ben je nieuwsgierig naar onderwerpen als Agile en DevOps, bezoek dan zeker de stream ‘NextGen Testing’ waar mijn sessie in valt.