End-to-end testen: hoe software wordt getest zoals een gebruiker het ervaart
Stel je bestelt online een pakket. Je zoekt het product, legt het in je winkelmandje, vult je adres in, betaalt en wacht tot het pakket wordt bezorgd. Pas als al die stappen achter elkaar goed verlopen, is de bestelling echt geslaagd. End-to-end testen (letterlijk: van begin tot eind testen) werkt op dezelfde manier voor software: in plaats van losse onderdelen apart te controleren, wordt het hele proces getest zoals een echte gebruiker het zou doorlopen.
Bij software gebeurt dit meestal niet door een mens die telkens handmatig gaat klikken, maar door een computerprogramma dat dit automatisch nadoet. Zo'n geautomatiseerde test opent bijvoorbeeld een webshop, zoekt een product, klikt op 'bestellen', vult een adres in en controleert aan het eind of de bevestigingspagina verschijnt. Als ergens in die keten iets misgaat, een knop werkt niet, een formulier accepteert het adres niet, de betaling faalt, dan slaat de test alarm. End-to-end testen (vaak afgekort tot E2E-testen) is daarmee een manier om te controleren of een compleet systeem, met al zijn onderdelen samen, doet wat het moet doen.
Wat is het precies?
Software testen betekent in de kern: controleren of een programma zich gedraagt zoals bedoeld. Ontwikkelaars onderscheiden daarbij verschillende niveaus. Op het kleinste niveau staan unit tests: die controleren één geïsoleerd stukje code, bijvoorbeeld een functie die twee getallen optelt. Een niveau hoger zitten integratietests, die nagaan of verschillende onderdelen goed samenwerken, bijvoorbeeld of de betaalmodule correct communiceert met de voorraadadministratie.
End-to-end testen vormt de bovenste laag. Hier wordt niet één onderdeel getest, maar de volledige gebruikerservaring, van het openen van de applicatie tot het voltooien van een taak. Technisch gebeurt dit met een testscript: een stuk code dat exact beschrijft welke acties een gebruiker onderneemt. Dat script stuurt vervolgens een echte of gesimuleerde webbrowser aan, alsof er een onzichtbare gebruiker achter het toetsenbord zit. Het klikt op knoppen, typt tekst in velden, wacht tot pagina's laden en controleert of de uiteindelijke uitkomst klopt, bijvoorbeeld of de tekst 'Bestelling geplaatst' verschijnt.
Voor dit soort automatisering bestaan gespecialiseerde gereedschappen, zogeheten testframeworks. Bekende voorbeelden zijn Selenium, Cypress en Playwright. Deze tools verschillen in details, maar hebben allemaal hetzelfde doel: browsers programmatisch besturen zodat testscenario's herhaald en geautomatiseerd kunnen worden uitgevoerd, zonder dat een mens dit telkens handmatig hoeft te doen.
Wat wil men ermee bereiken?
Het belangrijkste doel is vertrouwen. Moderne software verandert voortdurend: ontwikkelaars voegen functies toe, repareren fouten en passen code aan. Bij elke wijziging bestaat het risico dat er ergens anders iets kapotgaat, een probleem dat in de sector 'regressie' heet. End-to-end tests fungeren als een vangnet: ze controleren automatisch of de belangrijkste gebruikersstromen nog steeds werken, ook na een wijziging die op het eerste gezicht niets met die stroom te maken had.
Daarnaast spelen kosten en snelheid een rol. Handmatig een compleet bestelproces doorlopen kost een tester al gauw enkele minuten; een geautomatiseerd script doet dit in seconden en kan dit bovendien tientallen keren per dag herhalen, zonder vermoeidheid of menselijke fouten. Dit sluit aan bij een werkwijze die continuous integration/continuous deployment (CI/CD) wordt genoemd: software wordt voortdurend in kleine stapjes bijgewerkt en automatisch getest, zodat nieuwe versies sneller en met minder risico kunnen worden uitgebracht. Zonder geautomatiseerde tests zou dit tempo niet haalbaar zijn, omdat handmatig controleren simpelweg te veel tijd zou kosten.
Voorbeelden uit de praktijk
Een van de oudste en invloedrijkste tools is Selenium, ontstaan in 2004 bij het IT-adviesbureau ThoughtWorks. Ontwikkelaar Jason Huggins bouwde het als intern hulpmiddel om herhaaldelijk terugkerende browsertests te automatiseren; het groeide uit tot een open source project dat de basis legde voor veel latere tools.
In 2015 richtte Brian Mann Cypress.io op, met als doel testen voor webontwikkelaars eenvoudiger en betrouwbaarder te maken dan met de toenmalige generatie tools. Cypress won snel populariteit vanwege de directe, visuele manier waarop ontwikkelaars konden zien wat een test precies deed tijdens het uitvoeren ervan.
Google bracht in 2017 Puppeteer uit, een tool waarmee de Chrome-browser programmatisch aangestuurd kan worden. Een aantal ontwikkelaars met ervaring uit dat project startte vervolgens bij Microsoft, dat in 2020 Playwright lanceerde: een testtool die, in tegenstelling tot veel voorgangers, vanaf het begin meerdere browsers (waaronder Chrome, Firefox en Safari) op dezelfde manier kon aansturen.
Ook grote techbedrijven zelf leunen zwaar op deze aanpak. Google gebruikt intern grootschalige, geautomatiseerde testinfrastructuur om producten als Search en Gmail te controleren voordat wijzigingen naar miljarden gebruikers gaan; de exacte omvang en werking van die interne systemen is niet volledig openbaar, maar het bedrijf heeft in technische publicaties en presentaties herhaaldelijk het belang van geautomatiseerd testen op schaal benadrukt.
Hoe ver is de techniek?
End-to-end testen is inmiddels een volwassen en wijdverspreide praktijk in de softwaresector, geen experimentele nieuwigheid. Toch kent het bekende, hardnekkige problemen. Het bekendste is het verschijnsel flaky tests: tests die soms slagen en soms falen, zonder dat er daadwerkelijk iets mis is met de software. Dit gebeurt bijvoorbeeld doordat een pagina net iets langzamer laadt dan verwacht. Zulke onbetrouwbare tests ondermijnen het vertrouwen van ontwikkelaars en kosten veel tijd om uit te zoeken.
Een tweede obstakel is onderhoud. Naarmate een applicatie verandert, moeten ook de testscripts worden bijgewerkt, anders raken ze verouderd of gaan ze verkeerde dingen controleren. Bij grote applicaties met honderden testscenario's kan dit onderhoud een aanzienlijke inspanning vergen. Daarnaast zijn end-to-end tests relatief traag: het opstarten van een browser en het doorlopen van een volledig scenario duurt aanzienlijk langer dan het testen van een enkele functie. Om deze reden hanteert de sector het concept van de testpiramide: veel snelle unit tests aan de basis, minder integratietests in het midden, en relatief weinig, zorgvuldig gekozen end-to-end tests aan de top, gericht op de belangrijkste gebruikersstromen.
Een recente ontwikkeling is het gebruik van kunstmatige intelligentie om testscripts (deels) automatisch te genereren of om flaky tests te herkennen en te herstellen. Dit staat nog volop in ontwikkeling; verschillende bedrijven experimenteren ermee, maar het is nog niet duidelijk in hoeverre dit de rol van menselijke testontwikkelaars structureel zal veranderen.
Wie werken eraan?
Het veld wordt gedreven door een combinatie van grote techbedrijven en open source gemeenschappen, met een sterke concentratie in de Verenigde Staten. Microsoft ontwikkelt en onderhoudt Playwright. Het bedrijf Cypress.io is verantwoordelijk voor het gelijknamige testframework. Google ontwikkelde Puppeteer en investeert daarnaast zwaar in interne testinfrastructuur voor zijn eigen producten.
Selenium wordt beheerd als open source project, ondergebracht bij de Software Freedom Conservancy, een organisatie die verschillende open source projecten juridisch en organisatorisch ondersteunt. Op standaardisatieniveau speelt het World Wide Web Consortium (W3C) een rol: dit internationale gremium beheert de WebDriver-standaard, een gedeelde technische afspraak over hoe software een browser mag aansturen, waarmee verschillende testtools onderling compatibel blijven.