Your Test Professionals

14/10/2026

07/10/2026

Alle lokale tests zijn groen. De bestelling komt niet aan.

De berekening klopt, het event ziet er goed uit en de mock geeft het verwachte antwoord.
In AWS ontbreekt alleen één ding: het recht om naar de tabel te schrijven.

De mock heeft precies gedaan wat je erom vroeg: een geslaagde schrijfactie teruggeven. Of de functie in AWS echt mag schrijven, heeft die test echter nooit gecontroleerd.

Serverless testing draait om die vraag: wat zegt een groen resultaat eigenlijk over de uitgerolde applicatie?
Welke controles doe je lokaal, en wanneer heb je echte AWS-resources nodig?

In ons nieuwe artikel lopen we de complete route door: van unit tests en lokale emulatie tot cloudbewijs voor rechten, duplicaten en cold starts.

Lees het artikel via de link in de reacties.

16/09/2026

Ongeveer 80% van de bugs in numerieke invoer zit op of rond een grenswaarde. Niet ergens verspreid in je testdata, maar precies op de rand.

Dat is goed nieuws. Het betekent dat je met veel minder testcases juist meer bugs vangt, zodra je op de juiste plekken test. Eén waarde per equivalentieklasse, de grenzen erbij en je dekt de kritieke scenario's zonder honderden tests te schrijven.

Minder testen die meer vinden, dat is precies waar equivalence partitioning en boundary value analysis om draaien.

Wil je weten hoe je die grenzen herkent, ook bij lastige datatypes zoals percentages en bedragen in centen?
We leggen het stap voor stap uit in ons nieuwe artikel.

Lees het hier: [link]

11/09/2026

Exploratory testing klinkt soms misschien als vrij rondklikken. Toch werkt het alleen goed met meer structuur, niet met minder. Een sterke sessie heeft een doel, een tijdsgrens en een hypothese die je onderweg bijstelt op basis van wat je ontdekt. Zonder die structuur test je wel, maar leer je weinig.

Het verschil zit dus niet in "wel of geen plan". Het zit in hoe je dat plan gebruikt.
We schreven op hoe je exploratory testing gestructureerd aanpakt, inclusief een sessiemodel dat je morgen al kunt gebruiken.

26/08/2026

Een snelle rollback betekent niet automatisch dat je release veilig is.
Bij blue-green deployment kun je technisch snel terugschakelen. Maar wat gebeurt er met je database, sessies, events en gebruikersdata?
En bij canary testing geldt: geleidelijk uitrollen heeft weinig waarde als je niet weet welke metrics je moet monitoren.

De release-aanpak is pas veilig als je ook de randvoorwaarden op orde hebt.
Lees meer over canary testing versus blue-green deployment:

(link in comments)

19/08/2026

"Gaan we voor continuous delivery of continuous deployment?"

Die vraag lijkt klein, maar het antwoord bepaalt hoe jij als tester je werk doet. Test je features vóórdat ze live gaan, of bouw je juist mee aan systemen die zichzelf in productie testen?

We doken in het verschil, met concrete voorbeelden uit de praktijk: van YAML-pipelines tot monitoring queries die je helpen de juiste keuze te maken voor jouw team.

(link in comments)

12/08/2026

Een canary release voelt vaak veilig omdat je “maar een klein deel” van je gebruikers raakt.

Maar klein uitrollen is nog geen gecontroleerd uitrollen.

Het verschil zit in wat je meet.

Bij een goede canary release kijk je niet alleen naar algemene signalen zoals uptime of totale error rate. Juist daar kan het misgaan, omdat een probleem in één kritieke flow makkelijk verdwijnt in het gemiddelde.

Daarom wil je vooraf scherp hebben:

- wat normaal gedrag is voor de oude versie
- welke technische metrics direct moeten opvallen
- welke business metrics laten zien of gebruikers vastlopen
- wanneer je opschaalt, pauzeert of terugrolt

Eigenlijk is het punt heel simpel: een canary release werkt pas goed als je vooraf weet welke signalen je vertrouwt.

In dit artikel zetten we de belangrijkste canary release metrics op een rij, inclusief hoe je ze praktisch gebruikt in je releaseproces.

[link naar artikel in de comments]