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.