Veel organisaties beginnen hun DevOps transitie met het automatiseren van builds en deployments, bijvoorbeeld met behulp van Azure DevOps. Je begint met een Git repository voor je source code. Dit breidt je uit met een automatische build, je automatiseert je deployments met een release pipeline en steeds meer zaken gaan automatisch een stapje verder.
Automatiseren van builds en deployments zijn op zichzelf al erg waardevol, maar we zien vaak dat het automatiseren van testen achter blijft. Het opzetten van testautomatisering is één ding, het onderhouden daarvan is nog een stuk lastiger. Maar hoe kun je het beste beginnen met testautomatisering bij een bestaande applicatie?
Welke tests kun je automatiseren?
Een belangrijk aspect om te begrijpen, is dat je niet al je testen kunt automatiseren. Je kunt wel geautomatiseerd controleren of de applicatie doet wat jij verwacht dat het doet. Maar als onderdeel van je testen wil je waarschijnlijk ook de gebruiksvriendelijkheid testen en wil je de nieuwe functionaliteit leren kennen. Voor sommige zaken heb je nog steeds menselijke intelligentie nodig om te beoordelen of bepaald gedrag gewenst of ongewenst is. Testautomatisering is dan ook geen vervanging van handmatige testen, het zorgt er vooral voor dat je meer kunt testen met minder inspanning. Bedenk vooraf dus ook goed waarom je de testen wilt automatiseren en wat je ermee wilt bereiken.
Testpiramide
Om te beginnen met het automatiseren van testen laten we vaak een testpiramide zien. Er bestaan veel versies van deze piramide en ook de gebruikte termen verschillen onderling. Maar het gaat ons vooral om het concept.
Deze piramide laat zien dat je testen kunt onderverdelen in verschillende lagen. Aan de onderkant van de piramide zijn de testen snel en goedkoop, daar wil je de meeste testen van hebben. Unit tests zijn erg nauw verweven met de code, waardoor ze goedkoper te onderhouden zijn. Aan de bovenkant van de piramide zijn de testen vaak langzaam en duur. Deze testen zitten verder van de code af, aanpassingen in de code kunnen zorgen voor fouten in de tests, ze zijn daardoor duurder om te onderhouden. Dat wil niet zeggen dat je uiteindelijk alleen maar testen aan de onderkant moet hebben, je hebt uiteindelijk testen uit iedere laag nodig.
Unit tests
Unit tests testen de kleinst mogelijke eenheid van je code. Wat een unit is hangt onder andere af van de taal waarin de applicatie geschreven is, maar ook wat jullie als team beschouwen als unit. Je kunt hierbij denken aan een functie, een methode of een class. Deze tests worden meestal geschreven door de developers zelf, al dan niet geholpen door testspecialisten. Ze zijn erg snel en geven heel snel feedback over fouten in je code. Op zichzelf lijkt zo’n unit test misschien niet heel waardevol, maar juist het feit dat je bij iedere aanpassing in je code snel en eenvoudig heel veel unit testen uitvoert, geeft je heel snel waardevolle feedback. Uiteindelijk bouw je hiermee een goede regressietest op die je bij iedere aanpassing uit kunt voeren.
Integratie tests
De volgende laag zijn integratie tests. Ook voor integratietesten bestaat geen harde definitie. Vaak is jouw applicatie of het component van de applicatie waar jij aan werkt onderdeel van een groter systeem. Die losse applicaties of componenten moeten kunnen samenwerken. Deze samenwerking test je met integratietesten. Hierbij kun je o.a. denken aan de connectie met een database of de aanroep van een API.
Geautomatiseerde end to end testen
De laag daarboven zijn de geautomatiseerde end to end testen, deze worden vaak uitgevoerd vanuit de User Interface. In de meeste gevallen gebruik je hier externe tools voor. Deze testen zijn ingewikkeld om te maken en vooral om te onderhouden. Deze testen zijn meestal ook langzamer in de uitvoering en zijn vrij duur.
Handmatige exploratory testen
Daarboven heb je nog de handmatige exploratory testen. Dit zou je kunnen zien als de tegenhanger van het uitvoeren van vooraf gedefinieerde standaard test scripts. Hiermee test je het gebied wat erg lastig te automatiseren is. Je kunt denken aan een ervaren gebruiker of tester die de nieuwe of gewijzigde functionaliteit van een applicatie test. Deze gebruiker weet vaak wel waar de problemen te verwachten zijn, of welke onderdelen echt getest moeten worden. Tijdens het testen leert de tester ook nieuwe dingen die ook meteen weer tijdens het testen toegepast kunnen worden.
Waar begin ik met testautomatisering?
Om terug te komen op de vraag: “waar kan ik het beste beginnen met testautomatisering?”. Voor een deel hangt dit af van je doel. Het is altijd goed om te starten met unit tests. Je hoeft niet meteen unit tests te schrijven voor alle bestaande units, maar je kunt bijvoorbeeld beginnen met het schrijven van unit tests voor de units die je toevoegt of aanpast. Als je eenmaal gewend bent geraakt aan het maken van unit tests, kun je unit tests schrijven voor de belangrijkste onderdelen van je applicatie. Voor basisfuncties die altijd moeten werken.
Een andere mogelijkheid is om te starten met smoke tests. Een smoke test is eigenlijk een simpele check of je applicatie in de basis werkt zodra de deployment klaar is. Je kunt bijvoorbeeld testen of een service gestart is, of dat je website in de lucht is. Dit zijn eenvoudige tests waarmee je heel snel waardevolle feedback krijgt. Als een smoke test faalt, hoeven de testers niet te beginnen met testen.
Starten met geautomatiseerde testen kan lastig zijn. Het vergt ook een flinke investering, vooral als je er net mee begint. Toch zal het uiteindelijk zijn vruchten afwerpen. Je krijgt sneller feedback op je aanpassingen en de kwaliteit van je code zal erop vooruit gaan. Uiteindelijk kun je met het toevoegen van geautomatiseerde testen aan je deployment pipeline sneller, maar vooral ook meer waarde opleveren aan je klant.
Wilt u gaan starten met automatisch testen, of bent u gestart en loopt u tegen vragen op? Aarzel dan niet om contact met ons op te nemen via 085 – 487 52 00. Bent u continu op zoek naar het verbeteren van uw software ontwikkelproces, kijk dan eens naar het DevOps Program.
Mike Beemsterboer, DevOps Consultant
