Geautomatiseerd testen van software

Why is testing automation important to continuous delivery?

Bij continue levering (CD) draait alles om het zo snel mogelijk leveren van nieuwe codereleases aan klanten. Geautomatiseerde tests zijn van cruciaal belang om dat doel te bereiken. Er is geen manier om de levering aan gebruikers te automatiseren als er een handmatige, tijdrovende stap is in het leveringsproces.

CD maakt deel uit van een grotere implementatiepipeline. CD is een opvolger van en ook afhankelijk van continue integratie (CI). CI is volledig verantwoordelijk voor het uitvoeren van geautomatiseerde tests op nieuwe codewijzigingen en om te controleren of deze wijzigingen bestaande functies niet onderbreken of nieuwe bugs introduceren. CD wordt geactiveerd zodra de continue integratiestap het geautomatiseerde testplan heeft doorstaan.

Deze relatie tussen geautomatiseerd testen, CI en CD levert veel voordelen op voor een snel softwareteam. Geautomatiseerd testen garandeert kwaliteit in elke ontwikkelingsfase door ervoor te zorgen dat nieuwe commits geen bugs veroorzaken, zodat de software te allen tijde klaar is voor implementatie.

1. End-to-end-tests

De meest waardevolle tests om uit te voeren zijn ongetwijfeld end-to-end-tests (E2E). E2E-tests simuleren een ervaring op gebruikersniveau in de volledige stack van een softwareproduct. E2E-testplannen omvatten over het algemeen story's op gebruikersniveau, zoals: 'een gebruiker kan inloggen', 'een gebruiker kan een storting doen', 'de gebruiker kan de e-mailinstellingen wijzigen'. Deze tests zijn zeer waardevol om uit te voeren, omdat ze garanderen dat echte gebruikers een probleemloze ervaring hebben, zelfs als er nieuwe commits worden gepusht.

E2E-testtools leggen acties van gebruikers vast en spelen ze opnieuw af, zodat E2E-testplannen opnames worden van belangrijke stromen van gebruikerservaringen. Als een softwareproduct geen enkele vorm van geautomatiseerd testen omvat, krijgt het de meeste waarde door E2E-tests van de meest kritieke bedrijfsstromen uit te voeren. E2E-tests kunnen vooraf duur zijn om de gebruikersstroomvolgorde vast te leggen. Als het softwareproduct geen snelle dagelijkse releases uitbrengt, kan het voordeliger zijn om dit handmatig te laten uitvoeren door een menselijk team met de E2E-testplannen.

2. Unittests

Zoals de naam al aangeeft, hebben unittests betrekking op individuele code-units. Code-units kunnen het best worden gemeten in functiedefinities. Een unittest heeft betrekking op een afzonderlijke functie. Unittests wijzen uit dat de verwachte invoer voor een functie overeenkomt met de verwachte output. Code met gevoelige berekeningen (aangezien het betrekking kan hebben op financiën, gezondheidszorg of luchtvaart) kan het best worden gedekt door unittests. Unittests zijn goedkoop en snel uit te voeren en leveren een hoog investeringsrendement op.

3. Integratietests

Vaak maakt een code-unit gebruik van een externe service. De primaire codebase die wordt getest, heeft geen toegang tot de code van dit externe hulpmiddel. Integratietests behandelen de nabootsing van deze externe afhankelijkheden en de bevestiging dat de code die ermee verbonden is zich gedraagt zoals verwacht.

Integratietests lijken op unittests wat betreft de manier waarop ze zijn geschreven en wat betreft de tools. Integratietests kunnen een voordelig alternatief zijn voor E2E-tests, maar het rendement op de investering is discutabel wanneer de combinatie van unittests en E2E al bestaat.

4. Prestatietests

Bij gebruik in de context van softwareontwikkeling worden 'prestaties' gebruikt om de snelheid en het reactievermogen te beschrijven waarmee een softwareproject reageert. Enkele voorbeelden van prestatiestatistieken zijn: 'tijd om de pagina te laden', 'tijd tot de eerste weergave', 'reactietijd van de zoekresultaten'. Prestatietests leveren metingen en beweringen op voor deze voorbeeldgevallen. Geautomatiseerde prestatietests voeren testcases uit op basis van deze statistieken en brengen het team vervolgens op de hoogte van eventuele regressies of snelheidsverlies.

Welke soorten softwaretests moeten handmatig worden uitgevoerd?

Het is een goed discussiepunt of alle tests die geautomatiseerd kunnen worden, ook geautomatiseerd moeten worden. Het betekent een enorme stijging in productiviteit en bespaart medewerkers tijd. Dat gezegd hebbende, zijn er momenten waarop het rendement van de ontwikkeling van een geautomatiseerde testsuite niet de moeite waard is ten opzichte van het uitvoeren van een handmatige test.

1. Verkennende testen

Geautomatiseerde tests zijn gescript en volgen een reeks stappen om gedrag te valideren. Verkennende tests zijn willekeuriger en proberen ongescripte volgordes te vinden om bugs of onverwacht gedrag te vinden. Hoewel er softwaretools zijn om een suite voor verkennende softwaretests op te zetten, zijn deze nog niet volledig ontwikkeld en worden nog niet op grote schaal toegepast. Het kan veel efficiënter zijn om een handmatige QA-tester toe te wijzen en menselijke creativiteit te gebruiken om te ontdekken hoe je een softwareproduct kunt ontplooien.

2. Visuele regressietests

Een visuele regressie vindt plaats wanneer er een visuele ontwerpfout wordt geïntroduceerd in de gebruikersinterface van de software. Dit kunnen verkeerd geplaatste UI-elementen, een verkeerd lettertype, verkeerde kleuren of meer zijn. Net als bij verkennend testen zijn er hulpmiddelen beschikbaar om geautomatiseerde tests te schrijven om deze regressies vast te leggen. Deze tools maken screenshots van verschillende versies van een softwareproduct en gebruiken vervolgens OCR (optische tekstherkenning) om ze te vergelijken met de verwachte resultaten. Het ontwikkelen van deze tests is duur en de tools worden niet algemeen ingezet. Het kan veel effectiever zijn om een persoon iets te laten bekijken om te kijken of er visuele problemen zijn.

3. Een kader voor testautomatisering bouwen voor je DevOps-team

Er is geen allesomvattende oplossing voor geautomatiseerd testen. Bij het plannen van een geautomatiseerde testoplossing voor je team zijn er een paar belangrijke overwegingen die je moet maken.

4. Frequentie van release

Voor softwareproducten die met vaste tussenpozen worden uitgebracht, zoals maandelijks of wekelijks, kan handmatig testen beter geschikt zijn. Softwareproducten die sneller op de markt komen, hebben meer baat bij geautomatiseerd testen, aangezien CI en CD afhankelijk zijn van geautomatiseerd testen.

5. Beschikbare tools en ecosysteem

Elke programmeertaal heeft zijn eigen ecosysteem van aanvullende tools en hulpprogramma's. Elk type geautomatiseerd testpatroon heeft een eigen set tools die al dan niet beschikbaar zijn in een bepaald ecosysteem van programmeertalen. Voor een succesvolle implementatie van een geautomatiseerd testpatroon is een combinatie van taal en toolondersteuning vereist.

6. Geschikt voor de productmarkt en een volwassen codebase

Als je team bezig is met de ontwikkeling van een nieuw product waarvan nog niet bewezen is dat het een doelgroep of bedrijfsmodel heeft, is het misschien niet verstandig om te investeren in geautomatiseerde tests. Geautomatiseerde tests fungeren als een verzekeringsmechanisme om onverwachte coderegressies te beperken. Als je team razendsnel vordert, kan het frustrerend duur zijn om geautomatiseerde tests te moeten bijwerken en onderhouden wanneer de code drastisch en snel verandert

Geautomatiseerd testen onderdeel van je CD-pipeline maken

Geautomatiseerd testen is een standaardwerkwijze voor moderne softwareontwikkeling. De beste teams en bedrijven gebruiken geautomatiseerde tests. CI/CD is afhankelijk van geautomatiseerde tests en is van groot belang om de beste teams te helpen betrouwbare en robuuste software aan hun klanten te leveren.

Bovendien biedt Open DevOps van Atlassian een open toolchain-platform waarmee je een CD-gebaseerde ontwikkelingspipeline kunt bouwen met je favoriete tools. Ontdek hoe Atlassian en tools van derden testen kunnen integreren in je workflow met onze DevOps-testtutorials.