DevOps: to test or not to test

| Remco van Aarst over DevOps en Continuous Delivery.

Nieuwe test- en ontwikkelmethodes veranderen de rol van de tester. Remco van Aarst begon zijn carrière in Waterval, zag de opkomst van Agile en kijkt nu naar het nieuwe DevOps en de trend naar Continuous Delivery.

Als tester heb ik het zelf allemaal meegemaakt. Toen ik als senior tester/testcoördinator begon bij mijn huidige opdrachtgever - het was toen 2011 - werkte men nog volledig met projectmatige releases. Eind 2011 maakten wij een start met Agile. Het idee was om met Agile de doorlooptijd van software-ontwikkeltrajecten te verkorten en daarmee ook de kosten terug te dringen. “More money for your buck”, was het credo. Het gevolg hiervan was dat diverse disciplines binnen de IT-afdeling, maar ook IT en Business, steeds meer naar elkaar toe zijn gaan groeien. DevOps lijkt zich nadrukkelijk voort te bewegen op dit pad.

“Eat your own dogfood” met DevOps
Binnen Agile werkte men meer dan ooit samen. Maar omdat meerdere teams wijzigingen doorvoerden in dezelfde software en er vrijwel geen afstemming hierover was tussen de diverse teams, was er soms ook geen duidelijk beeld van de kwaliteit van de software door de organisatie heen. In Agile was het uiteindelijke beheer van de software nog steeds ondergebracht bij een los beheerteam, dus de problemen die de beheerders op hun bord kregen, gingen voor een groot deel langs het ontwikkelteam heen. Om meer grip te krijgen op het ontwikkelproces en op de kwaliteit van de software is mijn opdrachtgever in 2013 overgestapt naar ontwikkelen volgens de DevOps-methode. Bij DevOps worden ontwikkeling en beheer – de naam zegt het al – samengevoegd in één team. Hierdoor heeft de tester, meer dan bij Agile, zicht op en verantwoordelijkheid voor de ontwikkeling en het beheer van de software. Alle feedback vanuit de business na het “in productie brengen”, komt dus ook direct terecht bij het team en de teamleden zijn ook verantwoordelijk voor het oplossen van incidenten en problemen. Bij ons wordt dit omgeschreven als “eat your own dogfood”. Met andere woorden: een fout in de software krijg je als team vrijwel gelijk weer terug op je bord om op te lossen.

Continuous Delivery
De stap naar DevOps heeft ook bijgedragen aan een veranderde manier van testen. Het testen begint binnen DevOps in een nog eerder stadium dan bij Agile/Scrum. De eerste testen vinden vaak al plaats in samenspraak met de ontwikkelaar. Zijn unittesten worden automatisch uitgevoerd op het moment dat er een deploy van de code wordt gedaan. Ook werken wij met smoketesten, waarbij de stabiliteit van een software component heel snel kan worden getest, ingericht op zowel een test- als op een productieomgeving. Er wordt binnen DevOps ook – meer dan voorheen – gebruik gemaakt van geautomatiseerde regressietesten. Hiervoor worden tools gebruikt als UFT/QTP en RIT. Het automatiseren van het software ontwikkelproces resulteert in het sneller kunnen leveren van software die voortgekomen is uit een proces met lagere kosten en in het sneller kunnen inspelen op vragen van de klant. Het automatisch compileren, testen en deployen en dus continu kunnen leveren zonder overdrachtsmoment wordt ook wel Continuous Delivery genoemd. Deel-oplossingen heten Continuous Integration. Onder Continuous Integration (CI) verstaan wij snelle, geautomatiseerde deployments van de ene omgeving naar de andere. Continuous Integration geeft de mogelijkheid om snel de kwaliteit van de nieuwe software te testen en te toetsen. Continuous Delivery (CD) hanteert min of meer hetzelfde principe, maar gaat nog een stap verder. In Continuous Delivery wordt zeer frequent, in zeer kleine batches, software-onderdelen in productie genomen. Soms zelfs meerdere keren per dag. Feitelijk is er een volledig geautomatiseerde gang naar productie, zonder menselijk ingrijpen. Alle stappen worden volautomatisch getest in een framework dat de belangrijkste risico's opvangt. En mocht er iets doorheen glippen dan zijn de updates zo klein dat de impact van een fout vaak nihil is.

Meer dan in Agile wordt er in DevOps – althans, in mijn ervaring - gebruik gemaakt van een risico-analyse om te bepalen hoe en of er getest moet worden. Op basis van deze risico-analyse in wordt er met het gehele DevOps team bepaald wat het risico is van het beschikbaar stellen van de nieuwe of gewijzigde functionaliteit, mocht er fout in de software blijven zitten. De uitkomst bepaalt hoe en of er getest zal gaan worden. In Agile is men soms nog iets meer geneigd om de risico- analyse achterwege te laten en gewoon uitgebreid te gaan testen. Je wilt niet het risico lopen een ander team met incidenten op te zadelen die door jouw opgeleverde software zijn veroorzaakt. In mijn beleving zie je in DevOps ook steeds vaker dat er slechts in beperkte mate wordt getest en soms zelfs helemaal niet. Dit is in mijn ogen een goede ontwikkeling, omdat je hiermee geen “overbodig” werk doet en dus sneller aan de wensen van de klant kunt voldoen en je de kosten laag kunt houden. Op dit moment zijn we, binnen het team waarin ik werk, nog niet zover dat we Continuous Delivery volledig hebben ingericht, maar we bewegen er wel langzamerhand naar toe.

Multidisciplinaire teamleden
Voor mijn persoonlijke ontwikkeling heeft DevOps ook positieve gevolgen gehad. Binnen de DevOps metode moet iedereen binnen het team in staat zijn om de rol van een ander (tijdelijk) over te nemen om zo het resultaat van de doelstellingen te kunnen blijven waarborgen. Bij mijn huidige opdrachtgever heeft men in dit opzicht aangegeven dat iedereen in een team multi-disciplinair moet zijn. Men wil T-shaped engineers. Concreet houdt dit in dat iedereen meerdere rollen binnen het team zou moeten kunnen uitvoeren. De gevolgen van deze eis voor mijzelf zijn dat mijn expertise (uiteraard) blijft bij het testen, maar dat ik mijzelf ook het beheerwerk eigen aan het maken ben. Om dit te kunnen realiseren wordt er veel aan kennisdeling gedaan, binnen (en buiten) het team. Ook in dit opzicht is DevOps iets dat je doet met elkaar.