Visuele regressietest: hoe software automatisch checkt of een website er nog goed uitziet
Stel je een bouwinspecteur voor die van een pand elke maand een foto neemt vanaf precies dezelfde plek. Verandert er iets aan de gevel — een scheve dakgoot, een verzakte stoep, een raam dat anders staat — dan valt dat meteen op zodra je de nieuwe foto naast de oude legt. Een visuele regressietest doet precies dit, maar dan voor websites en apps: een computer maakt automatisch schermafbeeldingen van een digitaal product en vergelijkt die, pixel voor pixel, met een eerdere versie die als referentie geldt.
Het woord "regressie" betekent hier niet dat iets letterlijk achteruitgaat, maar dat een programma per ongeluk een ongewenste verandering heeft veroorzaakt — een knop die opeens verschoven is, tekst die over een afbeelding heen valt, een kleur die niet meer klopt. Programmeurs passen voortdurend code aan, en zulke aanpassingen kunnen onbedoeld het uiterlijk van andere delen van de site beïnvloeden. Een visuele regressietest is de digitale bouwinspecteur die dat soort ongelukjes opspoort voordat een bezoeker ze ziet.
Wat is het precies?
Het proces bestaat in de kern uit drie stappen. Eerst wordt er een baseline vastgelegd: een set schermafbeeldingen van hoe de website of app er op dit moment correct uitziet, bijvoorbeeld de homepage, het inlogscherm en een productpagina. Deze foto's worden meestal niet met een echte browser gemaakt, maar met een zogeheten headless browser — een browser zonder zichtbaar venster die op de achtergrond draait en precies hetzelfde rendert (opbouwt en toont) als een gewone browser, maar dan automatisch aanstuurbaar via code. Bekende voorbeelden van zulke automatiseringsgereedschappen zijn Puppeteer en Playwright.
Vervolgens wordt, telkens als een ontwikkelaar iets aan de code wijzigt, opnieuw een set schermafbeeldingen gemaakt van diezelfde pagina's. Een algoritme vergelijkt daarna de nieuwe afbeeldingen met de baseline via pixel-diffing: het bekijkt letterlijk elke beeldpuntje (pixel) op kleurverschil. Omdat schermen, lettertypes en zelfs de manier waarop een besturingssysteem tekst afrondt subtiele verschillen kunnen veroorzaken die niemand als "kapot" zou ervaren, werkt men met een drempelwaarde: pas als het percentage afwijkende pixels boven een ingestelde grens komt, wordt het gemarkeerd als een mogelijk probleem.
Dit alles gebeurt meestal geautomatiseerd binnen een CI/CD-pipeline — een reeks geautomatiseerde stappen die bij elke codewijziging in werking treedt om te testen, te bouwen en uiteindelijk te publiceren (CI staat voor continuous integration, CD voor continuous delivery of deployment). Wanneer een visuele test een verschil signaleert, krijgt een ontwikkelaar of ontwerper dat te zien, vaak met de oude en nieuwe afbeelding naast elkaar en de verschillen gemarkeerd in een felle kleur. Die persoon beslist dan: is dit een bug die hersteld moet worden, of is het een bewuste, gewenste wijziging? In dat laatste geval wordt de nieuwe afbeelding de nieuwe baseline.
Wat wil men ermee bereiken?
Het belangrijkste doel is simpel: onbedoelde visuele fouten vroeg opsporen, liefst nog voordat een gebruiker ze ooit te zien krijgt. Zonder zo'n test moet iemand handmatig door tientallen pagina's en schermformaten klikken om te controleren of alles er nog goed uitziet — een taak die traag, saai en foutgevoelig is. Bij grote websites met honderden pagina's en meerdere schermgroottes (telefoon, tablet, desktop) is dat handmatig eigenlijk niet meer te doen.
Daarnaast geeft het ontwikkelaars vertrouwen om code te refactoren — bestaande code herstructureren of opschonen zonder de werking te veranderen. Vooral bij CSS, de opmaaktaal die het uiterlijk van een webpagina bepaalt, is het risico op onbedoelde neveneffecten groot: één regel CSS kan ergens anders op de site iets doen verschuiven. Een visuele regressietest fungeert dan als vangnet.
Ten slotte speelt het een rol in kwaliteitsborging binnen grotere teams. Als tientallen ontwikkelaars tegelijk aan hetzelfde product werken, is het praktisch onmogelijk om overzicht te houden over elk visueel detail. Geautomatiseerde controle helpt zulke teams sneller en met meer zekerheid nieuwe versies uit te brengen.
Voorbeelden uit de praktijk
Percy is een van de bekendste gespecialiseerde tools voor visuele tests, opgericht in de tweede helft van de jaren 2010 en in 2020 overgenomen door testplatform BrowserStack. Percy maakt schermafbeeldingen in de cloud op meerdere browsers tegelijk en integreert met veel bestaande CI/CD-systemen.
Applitools, opgericht in Israël rond 2013, promoot wat het bedrijf "Visual AI" noemt: in plaats van elke pixel star te vergelijken, gebruikt het machine learning om te proberen alleen de verschillen te signaleren die een mens ook daadwerkelijk als storend zou ervaren, en kleine ruis (zoals afwijkingen door schermresolutie) te negeren.
Chromatic is gemaakt door het team achter Storybook, een populair open source hulpmiddel waarmee ontwikkelaars losse UI-onderdelen (knoppen, formulieren, kaarten) apart van de rest van de applicatie kunnen bouwen en bekijken. Chromatic voegt daar visuele regressietests bovenop en wordt sinds de tweede helft van de jaren 2010 breed gebruikt, met name in de wereld rond JavaScript-frameworks zoals React.
BackstopJS is een gratis, open source alternatief dat ontwikkelaars zelf op hun eigen servers kunnen draaien, zonder afhankelijk te zijn van een commerciële cloudprovider.
Playwright, een testgereedschap van Microsoft dat rond 2020 uitkwam, heeft visuele vergelijking inmiddels standaard ingebouwd via een functie die schermafbeeldingen automatisch met een opgeslagen referentiebeeld vergelijkt. Dat maakt de drempel om ermee te beginnen een stuk lager, omdat teams niet meteen een apart, extern product hoeven aan te schaffen.
Hoe ver is de techniek?
Visuele regressietesten zijn geen experimentele nieuwigheid meer; het is inmiddels een gangbare, volwassen praktijk binnen professionele webontwikkeling, vooral bij teams die met frequente updates werken. De meeste grote CI/CD-platformen ondersteunen de integratie van dit soort tests probleemloos.
Toch kent de techniek hardnekkige praktische obstakels. Lettertypes en tekstweergave verschillen soms licht tussen besturingssystemen, waardoor twee "identieke" schermafbeeldingen toch als afwijkend worden gemarkeerd — een zogeheten false positive (een test die onterecht een probleem meldt). Animaties, laadindicatoren, actuele tijdstempels of wisselende advertenties zorgen voor vergelijkbare ruis: de pagina is inhoudelijk prima, maar toch net anders op het moment van de foto. Dit soort onbetrouwbare, wisselende testresultaten staat bekend als flakiness, en het is een van de grootste ergernissen bij teams die visuele tests gebruiken — te veel valse meldingen, en ontwikkelaars gaan waarschuwingen simpelweg negeren.
De trend is dat tools steeds slimmer proberen te filteren welke verschillen er werkelijk toe doen, onder meer met machine learning zoals bij Applitools. Zeker is dat dit de false positives vermindert; onzeker is of dit soort AI-gestuurde filtering ooit volledig betrouwbaar wordt, aangezien het risico blijft bestaan dat een systeem een echt relevante fout over het hoofd ziet omdat het die als "onbelangrijke ruis" classificeert.
Wie werken eraan?
Het veld wordt gedomineerd door een mix van gespecialiseerde bedrijven en de bredere open source gemeenschap. BrowserStack, met wortels in de Verenigde Staten en India, is via zijn overname van Percy een van de grotere commerciële spelers. Applitools, met kantoren in Israël en de VS, richt zich specifiek op AI-ondersteunde visuele tests. Het team achter Storybook onderhoudt Chromatic als commercieel product naast het gratis open source Storybook-project.
Microsoft speelt een grote rol via het Playwright-team, dat visuele vergelijking als gratis, ingebouwde functie aanbiedt naast zijn bredere browserautomatiseringswerk. Daarnaast bestaat er een levendige open source gemeenschap rond gratis alternatieven zoals BackstopJS, Loki en reg-suit, vaak onderhouden door individuele ontwikkelaars of kleine collectieven.
Grote techbedrijven zoals Google, Meta en Airbnb gebruiken naar verluidt eigen interne varianten van visuele regressietests binnen hun ontwikkelproces, naast of in plaats van externe tools, gezien de schaal en specifieke eisen van hun producten. Details over de precieze interne implementaties van dit soort bedrijven zijn echter niet altijd publiek gedocumenteerd.