Handig omgaan met testautomatisering in sprints

8 juni 2018

Wie als testautomatiseerder verantwoordelijk is voor het programmeren van de geautomatiseerde UI testen in een sprint loopt vaak tegen het feit aan, dat de software waarvoor de testen geautomatiseerd moeten worden pas laat in de sprint beschikbaar komt. Dat maakt de beschikbare tijd om te testautomatiseren onvoldoende om er nog iets zinvols van te maken. We zien hiervoor in de praktijk verschillende oplossingen: de sprint voor de testautomatiseerder wat langer maken, de sprint voor iedereen langer maken, testautomatisering beperken tot het meest noodzakelijke om toch te sprint door te komen of, en dat heeft onze voorkeur, de testautomatisering niet in dezelfde sprint realiseren als waarin de software wordt opgeleverd.

De reden voor de testautomatisering is niet, om de huidige sprint versneld door te komen. De reden voor de testautomatisering is, om de ontwikkelaars in staat te stellen vaak en snel op te leveren en de beschikbare regressietesten, met één druk op de knop, op een willekeurig moment te kunnen opstarten. Het helpt daarom enorm om een betrouwbare, omvangrijke regressietest te hebben, die automatisch in de CD/CD straat wordt aangeroepen. De testautomatiseerder voegt daar met regelmaat de nieuwste testen aan toe. Echter, testautomatisering volgt, maar loopt nooit voor op, door een testprofessional ontworpen testen. En deze testen worden gebaseerd op documentatie, proces, software of ervaring1En we weten onderhand dat proces (het beoogde gebruik van de software) en de software zelf (werken alle zichtbare functies, werkt het in vergelijking met de vorige versie goed), gecombineerd met de ervaring van de tester, hierbij het meest van belang zijn..

Om opgeleverde software goed te kunnen testen moet de tester er de nodige tijd mee kunnen doorbrengen, op ideeën komen, testen uitvoeren, situaties klaarzetten, onderzoek doen, overleg plegen, bevindingen rapporteren. In niet-agile trajecten kon dat ruim van tevoren aan de hand van uitgebreide functionele specificaties, maar nu moet dat op het oplevermoment zelf gebeuren.

De ontwikkelaars hebben, als het goed is, zelf de geautomatiseerde regressietesten al gedraaid en eventuele regressiefouten hersteld. Ook hebben zij, hopelijk, de regressietesten aangepast, als deze omwille van de aangepaste software niet meer de juiste resultaten leveren. Maar het wachten is nu op het woord van de tester.

Die tester kan, in plaats van bezig te zijn met de geautomatiseerde testen, beter doen waar hij het team het meest mee helpt en dat is testen ontwerpen en uitvoeren. Dat doet hij dan bij voorkeur ‘met de hand’ en maakt hiernaast een lijstje met aangepaste, en nieuwe testen. Dit lijstje wordt in één nieuwe user story gezet, die heet ‘Aanpassingen aan de geautomatiseerde regressietest naar aanleiding van sprint <huidige sprint>’. Deze user story bevat alle aan te passen en te vernieuwen testen in de geautomatiseerde regressietest en wordt bij de eerstevolgende refinement door het team ingeschat op punten. Omdat de user story binnen het hele team wordt besproken wordt de draagvlak voor het aanpassen van deze testen groter, en kan een grotere groep hieraan bijdragen. Het is voor de product owner ook altijd inzichtelijk, wat er moet gebeuren.