Vrijdagochtend. Release staat gepland om 14:00. Het team draait de testsuite, maar na twee uur wachten staat de pipeline nog steeds op oranje. Uiteindelijk komt het verdict: 12 van de 500 end-to-end tests zijn gefaald. Niemand weet of het echte bugs zijn of gewoon instabiele tests. De release wordt uitgesteld naar maandag, want niemand durft het risico te nemen.
Dit scenario komt vaker voor dan je zou denken. Teams bouwen honderden e2e tests (end-to-end tests, oftewel tests die de complete gebruikersreis van begin tot eind doorlopen) met de beste intenties, maar eindigen met een trage, fragiele testsuite die meer problemen veroorzaakt dan oplost. En dat is zonde, want end-to-end testing is ontzettend waardevol als je het goed aanpakt.
In deze guide leer je hoe je e2e tests opzet die echt werken, welke tools je daarvoor kunt gebruiken, en vooral: hoe je voorkomt dat je testsuite een monster wordt dat niemand meer durft aan te raken. Of je nu net begint met end-to-end testing of je huidige aanpak wilt verbeteren, na dit artikel weet je precies waar je staat en wat je volgende stap is.
Wat is end-to-end testing eigenlijk, en waarom zou je het gebruiken?
End-to-end testing betekent dat je de complete reis van een gebruiker door je applicatie test, van de eerste klik tot het uiteindelijke resultaat. Je test dus niet een los onderdeel, maar de hele keten: frontend, backend, database, externe services, alles samen.
Neem als voorbeeld een checkout flow in een webshop. Een gebruiker zoekt een product, legt het in de winkelmand, vult verzendgegevens in, betaalt, en krijgt een orderbevestiging. Bij end-to-end testing doorloop je precies die stappen, alsof je zelf die gebruiker bent. Je controleert of elk onderdeel goed samenwerkt en of het eindresultaat klopt.
Dat klinkt logisch, maar waarom is dat zo belangrijk? Omdat veel bugs pas opduiken wanneer verschillende onderdelen met elkaar communiceren. Een unit test (een test op een klein, afgebakend stukje code) kan prima slagen, terwijl de complete flow toch kapotgaat. Stel je voor: de productpagina werkt, de winkelmand werkt, de betaalmodule werkt, maar het verzendadres wordt niet correct doorgegeven van stap 3 naar stap 4. Dat soort problemen vang je alleen met end-to-end testing.
Maar er zit een keerzijde aan, en die is belangrijk om te begrijpen voordat je begint.
Waarom e2e testing waardevol is, maar ook veel kost
End-to-end testing geeft je iets dat geen andere testvorm kan bieden: het vertrouwen dat je applicatie als geheel werkt voor echte gebruikers. Je test niet alleen losse onderdelen, maar de complete ervaring. Dat maakt het onmisbaar voor kritieke flows zoals betalingen, registraties of bestellingen.
Echter, die waarde heeft een prijs. Een gemiddelde e2e test duurt 30 tot 60 seconden, omdat de test een echte browser opstart, pagina's laadt, formulieren invult en op responses wacht. Vergelijk dat met een unit test die in milliseconden klaar is. Als je 200 e2e tests hebt, zit je al snel aan twee uur wachten voordat je suite klaar is.
Daarnaast zijn e2e tests kwetsbaar. Een kleine wijziging in de gebruikersinterface, bijvoorbeeld een knop die van plek verandert of een tekst die aangepast wordt, kan tientallen tests laten falen. Dit noemen we flaky tests: instabiele tests die soms slagen en soms falen zonder dat er iets aan de code veranderd is. Teams die hier niet goed mee omgaan, verliezen het vertrouwen in hun testsuite en beginnen mislukte tests te negeren. En dat is precies wanneer echte bugs door de mazen glippen.
De sleutel is dus balans. End-to-end testing is geen doel op zich, maar een middel. En hoe je die balans vindt, bepaalt of je testsuite je helpt of juist tegenwerkt.
Dus hoe zorg je ervoor dat je e2e tests echt waarde toevoegen? Dat begint bij het ontwerp van elke individuele test.
Hoe herken je een goede e2e test (en wanneer gaat het mis)?
Een goede end-to-end test heeft een paar duidelijke kenmerken. Ten eerste test hij een kritieke gebruikersreis, zoals het aanmaken van een account, het plaatsen van een bestelling, of het resetten van een wachtwoord. Dit zijn de flows waar je gebruikers echt afhankelijk van zijn, en waar een bug direct impact heeft op je omzet of gebruikerservaring.
Ten tweede is een goede e2e test gefocust. Dat betekent 5 tot 10 stappen, niet meer. Stel je een test voor die 50 stappen doorloopt: van inloggen tot het aanpassen van profielinstellingen tot het bestellen van drie verschillende producten. Zo'n test is fragiel, want elke stap is een potentieel breekpunt. Bovendien is het lastig om te achterhalen wat er precies misging als de test faalt.
Daarnaast gebruikt een goede test zogenaamde expliciete waits (wachtmomenten). Dat betekent dat de test wacht tot een element daadwerkelijk zichtbaar of beschikbaar is, in plaats van een vaste wachttijd in te stellen. Het verschil is groot: een vaste wachttijd van 5 seconden vertraagt je test onnodig, en als de pagina net iets langer laadt, faalt de test alsnog. Expliciete waits zijn dus sneller en betrouwbaarder.
Waar gaat het dan mis? Vaak bij teams die e2e tests schrijven voor randzaken die eigenlijk op een lager niveau thuishoren. Edge cases (randgevallen), specifieke validatieregels, foutafhandeling: die horen bij unit tests of integration tests (tests die controleren of meerdere onderdelen correct samenwerken). Als je die op e2e-niveau test, bouw je een enorme, trage suite die meer onderhoud kost dan nodig is.
En als je eenmaal weet wat een goede test is, wil je natuurlijk ook weten met welk gereedschap je die test schrijft.
Welke tool kies je: Selenium, Cypress of Playwright?
De drie meest gebruikte e2e testing tools zijn Selenium, Cypress en Playwright. Elk heeft sterke en zwakke punten, en de beste keuze hangt af van je situatie.
Selenium is de oudste en meest bekende optie. Het ondersteunt alle belangrijke browsers en werkt met meerdere programmeertalen zoals Java, Python en JavaScript. Bekijk de officiële Selenium-documentatie voor een actueel overzicht van de mogelijkheden. Nadeel: trager dan de alternatieven en meer configuratie nodig.
Cypress is populair bij JavaScript-teams. Het draait direct in de browser, waardoor het snel is en ingebouwde wachtmechanismen heeft. Nadeel: alleen Chromium-gebaseerde browsers, dus geen Firefox of Safari.
Playwright combineert het beste van beide: snel, alle browsers, en automatisch wachten tot elementen beschikbaar zijn (auto-wait). Voor nieuwe end-to-end testing projecten is Playwright vaak de beste keuze. Zie de Playwright-documentatie voor een snelle start.
Welke tool past? Een modern team met React en TypeScript kiest waarschijnlijk Playwright. Een enterprise organisatie met een uitgebreide Selenium-suite blijft beter bij Selenium en investeert in het verbeteren van bestaande tests.
Zo ziet een e2e test eruit in de praktijk
Om het concreet te maken, hier is een voorbeeld van een checkout-test met Playwright:
import { test, expect } from '@playwright/test';
test('checkout flow werkt end-to-end', async ({ page }) => {
// 1. Browse products
await page.goto('https://example.com/products');
// 2. Add to cart
await page.click('button[data-testid="add-to-cart"]');
await expect(page.locator('.cart-count')).toHaveText('1');
// 3. Fill shipping
await page.click('button[data-testid="checkout"]');
await page.fill('#email', 'test@example.com');
await page.fill('#address', 'Teststraat 123');
// 4. Payment
await page.click('button[data-testid="continue-to-payment"]');
await page.fill('#card-number', '4242424242424242');
// 5. Order confirmation
await page.click('button[data-testid="place-order"]');
await expect(page.locator('h1')).toContainText('Bestelling bevestigd');
});
Let op een paar dingen in deze test. Elke stap gebruikt await, wat betekent dat de test wacht tot de actie daadwerkelijk voltooid is voordat hij doorgaat. Daarnaast worden data-testid attributen gebruikt in plaats van CSS-klassen of tekst, want die veranderen minder snel bij UI-aanpassingen. En de test focust op een kritieke flow (checkout) met een overzichtelijk aantal stappen.
Voor meer over hoe test automation past in je bredere strategie, bekijk de test automation strategie gids.
Maar zelfs met het juiste gereedschap en goed ontworpen tests kun je in valkuilen trappen. En die valkuilen komen verrassend vaak voor.
Vijf valkuilen die bijna elk team tegenkomt
Je testsuite groeit, maar krimpt nooit
Teams schrijven steeds nieuwe e2e tests, maar verwijderen nooit de oude. Een team begon met 30 tests, had er na anderhalf jaar 500, en hun pipeline duurde vier uur. De oplossing: 350 tests schrappen en de logica verplaatsen naar snellere unit en integration tests. Resultaat? Een suite van 25 minuten die daadwerkelijk werd gedraaid.
Als end-to-end testing meer dan 30% van je geautomatiseerde tests uitmaakt, heb je waarschijnlijk een ice cream cone anti-pattern: een omgekeerde testpiramide.
Edge cases testen op het verkeerde niveau
Edge cases (randgevallen), zoals wat er gebeurt als een gebruiker een negatief aantal producten invult of een emoji als postcode gebruikt, zijn belangrijk om te testen. Maar niet op e2e-niveau. Die horen bij unit tests of integration tests, waar ze in milliseconden draaien in plaats van seconden. Bewaar je e2e tests dus voor de kritieke paden die je gebruikers het vaakst doorlopen. Bekijk ook hoe integratietesten een laag lager dezelfde grens bewaken.
Instabiele tests accepteren als "normaal"
"Ach, die test doet soms raar, gewoon opnieuw draaien." Maar elke keer dat je dat doet, erodeert het vertrouwen in je testsuite. Teams die instabiele tests tolereren, missen uiteindelijk echte bugs.
Geen onderhoudsstrategie hebben
End-to-end testing vereist onderhoud omdat applicaties veranderen. Reserveer 20 tot 30 procent van je testtijd voor het bijwerken en opschonen van bestaande tests.
Alle tests in je CI-pipeline proppen
Als je volledige e2e-suite bij elke commit draait, wordt je feedbackloop onacceptabel lang. Draai alleen smoke tests bij elke commit (binnen 15 minuten klaar). De volledige suite draai je 's nachts.
Deze valkuilen hebben allemaal iets gemeen: ze ontstaan omdat teams te veel willen testen op e2e-niveau. Maar hoeveel e2e tests heb je dan eigenlijk nodig?
De testpiramide: waarom 10% e2e genoeg is
De test automation pyramid (testpiramide) is een model dat beschrijft hoe je je tests het beste kunt verdelen. Onderaan staan unit tests: snel, stabiel, en ze vormen de basis met ongeveer 70% van je tests. In het midden zitten integration tests, die controleren of onderdelen correct samenwerken, goed voor zo'n 20%. En bovenaan, de punt van de piramide, staan je end-to-end tests: maximaal 10%.
Waarom zo weinig? Omdat e2e tests de duurste tests zijn die je hebt. Ze kosten de meeste tijd om te schrijven, de meeste tijd om te draaien, en de meeste tijd om te onderhouden. Elke e2e test die je schrijft, moet dus echt zijn gewicht waard zijn.
Concreet betekent dit dat je end-to-end tests schrijft voor je kritieke gebruikersreizen. Denk aan de checkout flow van een webshop, het inlogproces, of de betaalflow. Dit zijn de paden waar een bug direct geld kost of gebruikers wegjaagt. Alles daarbuiten, zoals validatieregels, foutmeldingen, of administratieve schermen, test je op een lager niveau.
Een vuistregel die goed werkt: als je CI/CD-pipeline langer dan 30 minuten duurt, heb je waarschijnlijk te veel end-to-end tests. Dat is het moment om kritisch te kijken naar wat je op welk niveau test.
En als je die verdeling eenmaal hebt, wil je natuurlijk ook dat je tests slim draaien in je pipeline.
Hoe pas je e2e tests in je CI/CD-pipeline in?
De truc is om je e2e tests in twee groepen te splitsen. De eerste groep zijn je smoke tests: een handvol tests die je allerkritiekste flows dekken, zoals inloggen, een bestelling plaatsen, en een betaling afronden. Deze groep draait bij elke commit en moet binnen 15 minuten klaar zijn. Als een smoke test faalt, weet je direct dat er iets fundamenteels mis is.
De tweede groep is je volledige e2e-suite. Die draai je 's nachts, buiten werktijden. 's Ochtends bekijk je de resultaten en pak je eventuele problemen op. Dit geeft je het beste van twee werelden: snelle feedback overdag en uitgebreide testdekking 's nachts.
Een team dat deze aanpak invoerde, ging van 200 e2e tests bij elke commit (90 minuten) naar 15 smoke tests (8 minuten) plus de volledige suite 's nachts. Het verschil was enorm: snellere feedback, minder contextswitching, en een team dat weer vertrouwen had in hun end-to-end testing pipeline.
Maar zelfs de best ingerichte pipeline helpt niet als je tests niet stabiel blijven. Daarom is onderhoud misschien wel het belangrijkste onderdeel van je e2e-strategie.
Hoe je e2e tests stabiel en onderhoudbaar houdt
Onderhoud is waar de meeste teams struikelen bij end-to-end testing. Schrijven is het leuke gedeelte, onderhouden is het harde werk. Het begint bij expliciete waits:
// Slecht: vaste wachttijd
await page.waitForTimeout(5000);
// Goed: wacht tot element er daadwerkelijk is
await page.waitForSelector('.product-loaded');
await expect(page.locator('.product-title')).toBeVisible();
De eerste variant wacht altijd 5 seconden, ongeacht of de pagina al klaar is. De tweede wacht precies lang genoeg: sneller en stabieler.
Daarnaast is het belangrijk dat elke test zijn eigen testdata aanmaakt. Als meerdere tests dezelfde testgebruiker gebruiken, beinvloeden ze elkaar en krijg je instabiliteit.
Bouw ook retries in: maximaal twee keer opnieuw proberen, maar log altijd waarom de test faalde. En de belangrijkste regel: als een test twee keer achter elkaar faalt zonder codewijziging, fix hem of verwijder hem. Instabiele tests zijn als een kapotte rookmelder.
End-to-end testing bouwt voort op een solide basis van integratietests. Begin ook met API testing om je backend te valideren voordat je volledige gebruikersflows test.
Wanneer begin je, en wat is je eerste stap?
Als je team al unit tests en integration tests schrijft en een werkende CI/CD-pipeline heeft, ben je klaar om met end-to-end testing te starten. Heb je dat nog niet? Begin daar eerst, want e2e tests zonder die basis zijn als een dak zonder muren.
Je eerste stap: identificeer je drie belangrijkste gebruikersflows. Welke paden leveren het meeste geld op? Waar klagen gebruikers het snelst? Dat zijn je eerste e2e tests. Drie tot vijf goed onderhouden tests geven je al meer vertrouwen dan een suite van 200 wankele tests.
Wat je morgen anders kunt doen
End-to-end testing is een van de krachtigste vormen van testen die je tot je beschikking hebt, maar alleen als je het met mate inzet. De testpiramide is je kompas: 10% e2e, niet meer. Focus op je kritieke gebruikersreizen, houd je tests kort en stabiel, en investeer bewust in onderhoud.
Je hoeft niet alles tegelijk aan te pakken. Kies vandaag een kritieke flow, schrijf daar een test voor, en draai die test bij elke commit. Dat is je startpunt. Volgende week voeg je er een toe. En de week daarna weer een. Binnen een maand heb je een kleine maar solide suite die je echt vertrouwen geeft bij elke release.
Want het doel van end-to-end testing is niet zoveel mogelijk tests hebben. Het doel is vertrouwen. Vertrouwen dat je applicatie werkt voor je gebruikers, elke keer opnieuw. En dat vertrouwen bouw je op met minder, betere tests.
Wil je eens sparren over hoe end-to-end testing er voor jouw team uit zou zien? Of loop je vast met een trage, instabiele testsuite? We denken graag vrijblijvend met je mee. Plan een gesprek
Wil je jouw end-to-end testing naar een hoger niveau tillen? Ontdek hoe wij je team kunnen ondersteunen.
