In het kort: Een ketentest controleert een complete klantreis door alle systemen erachter, van zoeken tot de order in het magazijn. Je noemt het ook end-to-end testen. In e-commerce is het de enige test die controleert wat je klant echt doet. Houd het bij een handvol belangrijke klantreizen, gebruik testdata die je zelf beheert en spreek af wie eigenaar is als meerdere leveranciers opleveren.

Stel je een release voor waarbij elke leverancier zijn eigen deel heeft getest. Het bureau testte de front-end, de platformleverancier het platform en IT de koppeling met het ERP. Alles groen. Dan bestelt de eerste klant een product met een kortingscode, betaalt, en komt de order zonder korting in het magazijn aan. Geen enkele test faalde, want niemand testte de bestelling van begin tot eind. Dat gat dicht je met een ketentest.

Wat is een ketentest?

Een ketentest controleert een volledig proces door een applicatie en alles waar die van afhangt, zoals een echte gebruiker het doorloopt. Een unittest controleert één stukje code en een API-test één dienst. Een ketentest volgt de hele reis. In een webshop zoekt een klant een product en legt het in het winkelmandje. Hij gebruikt een actie, logt in, betaalt en krijgt een bevestiging. Daarna gaat de order naar het ERP, het magazijn en de klantenservice. Een ketentest controleert dat allemaal in één keer. Hij kijkt naar de uitkomst waar het telt: het juiste product, de juiste prijs en het juiste adres aan het eind van de keten. In het Engels heet dit end-to-end testing. Het nadeel is dat ketentests traag en kwetsbaar zijn, omdat ze elk systeem tegelijk raken. Daarom houdt de testpiramide ze bewust klein, met de meeste controles lager in de piramide.

Waarom is een ketentest in e-commerce lastiger?

Omdat de keten lang is en niemand hem helemaal bezit. Een gemiddelde webshop draait op een front-end, een commerceplatform, een contentsysteem, zoeken, inloggen, een betaalprovider, een ERP en een magazijnsysteem. Een aantal daarvan komt van verschillende leveranciers, elk met een eigen releaseritme en eigen tests. Bij klanten zien we steeds hetzelfde patroon. Elke leverancier levert op en test zijn eigen deel. Business en QA zijn daarna veel tijd kwijt aan het controleren van losse opleveringen, en de sprintdoelen komen onder druk. Processen die door meerdere systemen lopen, worden zelden van begin tot eind geautomatiseerd. Niemand is eigenaar, niemand overziet het geheel en het krijgt nooit voorrang. Het gevolg: veel automatisering, en toch te veel incidenten in productie.

Welke klantreizen neem je op in je ketentest?

Alleen een handvol: de reizen die geld of klanten kosten als ze breken. De rest hoort in snellere tests lager in de piramide. Een goede eerste set voor een webshop:

• Van zoeken tot betaalde order. Een product vinden, in het mandje leggen, afrekenen en betalen met je meest gebruikte betaalmethode.
• Een actie bij het afrekenen. Een korting of bundel die tot op de factuur moet blijven kloppen.
• Een terugkerende klant. Inloggen, de orderhistorie zien en opnieuw bestellen.
• De order na de checkout. De order komt met de juiste producten, prijs en adres aan in ERP en magazijn.
• Retour of annulering. Het geld komt terug bij de klant en de voorraad wordt bijgewerkt.

Test de bedrijfsregels achter deze reizen, zoals kortingslogica en voorraad, op API-niveau. Dat is sneller en stabieler, zoals we uitleggen in ons artikel over API testen. De ketentest hoeft dan alleen nog te bewijzen dat de onderdelen samen werken.

Hoe houd je ketentests stabiel?

De meeste instabiele ketentests falen op hun omgeving, niet op de software. De data was veranderd, een gekoppeld systeem was traag of een ander team testte in dezelfde omgeving. Vier gewoontes helpen:

1. Gebruik testdata die je zelf beheert. Maak de klant, producten en prijzen die de test nodig heeft vooraf aan, en zet ze daarna terug.
2. Gebruik een vervanger waar een systeem er niet toe doet. Gaat een reis over de checkout, dan houdt een vervanger voor een externe dienst de test stabiel. Houd wel een paar tests tegen de echte koppelingen.
3. Wacht op een toestand, niet op seconden. Moderne tools zoals Playwright wachten tot de pagina klaar is, in plaats van vaste pauzes te gebruiken.
4. Draai ze elke nacht. Een test die dagelijks draait, wordt snel gerepareerd. Een test die eens per kwartaal draait, is verouderd voordat hij begint.

In ons artikel over flaky tests lees je meer over tests die falen terwijl er niets veranderde.

Wie is eigenaar van de ketentest bij meerdere leveranciers?

Iemand moet eigenaar zijn van de keten, niet alleen van de onderdelen. In de praktijk is dat de organisatie die aan de klant verkoopt: jij. Leveranciers testen hun eigen opleveringen. Eén partij beheert de ketentest, draait hem tegen elke combinatie van releases en meldt wat breekt, ongeacht wie het veroorzaakte. Dat verandert ook hoe je naar snelheid kijkt. QA wordt vaak de bottleneck genoemd, terwijl de oorzaak meestal in het hele opleverproces zit. Extra testers toevoegen is dan als de A4 verbreden zonder de verkeersstromen eromheen te verbeteren: meer capaciteit, nauwelijks betere doorstroming. Een kleine ketentest die elke nacht draait, doet meer dan een groot team dat elke oplevering met de hand controleert.

Wat betekent dit voor je team?

Schrijf je vijf belangrijkste klantreizen op. Vraag per reis wie hem vandaag van begin tot eind test, en hoe vaak. Is het antwoord “elke leverancier test zijn deel” of “we controleren het met de hand voor een grote release”, dan heb je het gat gevonden.

Bij dat deel helpen we teams. We testen over leveranciers en systemen heen, zodat een release als één keten wordt gecontroleerd en niet als losse opleveringen. Meer daarover lees je op onze pagina over e-commerce testen. Met Test Automation as a Service bouwen en draaien we de ketentest en de snellere tests eronder, elke nacht, samen met je team.

Veelgestelde vragen

Wat is het verschil tussen een ketentest en een integratietest?

Een integratietest controleert of twee systemen samenwerken, bijvoorbeeld de webshop en de betaalprovider. Een ketentest volgt een hele klantreis door alle systemen. Je hebt ze allebei nodig: integratietests vinden een probleem snel, ketentests bewijzen dat de reis werkt.

Wat is het verschil tussen een ketentest en een acceptatietest?

Een acceptatietest controleert of iets doet wat de business vroeg, vaak met gebruikers uit de organisatie. Een ketentest controleert of de keten technisch en functioneel van begin tot eind werkt. Een acceptatietest kan de vorm van een ketentest hebben, maar het doel is anders.

Hoeveel ketentests heb je nodig?

Minder dan de meeste teams denken. Een handvol belangrijke klantreizen dekt meestal de grootste risico’s. Zet de variaties, zoals elk type korting of elke betaalmethode, in snellere API-tests eronder.

Kun je ketentests automatiseren?

Ja, en voor een webshop die elke week verandert is dat slim. Voorwaarde is stabiele testdata en een eigenaar die een kapotte test dezelfde dag repareert. Zonder die twee kleuren geautomatiseerde ketentests zo vaak rood dat niemand er nog naar kijkt.