Agile-automated testen
July 14, 2023
Frederique De Winter
Tegenwoordig werken veel bedrijven volgens de Agile-methodologie of zijn ze bezig met de overstap ernaartoe. Met Agile kun je nieuwe functionaliteiten sneller en efficiënter opleveren. Maar hoe kunnen we de kwaliteit van die nieuwe features garanderen?
Wat is agile (testen)?
De Agile-methodologie draait om het leveren van incrementele verbeteringen aan je product en kan worden bereikt door processen zoals Scrum, waarbij de ontwikkeling wordt opgesplitst in kleine iteraties of ‘sprints’. Aan het begin van elke sprint bepaal je welke functionaliteiten prioriteit krijgen. Aan het einde controleer je of je hebt opgeleverd wat de gebruiker nodig heeft. Het resultaat is een reeks kleine, incrementele productreleases die telkens getest moeten worden op kwaliteit en stabiliteit.
Vroeger, bij de waterfall-methode, werd er pas getest als de hele ontwikkeling van het product was afgerond. Vandaag de dag verandert de specificatie regelmatig tijdens de ontwikkeling, waardoor QA-teams voortdurend moeten testen tegen nieuwe of gewijzigde vereisten.
Met andere woorden: het testen moet ook Agile zijn. Dit betekent dat je tijdens elke ontwikkelingssprint het hele product moet kunnen testen. In de meeste gevallen is dat alleen haalbaar met behulp van testautomatisatie. Hierbij voert een computer acties uit op de gebruikersinterface (UI), zoals een echte gebruiker dat zou doen. Hiervoor worden vaak tools zoals Selenium, Cypress, enz. gebruikt.
Uitdagingen bij Agile testautomatisering
De Agile-methodologie is de snelste manier om een idee om te zetten in een werkend product, zeker bij dynamische projecten die voortdurend veranderen. Het grootste voordeel van Agile werken is de mogelijkheid tot continue iteratie, maar juist dat brengt ook enkele belangrijke obstakels met zich mee:
Testcreatie
Het ontwikkelen van een geautomatiseerde test kan enkele uren of soms zelfs dagen duren, vooral bij complexe UI-applicaties. De reden hiervoor is dat elke test moet worden geïmplementeerd, getest en gedebugged. Voeg daar nog ondersteuning voor meerdere browsers of platformen aan toe, en het proces vertraagt nog verder. Tijdens een sprint kan de tijd die nodig is voor het maken van tests voor nieuwe features dan al snel een knelpunt vormen.
Regressietesten
De aard van de Agile-methodologie is om zich aan te passen aan voortdurende veranderingen. Bij elke update moeten zowel de code als de UI-laag van de applicatie opnieuw getest worden, om er zeker van te zijn dat alles nog correct werkt na deze changes. Dit resulteert in een enorme hoeveelheid regressietests die QA-teams moeten uitvoeren.
Testschuld (Test Debt)
Tijdens elke sprint heb je maar een beperkte hoeveelheid tijd. Die tijd moet worden verdeeld tussen het maken van tests voor de nieuwe functionaliteiten die binnen deze sprint worden ontwikkeld, het onderhouden van bestaande regressietests en het uitvoeren en analyseren van alle resultaten. Zo zal het testonderhoud voor de regressietests met elke sprint toenemen en uiteindelijk zal het team niet in staat zijn om al het werk dat ze moeten doen af te ronden. Deze steeds groter wordende achterstand in testonderhoud noemen we testschuld. Agile testen vereist dat je team een Agile aanpak volgt, waarbij ze hun werk opsplitsen op basis van sprints van het ontwikkelteam. Tijdens elke sprint moet het testteam prioriteiten stellen tussen het automatiseren van nieuwe features, het onderhouden van bestaande geautomatiseerde scripts en het handmatig uitvoeren van tests. Door testschuld moeten er concessies worden gedaan en dat leidt tot lastige keuzes om sprintdoelen toch te behalen.
Onderhoud
Geautomatiseerde UI-tests zijn erg kwetsbaar. In veel applicaties ontbreekt een unieke ID per element, waardoor testers moeten vertrouwen op CSS- of xPath-selectors om de juiste elementen te vinden. Onze geautomatiseerde test gebruikt deze selectors om het juiste element voor interactie te identificeren. Het nadeel van dit soort selectors is dat ze onvoorspelbaar kunnen veranderen wanneer de UI tijdens een sprint wordt bijgewerkt. Als zo’n selector verandert, zijn er twee mogelijke uitkomsten: de test breekt af omdat de selector kapot is en geen element kan vinden of de selector selecteert het verkeerde element voor interactie en de test mislukt een aantal stappen later. Elke keer dat de UI van je applicatie verandert, moet je ook je CSS en xPath selectors aanpassen.
Bij Brightest hebben we ons eigen Brightest automatisatieframework ontwikkeld. Dit is ontworpen als een toekomstbestendige oplossing en is leverancieronafhankelijk.
Zijn er oplossingen?
Systeem- en serviceniveau
In een Agile workflow ondergaat de gebruikersinterface (UI) vaak veranderingen. In termen van UI-onderhoud is testautomatisering vaak erg tijdrovend. Om de onderhoudskosten laag te houden en de algehele dekking te verbeteren, moet automatisatie zoveel mogelijk op systeem- en serviceniveau worden uitgevoerd . Het maken, uitvoeren en onderhouden van een geautomatiseerde API-test kost veel minder tijd dan een geautomatiseerde UI-test. Daarom moeten we proberen het aantal geautomatiseerde UI-tests zo laag mogelijk te houden.
Unieke id’s
Wanneer je een geautomatiseerde UI-test opzet, zorg er dan voor dat je zoveel mogelijk unieke id’s gebruikt . Dit zorgt voor snellere tests, minder fouten en minder onderhoud als er kleine wijzigingen in de UI van de applicatie worden aangebracht.
Automatisatieframework
Gebruik een automatisatieframework; dit is een combinatie van richtlijnen en gestructureerde code. Een goed ontworpen framework biedt heel wat voordelen:
- Het stimuleert herbruikbaarheid binnen je tests, wat leidt tot minder onderhoud.
- Een keyword-driven framework versnelt het aanmaken van nieuwe tests voor nieuwe functionaliteiten tijdens de sprint.
Dankzij de combinatie van keywords en duidelijke richtlijnen ontstaat een leesbare en begrijpelijke manier om tests te schrijven.En dat zelfs voor minder technische mensen. - Door het framework te scheiden van de tests en testobjecten, wordt het onderhoud beperkt, omdat elke verandering in een test veel minder impact heeft op de testobjecten en het framework zelf. Hetzelfde geldt voor elke verandering in een van de testobjecten. Dit zal geen impact hebben op de tests en het framework zelf.
- Een gestandaardiseerde manier van werken voor alle teams.
Een framework heeft veel voordelen in een agile omgeving, maar het moet nog steeds ontwikkeld worden. Het zal tijd kosten, is slechts een eenmalige inspanning. Als het eenmaal op de juiste manier is geïmplementeerd, kan hetzelfde framework zonder extra moeite voor alle projecten worden gebruikt.
Brightest automatisatieframework
Bij Brightest hebben we ons eigen Brightest Automation Framework ontwikkeld, dat is ontworpen als een toekomstbestendige oplossing en is leverancieronafhankelijk. Dit framework is uitbreidbaar en kan worden aangepast aan jouw wensen en eisen. Wij beloven geen sprookjes; complexe applicaties vragen om een complexe automatisatie. Met dit framework proberen we de complexiteit voor de tester zoveel mogelijk te minimaliseren. Het is gebaseerd op al onze eerdere ervaringen en zal ongetwijfeld een sterke start geven aan jouw testautomatisatie!
Laten we samenwerken