administrator

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 ervaring¹En 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.

24 januari 2018, eerder verschenen op TeamKPN

Bij het realiseren van geautomatiseerde CI/CD straten in onze DevOps teams ontstaat met regelmaat discussie over wat de verhouding moet zijn tussen de hoeveelheid (automatisch uitvoerbare) unittesten die door de developers met hun code wordt meegeleverd, het aantal geautomatiseerde UI-testen die door de testers, soms geholpen door developers, moeten worden gemaakt en welke testen er na het realiseren van de software nog met de hand moeten worden uitgevoerd.

Vanuit een kwaliteits- en effectiviteitsprincipe is een balans tussen snel aan te trappen geautomatiseerde testen en bedachtzame, maar vertragende handmatige testen, van levensbelang. Te veel automatiseren legt een te zware wissel op de inspanningen van het DevOps team, maar te weinig automatiseren levert een blokkade op de voortgang in de geautomatiseerde CI/CD-straat op.

Onderdeel van de balans vormt het doel van de testen: hierbij zou de kans op het vinden van fouten centraal moeten staan. Voor de 12e keer handmatige high-level regressietesten uitvoeren levert over het algemeen weinig op, terwijl tienduizend low-level unittesten geen enkel uitsluitsel over de bruikbaarheid van de UI hoeven te geven.

De pyramide van Martin Fowler, auteur van het boek Continuous Delivery, heeft precies dit doel: aanduiden dat een balans tussen ‘grote klappen, snel thuis’-geautomatiseerde UI-testen en ‘muizekeutels-op-het-tapijt’-unittesten, aangevuld met ‘sherlock-holmes’-procestesten van ‘utmost importance’ is voor een levensvatbare CI/CD-straat. Dat er idealiter veel meer snelle, doeltreffende geautomatiseerde low-level testen zijn dan procesblokkerende, handmatig uit te voeren procestesten staat buiten kijf, al was het alleen al dat er veel meer low-level testen nodig zijn om dezelfde dekkingsgraad te bereiken als met high-level testen.

In termen van kosten zit er weinig verschil tussen het maken van een UI-test en het maken van een unittest. Je zou daarom zeggen dat geautomatiseerde UI-testen het minst kosten. Op de lange termijn is dat wel zo in vergelijking met (steeds dezelfde) handmatig uit te voeren testen, maar juist niet ten opzichte van unittesten: het onderhoud aan unittesten is eenvoudiger dan het onderhoud aan UI-testen. Unittesten lijken echter problematisch te ontwikkelen zodra ‘coverage’ onderdeel van de kwaliteitsmaatstaf wordt: kwantiteit lijkt dan te prevaleren boven kwaliteit.

Het bereiken van een balans tussen de hoeveelheid en creatietijd van high-level en low-level testen is een holistisch proces, dat afhangt van de mate waarin aan bepaalde criteria wordt voldaan:

• Beschikbaarheid van voldoende gemotiveerde teamleden voor het ontwikkelen van geautomatiseerde UI-, API- en unittesten;
• Kwaliteit en hoeveelheid van de beschikbare geautomatiseerde testen;
• Behoefte aan volledig geautomatiseerde testuitvoering na merge, build, deploy of releasen van software;
• Aard en omvang van de aanpassingen;
• Stabiliteit van de software;
• Mate waarin het team T-shaped is en de teamleden elkaars werk kunnen ondersteunen.

In de praktijk blijkt een gezonde DevOps werkomgeving een positieve stimulans te geven op de snelheid waarmee een pragmatische balans wordt bereikt tussen ‘zware high-level testen’ en ‘lichte low-level testen’. Een balans die evenwel iedere sprint opnieuw moet worden bekeken om gaten die bijvoorbeeld ontstaan in de vorm van technical debt, op te sporen.