Skip to main content

Visuele QA-checklist: wat je moet controleren voor elke release

Een praktische visuele QA-checklist voor webteams. Behandelt layout, typografie, responsiviteit, cross-browser weergave, interactieve states en toegankelijkheidscontroles die je voor elke release moet uitvoeren.

Checklistinterface met visuele QA-verificatie-items met geslaagd- en mislukt-indicatoren

Visuele QA-checklist: wat je moet controleren voor elke release

Een release uitbrengen zonder visuele QA is een gok. Functionele tests bevestigen dat features werken, maar ze bevestigen niet dat de interface er correct uitziet. Een knop kan elke integratietest doorstaan en toch een formulierveld overlappen op mobiele Safari. Een kop kan perfect weergeven in het Engels en zijn container laten overlopen wanneer deze wordt vertaald naar het Duits.

Deze checklist behandelt de visuele verificaties die elk webteam zou moeten uitvoeren voordat een release naar productie gaat. Gebruik hem zoals hij is of pas hem aan op je specifieke stack en doelgroep.

Waarom een visuele checklist belangrijk is

Visuele bugs zijn bijzonder schadelijk omdat ze direct zichtbaar zijn voor gebruikers. Een verkeerd uitgelijnd element of een kapotte layout ondermijnt het vertrouwen op een manier die een trage API-response niet doet. Toch is visuele QA vaak het meest ad-hoc onderdeel van het releaseproces β€” inconsistent uitgevoerd, door verschillende mensen, zonder gedeelde criteria.

Een geschreven checklist lost dit op door visuele QA herhaalbaar en meetbaar te maken. Iedereen in het team weet wat "visueel geverifieerd" betekent, en geen enkele categorie controles wordt overgeslagen omdat iemand het vergeten is.

Layout en witruimte

Layoutproblemen zijn de meest voorkomende visuele regressies. Controleer deze systematisch:

  • Paginastructuur is intact β€” header, hoofdinhoud, zijbalk (indien aanwezig) en footer worden in de juiste volgorde weergegeven met de verwachte afstanden.
  • Grid- en flexbox-layouts lopen correct over β€” verifieer op desktop-, tablet- en mobiele breedtes. Let op onverwachte kolomoverlopen of elementen die buiten hun containers vallen.
  • Witruimte tussen secties is consistent β€” marges en padding komen overeen met de ontwerpspecificatie. Let op secties die te dicht op elkaar staan of te ver uit elkaar.
  • Geen overlappende elementen β€” controleer dat absoluut gepositioneerde elementen (tooltips, dropdowns, modals) geen inhoud overlappen of buiten het scherm vallen.
  • Sticky en vaste elementen gedragen zich correct β€” sticky headers en vaste footers moeten op hun positie blijven tijdens het scrollen zonder achterliggende inhoud te bedekken.

Bekijk voor geautomatiseerde layoutverificatie over breakpoints heen onze handleiding over cross-browser testworkflows.

Typografie en inhoud

Problemen met tekstweergave zijn subtiel maar beinvloeden de leesbaarheid en professionaliteit:

  • Koppen volgen de juiste hierarchie β€” H1, H2, H3 formaten en gewichten komen overeen met het ontwerpsysteem.
  • Broodtekst is leesbaar β€” lettergrootte, regelhoogte en contrast voldoen aan toegankelijkheidsnormen. Test met echte inhoud, niet met placeholdertekst.
  • Geen tekstafkapping of -overloop β€” lange koppen, vertaalde teksten en dynamische inhoud passen binnen hun containers. Controleer vooral bij langere talen zoals Duits.
  • Links zijn visueel herkenbaar β€” onderstreping, kleur of andere opmaak maakt links identificeerbaar zonder uitsluitend op kleur te vertrouwen.
  • Codeblokken en voorgeformatteerde tekst worden correct weergegeven β€” monospace-lettertypen laden, syntaxiskleuring werkt en horizontaal scrollen verschijnt bij lange regels.
  • Lijsten worden weergegeven met correcte markeringen β€” geordende lijsten tonen nummers, ongeordende lijsten tonen opsommingstekens en nesting is visueel duidelijk.

Responsief gedrag

Responsieve bugs vormen een onevenredig groot deel van door gebruikers gemelde visuele problemen:

  • Mobiele layout (375px breedte) β€” verifieer de volledige pagina op typische mobiele breedte. Navigatie klapt in tot hamburger, afbeeldingen schalen en inhoud wordt verticaal gestapeld.
  • Tablet-layout (768px breedte) β€” hier verschuilen de meeste responsieve bugs zich. Twee-koloms layouts moeten soepel overgaan en aanraakdoelen moeten voldoende groot zijn.
  • Desktop-layout (1440px breedte) β€” de primaire desktopervaring. Multi-kolom layouts worden correct weergegeven en maximale inhoudsbreedtes worden gerespecteerd.
  • Breed desktop (1920px+ breedte) β€” inhoud mag niet uitrekken om ultra-brede schermen te vullen. Controleer dat maximale breedtes en centrering correct werken.
  • Orientatiewisselingen β€” op mobiel en tablet mag het wisselen tussen staand en liggend de layout niet breken.
  • Zoomgedrag β€” browserzoom naar 150% en 200% mag geen overlappende of verborgen inhoud veroorzaken.

Cross-browser weergave

Verschillende browser-engines interpreteren CSS anders. Controleer minstens deze combinaties:

  • Chrome desktop β€” je referentieweergave. De meeste gebruikers zien deze versie.
  • Firefox desktop β€” vangt Gecko-specifieke problemen op met flexbox gap, lettertypemetrics en custom properties.
  • Safari desktop β€” WebKit heeft uniek gedrag voor backdrop-filter, position-sticky en flex-wrap.
  • Safari mobiel (iOS) β€” alle iOS-browsers gebruiken WebKit. Viewportafhandeling, safe-area insets en scrollgedrag verschillen van desktop.
  • Chrome mobiel (Android) β€” verifieer aanraakdoelen, viewport-metarichtlijnen en mobielspecifieke styling.

Je hoeft niet elke browser voor elke pagina te controleren. Prioriteer op basis van verkeersdata: dek de combinaties die 90% van je doelgroep vertegenwoordigen. Zie onze handleiding visuele regressietesten voor meer over het opbouwen van een browsermatrix.

Interactieve states

Interactieve elementen hebben meerdere visuele states. Elke state moet geverifieerd worden:

  • Knoppen β€” standaard, hover, focus, actief, uitgeschakeld en laadstates worden allemaal correct weergegeven en zijn visueel onderscheidbaar.
  • Formulierinvoervelden β€” leeg, gefocust, gevuld, fout en uitgeschakeld. Controleer dat foutmeldingen op de juiste positie verschijnen en de layout niet verschuiven.
  • Navigatie β€” actieve pagina-indicator, hover-effecten op links, dropdownmenu's die openen en sluiten op de juiste positie.
  • Modals en dialoogvensters β€” openen soepel, centreren correct op alle schermformaten en tonen een zichtbare achtergrond. De sluitknop is toegankelijk.
  • Tooltips en popovers β€” verschijnen op de juiste positie ten opzichte van hun trigger. Worden niet afgesneden door overflow-hidden containers of de rand van het scherm.
  • Laadstates β€” skeleton screens, spinners en voortgangsbalken worden correct weergegeven tijdens het ophalen van data.

Afbeeldingen en media

Visuele media vereisen hun eigen set controles:

  • Afbeeldingen laden en worden weergegeven β€” geen gebroken afbeeldingspictogrammen. Alle afbeeldingen hebben passende alt-tekst voor toegankelijkheid.
  • Afbeeldingen zijn correct geschaald β€” geen vervorming of onverwacht bijsnijden. Beeldverhoudingen worden behouden.
  • Responsieve afbeeldingen leveren passende formaten β€” mobiele apparaten downloaden geen desktopformaat afbeeldingen.
  • Video-embeds werken β€” afspeelknoppen worden weergegeven, beeldverhoudingen zijn correct en embeds lopen niet over buiten hun containers.
  • Iconen worden correct weergegeven β€” SVG-iconen worden weergegeven op het juiste formaat en in de juiste kleur. Icon fonts laden zonder terugvalkarakters te tonen.

Toegankelijkheid en kleur

Visuele QA en toegankelijkheid overlappen aanzienlijk:

  • Kleurcontrast voldoet aan WCAG AA β€” tekst en interactieve elementen hebben voldoende contrast tegen hun achtergrond. Controleer zowel licht als donker thema indien van toepassing.
  • Focusindicatoren zijn zichtbaar β€” toetsenbordnavigatie moet een duidelijke focusring tonen op alle interactieve elementen.
  • Donkere modus wordt correct weergegeven β€” als je applicatie donkere modus ondersteunt, verifieer dat alle componenten, afbeeldingen en tekst leesbaar zijn in beide thema's.
  • Geen informatie alleen door kleur overgebracht β€” foutstates, statusindicatoren en verplichte velden gebruiken naast kleur ook iconen of tekst.

Prestatiegerelateerde visuele controles

Prestatieproblemen kunnen zich manifesteren als visuele problemen:

  • Geen layoutverschuiving tijdens laden β€” inhoud springt niet terwijl lettertypen, afbeeldingen of scripts laden. Dit wordt gemeten door Cumulative Layout Shift (CLS).
  • Webfonts laden voor het renderen β€” geen flash of ongestileerde tekst (FOUT) of onzichtbare tekst (FOIT) tijdens het laden van de pagina.
  • Inhoud boven de vouw wordt snel weergegeven β€” het zichtbare deel van de pagina moet binnen 1–2 seconden verschijnen op een goede verbinding.

Pre-release verificatieworkflow

Gebruik deze workflow om de checklist consistent uit te voeren:

  1. Deploy naar staging β€” verifieer tegen een omgeving die productie zo nauwkeurig mogelijk nabootst.
  2. Voer geautomatiseerde screenshottests uit β€” maak referentiebeelden over je browser- en apparaatmatrix. Zie onze CI/CD-automatiseringshandleiding voor instructies.
  3. Beoordeel geautomatiseerde diffs β€” classificeer elke diff als bewust, regressie of ruis.
  4. Voer handmatige steekproeven uit β€” geautomatiseerde tests dekken statische weergave. Verifieer handmatig interactieve states, animaties en randgevallen.
  5. Documenteer resultaten β€” leg vast welke controles geslaagd zijn, welke gefaald hebben en wat is opgelost. Dit creΓ«ert een auditspoor voor toekomstige releases.
  6. Goedkeuren of blokkeren β€” als alle controles slagen, keur de release goed. Als er kritieke visuele bugs overblijven, blokkeer totdat ze zijn opgelost.

De checklist aanpassen aan je team

Deze checklist is bewust uitgebreid. Pas hem voor je team aan op basis van:

  • Je stack β€” als je geen donkere modus ondersteunt, verwijder die controles. Als je een ontwerpsysteem gebruikt, voeg componentniveau-controles toe.
  • Je doelgroep β€” als 95% van je verkeer van Chrome komt, beperk de cross-browser scope en vergroot de mobiele testomvang.
  • Je risicotolerantie β€” omzetkritieke applicaties hebben strengere controles nodig. Interne tools kunnen een lichter proces gebruiken.

Het gaat om consistentie. Een kortere checklist die bij elke release wordt doorlopen is waardevoller dan een uitgebreide die onder tijdsdruk wordt overgeslagen.

Ga verder met ScanU

Geautomatiseerde screenshottesten dekken de meest tijdrovende onderdelen van deze checklist: layoutverificatie, cross-browser weergave en responsieve breakpoint-controles. ScanU maakt screenshots over browsers en apparaten heen zodat je team zich kan richten op interactieve states en randgevallen. Bekijk de abonnementsopties op Pricing, leer meer over het platform op Features en vind antwoorden op veelgestelde vragen in de FAQ.