Automatiseren met CI en CD

Door middel van CI worden veranderingen in software direct geïntegreerd en vindt direct een integratie test plaats, zodat de integratie bewezen is. Zo is de code altijd in de juiste staat om op te leveren en elk type wijziging kan snel en veilig naar productie gebracht worden. Op deze manier wordt ‘waste’ in de vorm van werkvoorraad geminimaliseerd. De wijzigingen in productie kunnen kleiner gehouden worden en hebben minder impact op de bestaande software. CD focust op het geautomatiseerd overbrengen van software naar omgevingen, waardoor het mogelijk is om met één druk op de knop software naar productie te brengen en met als doel: sneller, sneller, sneller. Met CI/CD automatiseer je het gehele build-, test-, deploy- en releaseproces waardoor een korte time-to-market gerealiseerd wordt. Logisch dat steeds meer organisaties gebruik willen maken van delivery pipelines.

De impact op testen

CI/CD, delivery pipelines, kleinere wijzigingen, minder impact, software in een hoog tempo en geautomatiseerd opleveren: dat klinkt veelbelovend. Maar wat betekent dit eigenlijk voor de tester? Hoe voorkom je dat de delivery pipeline een efficiënte manier wordt om fouten naar productie te brengen? Hoe zorg je ervoor dat je nog steeds de juiste risico’s afdekt? Hoe zorg je ervoor dat je je team en de omliggende organisatie meeneemt in de totstandkoming van de delivery pipeline? Hoe krijg je de gewenste feedback?

Exploration track CI/CD delivery pipeline

Om een antwoord te geven op al deze vragen hebben we binnen Bartosz een exploration track georganiseerd en in deze blog deel ik graag de bevindingen daaruit. Hoe kunnen wij als tester meedenken bij de totstandkoming van een delivery pipeline? Hebben wij tips, adviezen, aandachtspunten? Met een groep Bartoszians zijn we een aantal avonden bijeengekomen om over dit onderwerp te brainstormen. Wat weten we van delivery pipelines? Wanneer de klant aan ons vraagt om mee te helpen bij het inrichten van een CI/CD delivery pipeline, wat kunnen we dan betekenen? Bij onze opdrachtgevers hebben we inmiddels veel ervaring opgedaan met het opzetten, inregelen en onderhouden van CI/CD delivery pipelines. Met elkaar hebben we dit op procesmatige wijze in kaart gebracht. Zowel voor een simpele webapplicatie als voor een complex systeem. Bovendien zijn we zelf hands-on aan de slag gegaan met het ontwerpen en bouwen van een pipeline. Inclusief het technische gedeelte.

Hoe veranderen de testwerkzaamheden?

1. Vroeger testen

Bij CI/CD wordt code meerdere malen per dag geïntegreerd, gebuild en getest. Dat zorgt ervoor dat je als tester in staat bent om nog vroeger in het ontwikkelproces meetpunten van kwaliteit in te bouwen. Je wacht immers niet meer tot de volledige functionaliteit opgeleverd wordt, maar kunt tussenproducten beoordelen, regressie in de gaten houden en bijsturen indien nodig. Door de juiste testen te selecteren in je build en integratie deel van de pipeline, krijg je vroeger een beeld van de kwaliteit van het op te leveren product.

2. Testautomatisering

CI/CD leidt tot het automatiseren van een groot deel van je testen. Maar welke testen ga je automatiseren en waar voer je die uit in je pipeline? Breng hiervoor je pipeline in beeld door met je team te bespreken wat de Definition of Done is. Bepaal vervolgens wat er in elke fase opgeleverd moet worden en ga deze activiteiten automatiseren. Uiteraard weten wij testers hoe en wat we willen testen, maar er is nu ruimte voor extra afwegingen. Het kritisch kijken naar overbodige en dubbele testen bijvoorbeeld en dus het reduceren van “waste”. Maar ook is het mogelijk om aan de hand van wijzigingen die gedaan worden te bepalen welke testen relevant zijn. Als je alle testen die je in je project uitvoert standaard automatiseert en in je pipeline stopt, zal je pipeline al snel verstopt raken. Je kunt intelligent de testen selecteren die je moet draaien, door bijvoorbeeld te kijken naar de inzet van AI. Wordt de pipeline gebruikt om de software ook volautomatisch naar productie te brengen, realiseer je dan dat er buiten je geautomatiseerde testen geen handmatige controles meer in je pipeline zitten en je geautomatiseerde tests dus de enige gatekeepers zijn om te voorkomen dat fouten naar productie gaan.

3. Test fasering

In de traditionele testfasering voer je sequentieel de testen in volgorde uit: unit tests, unit integration tests, system tests, acceptance tests. In een delivery pipeline is er geen enkele reden om testen die je veel inzicht geven, maar traditioneel later in het testproces zitten, niet eerder uit te kunnen voeren. Als er tijdens een project vaak blijkt dat een omgeving of database niet beschikbaar is, dan kan het waardevol zijn daar eerst een test voor uit te voeren om te voorkomen dat allerlei testen uitgevoerd worden maar falen omdat deze component niet beschikbaar is. Fail fast!
Niet alle testen hoeven of kunnen in de pipeline, dan raakt deze verstopt. Je kunt ook testen uitvoeren buiten de pipeline, zeker als er afhankelijkheden zijn met een ander project, of bij testen die erg lang duren. Toepassen van shift left (dichter tegen de ontwikkelaar aan) of shift right (testen in productie) behoort ook tot de mogelijkheden.

4. Tooling

Elk project kent zijn eigen platform, programmeertaal en voortbrengingstools. Het is aan te raden om met je test tools zoveel mogelijk aan te sluiten op de omgeving. Kies bijvoorbeeld voor complementaire tools als Karma die unit testen voor een javascript frontend kan uitvoeren, zonder dat daarvoor nog naar de user interface zelf hoeft worden gekeken. Programmeren de ontwikkelaars in Java? Kies dan voor een java based test tool als JUnit voor unit tests en Fitnesse of Robotframework voor acceptatie testen. Er is geen 1 tool te kiezen waarmee je alles test. Zoals Abraham Maslow’s law of instrument al zegt: “if all you have is a hammer, it is tempting to treat everything like a nail”. Er zijn veel verschillende testtools voor veel verschillende soorten tests; maak gebruik van de specifieke kracht van de diverse tools.

CI/CD maakt testwerk uitdagender

De transitie naar CI/CD maakt testwerk uitdagender. Het geeft jou als tester de kans om je eens te verdiepen in andere zaken. Treed buiten je comfortzone! Iedere pipeline is uniek en de situaties bij de klant is steeds weer anders. Jij als tester kunt meebewegen. Het is een lange reis naar een volledige CI/CD-pipeline die agile opgepakt kan worden en daar spelen testers een belangrijke rol in. Een goede CI/CD pipeline neemt veel repetitief werk bij de tester uit handen die daarop tijd vrij kan maken om aan exploration te doen; je kunt immers alleen automatiseren wat je weet en waarvan je het gedrag kunt voorspellen. Als tester is het extra interessant om te onderzoeken hoe de applicatie zich gedraagt in situaties die niet zijn voorzien of beschreven.