De waarde van testautomatisering

Testautomatisering is niet meer weg te denken in hedendaagse software-ontwikkeling. Om het ontwikkeltempo bij te kunnen houden moeten testen geautomatiseerd worden uitgevoerd en dan nog liefst zo vroeg mogelijk. Dit is een concrete invulling van de “shift to the left” beweging waarbij testen zo vroeg mogelijk in het proces worden toegepast. Waar voorheen een geautomatiseerde testset een aantal malen per release werd gedraaid, wordt in een DevOps situatie meerdere malen per dag een testset geautomatiseerd uitgevoerd.

De vraag is dan of en hoe je de waarde van geautomatiseerd testen kunt aantonen. De klassieke vuistregel dat een test 5-7 keer uitvoeren de moeite waard is, is in onze ogen achterhaald. In een DevOps context wordt een geautomatiseerde test misschien wel 5 keer per dag uitgevoerd.

Het aantonen van de waarde van investeringen kun je doen in een business case en dat kan ook een goede manier zijn om anderen te overtuigen van het nut van testautomatisering. Een business case zet kosten en baten tegen elkaar af. Kosten en baten kunnen zowel kwalitatief als kwantitatief worden beschreven.

In deze blog gaan we verder in op mogelijke kwalitatieve baten van een toekomstvaste vorm van testautomatisering. Het alleen kwantitatief te benaderen geeft een scheef beeld. Je speelt financieel wel break even maar het is onduidelijk of het dan voldoende waarde oplevert. Ondersteunt de testautomatisering de gedefinieerde doelstellingen wel echt?

De waarde van testautomatisering

Waar moet je aan denken om vast te stellen of testautomatisering de gedefinieerde doelstellingen ondersteunt? Dat hangt uiteraard af van wat de organisatie wil bereiken. In het algemeen kun je de volgende denklijnen volgen om de detailvragen te formuleren om voor je organisatie de (business) waarde te kunnen vaststellen.

Organisaties werken in toenemende mate samen in ketens en zijn afhankelijk van de input of output vanuit deze ketens. Een verstoring in de keten kan tot verliezen lijden. Door na (major) updates standaard een geautomatiseerde ketentest uit te voeren blijf je aantonen dat de keten functioneert en daardoor de bedrijfsdoelstellingen ondersteunt.

Een ander perspectief is het redeneren vanuit bedrijfsrisico’s. Welke risico’s hebben een grote impact? Waar ligt het management wakker van? Antwoorden op dit soort vragen helpen bij het definiëren van een standaard geautomatiseerde regressietest om aan te tonen dat deze risico’s voldoende aandacht krijgen en afgedekt worden. Door het berekenen van de impact van de risico’s op de organisatie, indien deze optreden, toon je de toegevoegde waarde aan van testautomatisering.

Waar is instabiliteit te verwachten in het proces en welke impact heeft dat op de organisatie of het proces in kwantitatieve of kwalitatieve zin? Is testautomatisering een middel om de stabiliteit te bevorderen? Door het berekenen van de faalschade kun je de waarde vaststellen als je de faalschade kunt voorkomen door frequent testautomatisering uit te voeren.

De waarde van testautomatisering kan ook vastgesteld worden door het analyseren van productie-incidenten. Dat is wel iets dat je over een langere termijn moet beoordelen. Door het consequent bijhouden van het aantal incidenten kun je de toegevoegde waarde van testautomatisering vaststellen als deze breed is uitgerold in de organisatie. Uiteraard dient het aantal productie-incidenten te dalen.

Testautomatisering kan de testefficiency verhogen. Door de uitrol van testautomatisering en het daardoor overnemen van het routinematige werk kunnen testers zich concentreren op de complexe cases. Dit leidt ook tot minder productie-incidenten, kortere doorlooptijden van de testuitvoer en efficiëntere inzet van de resources. Door het gestructureerd vastleggen van functionaliteiten in  geautomatiseerde testscripts wordt de aanwezige kennis ook beter geborgd in de organisatie.

Vanuit het software-ontwikkelproces kun je ook kijken of de juiste testen worden uitgevoerd met de juiste scope, diepgang en reikwijdte. Welke rol kan testautomatisering daarin spelen en hoe kan testautomatisering helpen de waarde van testen te vergroten? De ontwikkelteams krijgen sneller feedback op de geleverde software waardoor issues sneller opgelost kunnen worden.

De toepassing van testautomatisering zorgt ervoor dat er mensen beschikbaar komen die kunnen helpen om de voortbrengingsketen verder en efficiënter in te richten. Denk bijvoorbeeld aan het inrichten van een build pipeline en het optimaliseren daarvan. Betrokkenen krijgen dan een grotere uitdaging, er ontstaan meer doorgroeimogelijkheden en beschikbare expertise kan beter worden benut.

Hoe meer vormen van testautomatisering worden toegepast hoe groter de waarde zal zijn. Pas je testautomatisering al toe in de ontwerpfase dan zal dat zijn effect hebben in de verdere schakels in de ontwikkelketen. Hoe eerder een fout is gevonden hoe goedkoper het is om deze te herstellen en de mogelijk negatieve effecten te voorkomen.

Testautomatisering heeft ook een toegevoegde waarde om het kwaliteitsverschil tussen teams in bijvoorbeeld ketens op te vangen. Hoe goed ook het streven om alleen met kwalitatief hoogwaardige teams te werken blijft er altijd een verschil kwaliteit tussen de teams. Niet alleen de kwaliteit maar ook de zorgvuldigheid en betrokkenheid zijn zaken die meespelen. Door continu een geautomatiseerde test uit te voeren krijg je op ieder willekeurig moment inzicht in de kwaliteit van een systeem of een keten en kun je in een vroegtijdig stadium ingrijpen om kwaliteitsissues op te lossen.

Veelal zien we de focus op nieuwbouw van systemen liggen. Correctief onderhoud is noodzakelijk en wordt uiteraard uitgevoerd. Veelal wordt dit onder grote druk gedaan en moeten er keuzes worden gemaakt in wat wel testen en wat niet. Door consequent naast de handmatige testen de beschikbare geautomatiseerde test uit te voeren kan vrij snel inzicht worden verkregen in mogelijke regressie en kunnen productieproblemen worden voorkomen. Daardoor bewijst een geautomatiseerde regressietest zijn waarde.

De beweging om testen steeds eerder in het ontwikkelproces op te pakken en uit te voeren heet de “shift to the left” beweging. Dat betekent dat we bijvoorbeeld al moeten gaan testen voordat er een volwaardige gebruikersinterface beschikbaar is. We testen dan al op een meer technisch niveau. Handmatig is dat bijna niet meer mogelijk en moet wel geautomatiseerd worden uitgevoerd. Van daaruit gezien biedt testautomatisering zijn toegevoegde waarde omdat in een vroegtijdig stadium inzicht gegeven wordt in bijvoorbeeld de kwaliteit van een API.

Doordat we steeds sneller releasen en producten bijna onmiddellijk beschikbaar komen voor het publiek en de klanten kunnen we het ons niet veroorloven om slechte kwaliteit te leveren. Dit ligt dan direct bij het grote publiek en kan tot imagoschade leiden met verlies aan marktaandeel als mogelijk gevolg. Door een geautomatiseerde regressietest continu uit te voeren en deze als harde quality gates te gebruiken in een CI/CD pipeline richt je een extra vangnet in om productieproblemen te voorkomen.

Een laatste invalshoek kan zijn om te kijken naar welke processen binnen een organisatie altijd moeten blijven functioneren, ongeacht wat er gebeurt. Wat is de schade als deze processen stagneren? Door het inzetten van testautomatisering kun je inzicht krijgen of deze processen ongestoord blijven draaien.

Pakketten en testen; een vertragende factor?!

Pakketten en testen. Is dat een logische combinatie? Is het inderdaad een vertragende factor of kan het elkaar juist versterken.

Pakketten kies je om bepaalde redenen. Het gebruik maken van generieke oplossingen of standaarden vanuit de markt, onvoldoende capaciteit om zelf te kunnen ontwikkelen etc. Zo zijn vele redenen te bedenken om te werken met (standaard) pakketten. Een pakket staat niet op zich maar is geïntegreerd in het totale landschap binnen een organisatie. Het pakket vult een onderdeel van de keten in. Daarbij is het natuurlijk van belang dat de keten goed functioneert en er voor zorgt dat de klanten tevreden zijn en blijven.

Zoals bij maatwerk systemen het geval is krijg je ook bij pakketten te maken met updates t.a.v. het pakket of bijvoorbeeld andere wensen t.a.v. de inrichting door bijvoorbeeld veranderende business omstandigheden. Deze wijzigingen moeten gevalideerd worden om te voorkomen dat er allerlei ongewenste neveneffecten gaan ontstaan. De benodigde inspanning kan flink oplopen en heeft wellicht ook een repeterend karakter bij meerdere releases per jaar. Vooral als er (nog) handmatig getest wordt. De benodigde inspanning wordt mede bepaald door de omvang van een regressietest. Uiteraard is deze omvang afhankelijk van de aard van de wijzigingen.

Handmatig testen heeft een grote waarde maar is niet toereikend meer gezien de hoeveelheid updates die beschikbaar zijn, de snelheid waarmee deze geïmplementeerd moeten worden en de tijd die nodig is voor de testuitvoering.

Dan is het toepassen van geautomatiseerd testen een absolute must om het ontwikkeltempo bij te kunnen houden. Zeker gezien als je richting een DevOps situatie gaat bewegen.

Echter, bij de introductie van testautomatisering worden nieuwe uitdagingen geïntroduceerd. Testautomatisering moet herhaalbaar, herbruikbaar en overdraagbaar zijn. Het opvoeren van een bijvoorbeeld een pensioen polis met ingangsdatum vandaag is mooi en de gedefinieerde testgevallen kun je vandaag perfect uitvoeren. Alleen morgen is vandaag niet meer en dan werken je gedefinieerde testgevallen niet meer. Kortom, je testgevallen zijn niet herbruikbaar en herhaalbaar.

Wat kun je er aan doen? De oplossing is voorhanden. Zoals je een informatiesysteem bouwt op basis van een architectuur moet je testautomatisering ook opzetten onder architectuur. We noemen dat testautomatiserings-architectuur waarmee je o.a. herbruikbaarheid en herhaalbaarheid van je geautomatiseerde testen bereikt.

Door deze aanpak kun je snel en gedegen een wijziging, fix, release etc. valideren waarmee de doorlooptijd van de test en daardoor de doorlooptijd van een release aanzienlijk kunt verkorten. Je bereikt dan de situatie dat testen geen vertragende factor meer is maar een katalysator om wijzigingen snel in productie te kunnen zetten.

Wil je meer weten over het opzetten van een toekomstvaste testautomatiserings-architectuur? Kijk dan in het boek: testautomatisering wendbaar organiseren of de website https://mailchi.mp/a6bc6ba0b694/testautomatisering.

Heb je naar aanleiding van dit artikel vragen?

Heb je een vraag of wil je met ons sparren? Neem gerust contact op met Martijn. Hij denkt graag met je mee!