06 okt 2026 Flaky tests: waarom je geautomatiseerde tests falen terwijl er niets is veranderd

In het kort: Flaky tests slagen de ene keer en falen de andere keer. Aan de code is intussen niets veranderd. Timing, de volgorde van tests en externe diensten veroorzaken er veel. In bedrijfssoftware is de grootste oorzaak vaak testdata die door anderen wordt aangepast. Los dus de data en de omgeving op, niet alleen het testscript.

Eind september publiceerde het opensourceproject Apache Druid zijn wekelijkse overzicht van falende tests. Bij zes van de zeven codewijzigingen van 25 september faalde er een testrun. Van de 35 fouten hadden er 34 dezelfde oorzaak: de tests konden een extern onderdeel niet op tijd downloaden. Geen van die rode uitslagen zei iets over de code die getest werd.

Daar zit de echte schade van flaky tests. Elke rode uitslag die geen echte bug is, leert je team dat rood genegeerd mag worden. Na een tijdje kijkt niemand meer naar de uitslagen.

Wat is een flaky test?

Een flaky test is een geautomatiseerde test die soms slaagt en soms faalt, zonder dat de code of de test zelf is veranderd. Je draait hem twee keer op dezelfde versie en krijgt twee verschillende uitkomsten. Dat is iets anders dan een kapotte test. Een kapotte test faalt elke keer, vaak omdat de applicatie is veranderd en de test niet is bijgewerkt. Een flaky test is op één punt erger: je kunt geen van beide uitkomsten vertrouwen. Groen kan geluk zijn. Rood kan ruis zijn. Neem een test die inlogt, een product in het winkelmandje legt en het totaalbedrag controleert. Negen van de tien keer gaat het goed. De tiende keer laadt de pagina iets trager, de test kijkt naar het totaal voordat het er staat, en de run kleurt rood. Met de webwinkel is niets mis. Met de test, of met de omstandigheden waarin hij draait, wel.

Waardoor ontstaan flaky tests?

De meeste flaky tests hebben een van een paar oorzaken. De test gaat uit van iets in zijn omgeving dat meestal klopt, maar niet altijd. Dit zijn de bekendste:

• Timing. De test kijkt naar het scherm of een antwoord voordat het systeem klaar is. Een vaste pauze van twee seconden werkt op een rustige dag en faalt op een drukke.
• Volgorde. De ene test laat iets achter, zoals een ingelogde gebruiker of een aangepaste instelling. De volgende test rekent daar stilletjes op.
• Externe diensten. De test roept een betaalprovider, een mailserver of het systeem van een ander team aan. Is die traag of plat, dan faalt jouw test.
• Tests die tegelijk draaien. Ze gebruiken hetzelfde account, record of bestand en zitten elkaar in de weg.
• Testdata. Het record dat de test nodig heeft, is veranderd, verlopen of weg.

De eerste vier krijgen online de meeste aandacht. De laatste komen wij in bedrijfssoftware het vaakst tegen.

Waarom is testdata in bedrijfssystemen de grootste oorzaak?

In een webwinkel, een ERP-systeem of een CRM draaien tests niet in een schoon lab. Ze draaien in een gedeelde testomgeving, gekoppeld aan andere systemen en gebruikt door andere teams. De data daarin verandert voortdurend. Iemand test met de hand en sluit precies de order af die jouw test verwacht. Een nachtelijke synchronisatie uit een ander systeem overschrijft het klantrecord. Een kortingscode verloopt aan het eind van de maand. Een product raakt op omdat een andere test het laatste exemplaar kocht. In het testscript zie je daar niets van. De test treft gewoon een andere wereld aan dan waarvoor hij is geschreven, en faalt. Bij e-commercebedrijven zien we dit vaak. Tests falen regelmatig omdat niemand de testdata beheert, of omdat de data in de gekoppelde systemen steeds verandert.

Koppelingen met andere systemen geven nog een tweede laag. In Salesforce-projecten zien we tests af en toe falen omdat een koppeling traag antwoordt of het aantal verzoeken beperkt. Zulke fouten zijn lastig na te bootsen. Tegen de tijd dat iemand kijkt, is de koppeling weer snel en slaagt de test.

Hoe los je flaky tests blijvend op?

Begin met ze vinden. Kijk in de historie van je testruns: welke tests wisselden van uitkomst zonder dat de code veranderde? De meeste CI-tools laten dat per test zien. Markeer die tests, zodat ze opvallen. Pak daarna de oorzaak aan, niet het symptoom.

• Wacht op het juiste moment. Vervang vaste pauzes door controles die wachten tot iets klaar is, zoals een knop die klikbaar is of een antwoord dat binnen is. Tools als Playwright wachten automatisch op elementen voordat ze iets doen.
• Laat elke test op zichzelf staan. Elke test maakt aan wat hij nodig heeft en ruimt daarna op. Geen test rekent erop dat een andere eerst heeft gedraaid.
• Houd zelf de regie over je testdata. Dat is testdatamanagement in gewone woorden. Jij bepaalt welke data je tests gebruiken, in plaats van wat er toevallig in de omgeving staat. Zet voor de run een vaste set klanten, producten en orders klaar en zet die bij elke start terug. Dan treft dezelfde test elke nacht dezelfde wereld aan.
• Vervang externe diensten waar de test er niet over gaat. Een test van je winkelmandje heeft de echte betaalprovider niet nodig. Een vervanger die altijd hetzelfde antwoordt, haalt een hele groep fouten weg. Houd wel een paar aparte tests die de echte koppeling controleren.
• Zet ze in quarantaine, met een eigenaar en een datum. Haal een flaky test uit de hoofdrun, zodat hij releases niet meer blokkeert. Geef hem een naam en een deadline, anders blijft hij daar voor altijd staan.

Wees voorzichtig met automatisch opnieuw draaien. Een gefaalde test herhalen tot hij slaagt, houdt de pipeline groen. Het verstopt ook het probleem. Playwright markeert een test die pas bij een herhaling slaagt als flaky. Dat helpt, zolang iemand dat label ook leest.

Wat kost een onbetrouwbare testset je team?

De directe kosten zijn tijd. Iemand draait de build opnieuw, leest logs en ontdekt dat er niets aan de hand was. De grotere kosten zijn vertrouwen. Als rood meestal “probeer het nog eens” betekent, ziet niemand het nog als signaal. Een echte bug krijgt dan dezelfde behandeling als de ruis. We horen het in veel gesprekken: een test gaat stuk, wordt “even” overgeslagen, en niemand komt er nog op terug. Een jaar later weet niemand of het dekkingspercentage nog iets zegt. Zo valt een regressietest stil: ongemerkt, één overgeslagen test tegelijk.

Grote bedrijven nemen dit serieus. Google publiceerde onderzoek naar het vinden van de oorzaak van flaky tests in zijn eigen code. Voor een kleiner team is de les eenvoudiger: een testset is pas iets waard als rood ook echt iets betekent.

Wat betekent dit voor je team?

Pak je tien belangrijkste tests en bekijk hun uitslagen van de afgelopen maand. Wisselde er een van uitkomst zonder codewijziging? Kijk dan eerst naar de data en de omgeving, en pas daarna naar het script. Spreek daarna af wie de nachtelijke run bezit. Een flaky test zonder eigenaar wordt nooit opgelost.

En dat eigenaarschap is vaak precies wat ontbreekt. Iedereen leunt op de testset, maar niemand heeft tijd om hem bij te houden. Daar helpen we teams bij. Met Test Automation as a Service draaien en onderhouden we je geautomatiseerde regressietests samen met je team, inclusief de testdata waar ze op leunen. We halen tot 70% van het handmatige regressietesten weg, voor teams die hun regressietests nog met de hand doen. Je tests draaien elke nacht, en wij houden ze betrouwbaar. Je krijgt een stabiele testset waar je team op kan vertrouwen, die niet van één persoon afhangt en je team geen extra werk geeft. We bouwen, documenteren en onderhouden de testset, zodat hij van jou blijft.

Veelgestelde vragen

Moet je een flaky test gewoon opnieuw draaien?

Eén keer, om te zien of hij echt flaky is, is prima. Herhalen tot hij slaagt is geen oplossing. Het verstopt de oorzaak, en echte bugs die af en toe optreden verdwijnen op dezelfde manier uit beeld. Houd bij welke tests je opnieuw draait, zodat je ziet welke aandacht nodig hebben.

Zijn flaky tests een teken van slechte testautomatisering?

Niet altijd. Elke testset van enige omvang heeft er een paar. Heeft je testset er veel, dan zijn het meestal dezelfde oorzaken. Denk aan vaste pauzes, tests die van elkaar afhangen en testdata waar niemand de regie over heeft. Dat zijn keuzes die je kunt veranderen.

Hoe ga je om met flaky tests in Playwright of Selenium?

De tool doet er minder toe dan de oorzaak. Playwright wacht automatisch en markeert tests die pas bij een herhaling slagen. Bij Selenium bouw je het wachten zelf in. In beide gevallen doen stabiele testdata en losstaande tests het meeste werk. In onze vergelijking van Playwright en Selenium lees je de andere verschillen.

Wat is testdatamanagement?

Bij testdatamanagement bepaal en beheer je zelf de data waarop je tests draaien. Je zet voor een run een vaste set records klaar en zet die daarna terug. Je tests geven dan elke keer dezelfde uitkomst, zolang de software zich hetzelfde gedraagt.