Lever de UI uit die u ontwierp — niet degene die door CI heen glipte

Functionele tests beantwoorden één vraag goed: «doet de knop het juiste wanneer erop geklikt wordt?». Op alles wat vóór de klik gebeurt blijven ze stil — of de knop de juiste kleur, de juiste grootte, de juiste plek heeft, of hij leesbaar is op een scherm van 360 pixels of überhaupt nog zichtbaar is na de laatste CSS-refactor. Precies in die kloof leven de meeste incidenten op releasedag.

Echte regressies die wij zien — en waarvoor ScanU gebouwd is — clusteren rond een handvol voorspelbare aanleidingen:

• Een CSS-refactor laat de gap van een flex-container klappen op één breakpoint. Op desktop ziet de layout er identiek uit; op een tablet van 768 pixels overlappen twee cards nu.
• Een design-token-bump schuift elke spacing-waarde twee pixels op. Niets faalt; een twaalftal zorgvuldig gebalanceerde composities zijn stilletjes niet meer in balans.
• Een third-party-widget — een cookiebanner, een live-chat, een advertentieslot — brengt een stille update uit die de first paint verschuift. Core Web Vitals verslechteren van de ene op de andere dag zonder een code-wijziging aan uw kant.
• Een framework-upgrade wisselt de standaard font-feature-stack. Tekst reflowt een halve regel op longform-pagina’s. Hero-CTA’s zakken plotseling onder de vouw.
• Een feature-flag-rollout herordent het DOM. Op Safari verandert de stacking context van een modal en wordt de close-knop onklikbaar. Op Chrome ziet alles er prima uit.

Geen van deze wijzigingen laat een assertion falen. Alle breken iets voor een gebruiker. De taak van ScanU is om dit tweede soort breuken net zo makkelijk zichtbaar, reviewbaar en blokkeerbaar te maken als een rode unit-test. Wanneer de diff op de pull request verschijnt, kan een designer meewegen zoals een reviewer meeweegt op een function signature — vóór de merge, niet nadat het productie heeft bereikt.

Die verschuiving — van «hopelijk merkt iemand het in staging» naar «we reviewen een visuele wijziging zoals we een code- wijziging reviewen» — is de kernwaarde van een tool voor visuele regressietests in een moderne release-pipeline.

Elke run is een pipeline van drie stappen. Eerst navigeert ScanU in elke browser-engine naar de pagina of het component onder test, wacht op een geconfigureerde set readiness-signalen — geladen fonts, gedecodeerde afbeeldingen, rustig netwerk, een data-ready-attribuut of een eigen JavaScript-probe — en pint alle CSS-animaties op hun laatste frame. Vervolgens wordt de pagina op elk geconfigureerd viewport in dezelfde run vastgelegd, met scroll-stitching voor lange pagina’s zodat u het volledige artefact krijgt en niet alleen het zichtbare deel. Tot slot vergelijkt de pipeline de opname met de geaccepteerde baseline en produceert per (browser, viewport)-paar een resultaat: identiek, binnen tolerantie of significant anders.

De vergelijking zelf is geen naïeve pixel-diff. ScanU past een perceptueel model toe dat anti-aliasing, sub-pixel-rendering en kleurruimte-schommelingen begrijpt, zodat een kerning-eigenaardigheid in WebKit geen bug lijkt. Ook ondersteunt het expliciete maskers voor zones waarvan u weet dat ze bij elke load veranderen — live data, relatieve tijdstempels, gerandomiseerde content, carrousels — zodat die gebieden nul ruis toevoegen aan de diff.

Zodra een echte wijziging opduikt, toont het platform drie gesynchroniseerde panelen: de baseline, de huidige opname en een diff-overlay die precies markeert wat er is bewogen. Per wijziging wordt één beoordeelbare beslissing vastgelegd — accepteren, afwijzen of baseline updaten — en die beslissing wordt deel van de projectgeschiedenis. Geen stille drift en geen automatische acceptatie: de baseline beweegt pas als een geautoriseerd persoon dat uitdrukkelijk zegt.

Dezelfde pipeline kan vanuit drie ingangspunten worden aangestuurd: tegen live-URL’s (productie, staging, PR-previews), tegen een statische site of gebouwde asset- bundle, of tegen componentpreviews in een Storybook-achtige sandbox. De meeste teams gebruiken het eerste als release gate, het tweede voor deploy-artefacten en het derde voor werk aan het design system — alle drie voeden dezelfde baseline-opslag.

Wat de vorm van het team ook is, ScanU wordt doorgaans om een van vijf redenen ingezet: een recent productie-incident dat een visuele regressie zou hebben afgevangen; een design- system-migratie waarvan de impact-omvang onmogelijk handmatig te auditen is; een CI/CD-workflow die een release gate nodig heeft die rijker is dan «tests geslaagd»; een klantgerichte oplevering die voor/na-bewijs vraagt; of een compliance-positie die kiest voor EU-gehoste test-tooling. Een gedeelde CI/CD-integratie zit achter alle vijf — dezelfde pipeline doet het werk, ongeacht of hij door een PR, een merge of een nachtelijke planning wordt getriggerd.

ScanU wordt in de Europese Unie gebouwd en gehost, met opslag en verwerking op in de EU geopereerde infrastructuur. Voor teams met verplichtingen rond gegevenslokalisatie — gereguleerde sectoren, publieke afnemers, privacygevoelige B2B-klanten — is dat vaak een procurement-eis, geen voorkeur. ScanU is ontworpen om aan die eis te voldoen zonder concessies aan productmogelijkheden.

Uit die houding volgen een paar bewuste ontwerpkeuzes:

• Dataminimalisatie. Het platform bewaart screenshots en de metadata die nodig zijn om te diffen; het zuigt geen page source, cookies of request bodies op die niets aan de diff bijdragen.
• Maskering standaard in gevoelige contexten. Velden waarvan bekend is dat ze persoonsgegevens bevatten — account-headers, e-mailadressen, ordernummers — kunnen worden gedeclareerd als gemaskeerde gebieden, zodat de vastgelegde afbeelding al is geredigeerd op het moment dat hij naar de opslag wordt geschreven.
• Toegangscontrole. Wie een diff mag zien is een eersterangs recht. Reviewers, contributors en externe auditors krijgen expliciete rollen, en elke baseline- update wordt gelogd met de persoon die hem heeft geautoriseerd.
• Transparantie over sub-verwerkers. De lijst van sub-verwerkers is gepubliceerd en geversioneerd. Geen verborgen analytics-pipeline ziet uw screenshots.
• Bewaartermijn die u beheert. Baselines en diff-artefacten worden bewaard voor de horizon die u instelt; oude runs verlopen automatisch in plaats van zich stilletjes op te hopen.

Voor het volledige privacybeeld — sub-verwerkers, regionale hosting, verwerkersovereenkomst, bewaartermijnen — zie de AVG- en gegevensverwerkings­documentatie. Voor de meeste teams telt de korte versie: uw screenshots blijven in de EU, en het platform is zo gebouwd dat ze daar blijven.

Visuele bugs clusteren in een handvol terugkerende patronen. Elk lijkt in isolatie triviaal; elk kan in productie belanden zonder één rode test. Allemaal worden ze als diff zichtbaar bij de volgende ScanU-run, vóór de PR wordt gemerged.

• Spacing-verschuivingen. Een gap-utility gaat van 16 naar 20 pixels; een kaartgrid dat eerst rustig ademde, voelt op mobiel plots opgepropt. De HTML is onveranderd; de layout niet.
• Gebroken layouts na deploy. Een upgrade van de build-pipeline laat een PostCSS-plugin vallen die voor het autoprefixen van backdrop-filterzorgde. Op Safari rendert een navigatiebalk plots ondoorzichtig waar hij eerder vervaagde.
• CSS-regressies door specificiteits­verschuivingen. Een gewijzigde volgorde van Tailwind-klassen, een nieuwe utility-laag of een gerefactorde cascade verandert subtiel welke regel wint — een kop verliest zijn accentkleur op een handvol pagina’s.
• Falende responsive breakpoints. Een nieuwe nav-item overloopt het tablet-breakpoint en komt op een tweede regel, waardoor de hero op iPads en grote Android-telefoons onder de vouw zakt.
• Renderingverschillen tussen browsers. Een ontwerp dat op text-wrap: balance leunt, is strak op Chrome maar blijft ongebalanceerd in engines die het nog niet hebben uitgerold. Zonder cross-browser-check is dat onzichtbaar op de machine van de developer.
• Font- en typografiedrift. Een font- leverancier wisselt een subset, gewichten verschuiven honderd gram, en elke paragraaf van een marketingsite reflowt een kwart regel. De tekstdichtheid verandert; geen diff in het repository verklaart het.
• Regressies bij third-party-widgets. Een vendor van consent-banners brengt een update uit die de accept-knop op donkere thema’s onzichtbaar maakt. Uw conversie daalt; uw tests slagen.
• Design-system-drift. Een knopcomponent wijzigt de offset van zijn focus-ring. Twintig consumers hangen aan dat component. Twintig pagina’s zien er nu subtiel anders uit. Niemand reviewt twintig pagina’s met de hand.
• Visuele bugs die naar productie ontsnappen. Alles hierboven, vermenigvuldigd met de routes en breakpoints die in een gegeven week niemand opent, over de browsers die niemand in het team dagelijks gebruikt.

Het feature-overzicht gaat dieper in op de detectie-primitieven — perceptuele toleranties, gemaskeerde gebieden, scroll- capture, baseline-branching — en laat zien hoe elk aansluit op een van de categorieën hierboven. Voor de meeste teams luidt de korte versie: verandert er iets visueel, dan merkt ScanU het; is het gewenst, dan accepteert u het met één klik; is het dat niet, dan hebt u het eerder opgevangen dan wie dan ook.