De utopie van testautomatisering

‍Een van de grootste uitdagingen bij het implementeren van een continuous delivery pipeline is ervoor te zorgen dat er adequate testautomatisering is. In dit blog zoomen we in op een onderdeel van feature branching genaamd, Test On Demand. Want zelfs als je de continuous delivery pipeline hebt geautomatiseerd, is vaak de uitdaging: Hoe beheer je de testinfrastructuur en -omgevingen zo efficiënt mogelijk en kan ik nog sneller nieuwe features bij mijn gebruikers krijgen?

Alles moet sneller en efficiënter

Continuous Delivery - een softwareontwikkelmethode met als doel updates en nieuwe features zo snel en efficiënt mogelijk in productie te krijgen - is een hot topic waarin eindeloos gediscussieerd wordt om apps en applicaties veiliger en sneller in de handen van gebruikers te brengen. Door features te ontwikkelen in eigen feature branches draagt dit bij aan een nog kortere time to market, aangezien je niet op je collega ontwikkelaar hoeft te wachten.

Het is gebruikelijk, voor softwareontwikkelaars en DevOps-teams, om scripts te schrijven die automatisch omgevingen en infrastructuur inrichten en beheren. Als je tijdens dit proces ook nog eens rekening houdt met meerdere cloud providers (AWS, Azure, etc) kun je snel schakelen wanneer nodig en minimaliseer je de kans op een zogenaamde vendor lock-in. Wat echter vaak een uitdaging is voor deze teams, is het geautomatiseerd testen op een dedicated testomgeving.  Als we kijken naar het brede plaatje zou je kunnen zeggen dat de ideale wereld van testautomatisering er als volgt uit zou zien:

·         Omgevingsdefinities worden bepaald door tools zoals Ansible, Terraform, Marionet of Chef. De inrichtingsscripts zijn vastgelegd voor bronbeheer en versiebeheer, dus je kunt indien nodig teruggaan naar een eerdere status.

·         Al je tests zijn geautomatiseerd met services zoals Selenium, WebDriver, enz.

·         Je hebt een volledig geautomatiseerde implementatiepijplijn. In deze pijplijn wordt automatisch een productie-achtige testomgeving op gang gebracht voor elke codewijziging. Als alle tests slagen, kunnen de wijzigingen naar productie en wordt de testomgeving vernietigd. Als tests mislukken, worden de juiste mensen op de hoogte gebracht en wordt de testomgeving live gehouden zodat iemand de fouten kan debuggen.

Het verschil tussen On Demand en traditioneel testen

Als we inzoomen op de derde stap: het On Demand opstarten van testomgevingen en het automatisch vernietigen ervan. Krijgt het ontwikkelteam hiermee de mogelijkheid om geautomatiseerd unieke testomgevingen te creëren, gebaseerd op de laatste versie van de applicatie. In deze testomgevingen kunnen ze hun nieuwe features automatisch laten testen, voordat deze nieuwe features worden geïmplementeerd in productie. Het mooiste hieraan is dat dit kan zonder dat de lopende werkzaamheden van andere teamleden worden geblokkeerd. De testomgeving wordt vernietigd zodra de ontwikkeling van de feature is voltooid. Zo heb je altijd een schone, productieklare omgeving die op elk moment naar productie kan worden gezet.

Het grote verschil met traditioneel ontwikkelen is dat nieuwe features niet eerst opgestapeld worden in een OTA-omgeving wachtend totdat alle features klaar zijn om vervolgens te worden vrijgegeven aan de productie. Kortom, met Test on Demand kunnen ontwikkelteams sneller werken met minder risico.

Hoe zit het met kosten en resources?

Een andere uitdaging bij het implementeren van een end-to-end Continuous Delivery- pipeline is ervoor te zorgen dat er voldoende resources voor (de) testomgeving(en) zijn. En zelfs als je de hele testomgeving hebt geautomatiseerd, is er een tweede uitdaging: hoe beheer je de testinfrastructuur en -omgevingen zonder dat dit ten koste gaat van je ontwikkelcapaciteit, beschikbare uren voor ontwikkeling van beveiligingsupdates en nieuwe features? Kortom: Hoe hou je zicht op het financiële aspect? Bij veel cloud providers betaal je voor elke seconde dat je resources gebruikt. Als een testomgeving onnodig of zelfs continu online blijft is dit een behoorlijke kostenpost. Het daarom ideaal dat je alleen een testomgeving beschikbaar hebt wanneer deze nodig is en ook weer verdwijnt als deze niet meer nodig is. Dit leidt uiteindelijk tot een aanzienlijke besparing.

Conclusie

Door het concept van Test on Demand te gebruiken hoef je je geen zorgen te maken dat niet geteste features per abuis in productie worden gezet, omdat alle features die worden samengevoegd tot de productie al automatisch zijn getest en gecontroleerd. De testomgeving wordt ook automatisch vernietigd. Zo ga je efficiënt met je resources om, aangezien je alleen resources gebruikt op het moment van testen. Met Test on Demand kunnen softwareontwikkelaars en DevOps-teams zich blijven uitdagenen altijd blijven voldoen aan de steeds kritischer wordende eisen van je gebruikers en kosten besparen.

Voordelen op een rijtje:

-          Snellere time-to-market

-          Geen afhankelijkheid van andere ontwikkelaars, product owners, beschikbare resources om functies vrij te geven.

-          Productkwaliteit verhogen.

-          Geeft de mogelijkheid om experimenten uit te voeren in geïsoleerde omgevingen

-          Hotfixes hoeven de builds in de staging-omgeving niet te overschrijven of andere ontwikkelingswerkzaamheden te blokkeren.

-          Geen aparte testinfrastuctuur.

-          Gelukkigere ontwikkelaars en eindgebruikers