Het belang van automatisch software testen in een DevOps wereld

Pascal vierkantGeschreven door Pascal Widdershoven op 2-3-2022

DevOps gaat primair om het versnellen van software delivery. In de tijd waarin we leven is Time To Market uitermate belangrijk. De wereld om ons heen verandert razendsnel (wie had begin 2020 gedacht dat we minstens twee jaar in een pandemie zouden verkeren?) en software moet net zo snel mee kunnen veranderen.

脡茅n van de manieren waarop in de DevOps gedachte software delivery versneld kan worden is door het automatiseren van het complete software delivery process (Continuous Delivery). Een code wijziging zou zonder handmatige stappen, volledig geautomatiseerd naar de productieomgeving uitgerold moeten kunnen worden.

Voor moderne applicaties die ontwikkeld zijn met deze principes in gedachte, is het relatief eenvoudig om dit soort automation op te zetten. Er is tegenwoordig veel tooling beschikbaar die hierbij helpt. Containerization en Kubernetes maken dit makkelijker dan ooit tevoren.

Mooi, we kunnen het deployment proces technisch gezien dus vrij eenvoudig automatiseren. Maar hoe zorg je ervoor dat de wijzigingen die je op deze manier binnen no-time van development naar productie doorzet ook daadwerkelijk goed zijn? Met deze nieuwe manier van werken wordt het immers 贸贸k eenvoudig om bugs binnen no-time op je productieomgeving te krijgen. Niet zo handig :-).

Test automatisering als onderdeel van het development process

Een oplossing voor dit probleem is, geheel in lijn met de automate everything gedachte van DevOps, om het testen van je software te automatiseren. Veel teams passen al Continuous Integration toe, waarbij er bij elke wijziging van de software een aantal automatische checks uitgevoerd worden. Vaak beperkt dit zich echter tot checks op code stijl en code kwaliteit, maar ontbreken tests waarmee de werking van het systeem aangetoond kan worden.

Er zijn verschillende manieren om het testen van software te automatiseren, maar de meest krachtige is naar mijn mening om het geautomatiseerd testen onderdeel te maken van het software development proces. TDD, Test Driven Development, is een practice waarbij developers voor elke wijziging in code 贸贸k test code schrijven om aan te tonen dat de functionaliteit werkt. Sterker nog, de test wordt geschreven nog v贸贸rdat er ook maar 茅茅n regel productie code geschreven wordt. Dit heeft een aantal grote voordelen:

Snelheid in delivery door vertrouwen in wijzigingen

Het laatste punt is waar het uiteindelijk om gaat. Door de automatische tests kun je met vertrouwen wijzigingen maken aan de software. Als er door wijzigingen per abuis bestaande functionaliteit niet meer werkt (regressie) dan gaan er tests falen en wordt de deployment pipeline vanzelf gestopt. De wijziging zal daardoor niet naar productie gedeployed worden, totdat de functionaliteit weer werkt en de test weer slaagt.

De waarde hiervan is werkelijk enorm. Zowel direct - eindgebruikers krijgen geen niet of slecht werkende software voor hun kiezen, als indirect: de automatische tests geven het ontwikkelteam het vertrouwen om wijzigingen te maken.

Development, TDD, CI, CD process

Onderhoudbaarheid

Moderne software is onderhevig aan constante verandering. Requirements veranderen voortdurend en kunnen ervoor zorgen dat grote wijzigingen aan de structuur van de code nodig zijn. Om snel te kunnen ontwikkelen en om software onderhoudbaar te houden is hergebruik van code cruciaal. Dit betekent dus per definitie dat je voor het toevoegen van nieuwe functionaliteit 贸贸k de code van bestaande functionaliteit moet wijzigen. In software waarbij er g茅茅n of weinig automatische tests zijn worden dit soort wijzigingen meestal niet gedaan, omdat men bang is bestaande functionaliteit kapot te maken. Het gevolg hiervan is dat de software ontwikkeling steeds langzamer gaat en dat de kans op regressie significant toeneemt.

Hoe ga je zonder automatische tests 眉berhaupt merken dat je software niet meer werkt zoals het hoort? Precies, dat gaan je eindgebruikers je vertellen (niet fijn) 贸f je gaat veel handmatig testwerk moeten doen. Dit laatste is nu net wat je wil voorkomen. DevOps gaat immers om snelheid.

DevOps + test automatisering = 馃殌.

Bij Kabisa staat privacy hoog in het vaandel. Wij vinden het belangrijk dat er zorgvuldig wordt omgegaan met de data die onze bezoekers achterlaten. Zo zult u op onze website geen tracking-cookies vinden van third-parties zoals Facebook, Hotjar of Hubspot. Er worden alleen cookies geplaatst van Google en Vimeo. Deze worden gebruikt voor analyses, om zo de gebruikerservaring van onze websitebezoekers te kunnen verbeteren. Tevens zorgen deze cookies ervoor dat er relevante advertenties worden getoond. Lees meer over het gebruik van cookies in ons privacy statement.