Selenium vs. Cypress: Welk testframework moet je aannemen?

De aanstellingsvraag die teams eigenlijk stellen

"Moeten we aannemen op Selenium of Cypress?" is de verkeerde vraag. De juiste vraag is: "Wat verraadt de frameworkkeuze over engineeringvermogen?"

Selenium en Cypress toetsen verschillende dingen op verschillende manieren. In een aanstellingscontext maakt dat verschil uit. Het ene framework toont je of een kandidaat testarchitectuur begrijpt. Het andere toont je of ze snel, broze tests kunnen schrijven die in een demo werken maar in reality breken.

Selenium: De gedistribueerde test

Selenium draait in een apart proces van de browser. Tests zijn client-server. Er is latency, er is async werk, er is real-world complexiteit.

Wat Selenium in aannamen toont:

• Kan de kandidaat async operaties af? (waits, timeouts, race conditions)
• Begrijpen ze WebDriver protocol en browsercommunicatie?
• Kunnen ze debuggen wanneer een test flaky is — is het de app, het netwerk, of de test zelf?
• Weten ze hoe pagina's voor testability structureren (element identification, state management)?

Bij assessment: Een kandidaat die robuuste Selenium-tests schrijft — met expliciete waits, slimme selectors, teardown logic — toont dat ze de echte constraints van browserautomatisering begrijpen. Ze optimaliseren niet voor snelheid. Ze optimaliseren voor betrouwbaarheid.

De downside: Selenium-tests zijn trager om te schrijven, trager om te debuggen, en ze vereisen meer infrastructuurkennis. Een junior kan snel gefrustreerd raken.

Cypress: De synchrone illusie

Cypress draait in-process, in dezelfde browsercontext als de toepassing. Geen WebDriver protocol. Geen latency. Tests lezen als synchroon, eenvoudig JavaScript.

Wat Cypress in aannamen toont:

• Kan de kandidaat schoon, leesbaar JavaScript schrijven?
• Begrijpen ze de constraints van hun framework? (geen cross-tab, geen multiple domains)
• Kunnen ze debuggen als dingen falen (en ze falen, anders dan Selenium)?
• Zijn ze bewust van Cypress's opinions en waarom ze bestaan?

Bij assessment: Een kandidaat die Cypress-beperkingen kent en daarbinnen werkt, toont dat ze documentatie lezen en over toolkeuze nadenken. Een kandidaat die Cypress-constraints probeert om te zeilen (vreemde waits, polling, paginaverversingen) toont dat ze tegen het tool vechten in plaats van het te begrijpen.

De upside: Tests zijn sneller om te schrijven. De downside: Het is makkelijk om tests te schrijven die goed lijken maar eigenlijk broze zijn, omdat Cypress de async-complexiteit verbergt.

Wat elk framework toont over judgment

Hier wordt aannemen subtiel.

Een kandidaat die zegt "Ik zou Cypress gebruiken omdat tests makkelijker zijn om te schrijven" toont dat ze optimaliseren voor write-time snelheid. Waarschijnlijk prima voor een startup, waarschijnlijk slecht voor een 5-jaar-oude monolith.

Een kandidaat die zegt "Ik zou Selenium gebruiken omdat het realistischer is" toont dat ze over productieconstraints nadenken. Maar als ze Selenium voor een eenvoudige SPA kiezen, over-engineeren ze misschien.

De kandidaat die je wilt is degene die zegt: "Het hangt van de app af. Cypress voor dit interne tool, Selenium voor de cross-domain checkout flow, Playwright voor alles anders volgende kwartaal."

Dat is judgment. Dat is wie bugs vindt en test suites onderhoudt.

Welk framework in je assessment gebruiken

Als je iemand aanneemt om een legacy Selenium suite te onderhouden: Gebruik Selenium. Het is als een chirurg vragen om het scalpel te gebruiken dat ze eigenlijk in de OK zullen gebruiken.

Als je voor een moderne SPA aanneemt: Cypress is prima, maar stel vervolgvragen over beperkingen. Als ze "geen cross-domain" niet noemen, denken ze niet kritisch na.

Als het je niet uitmaakt welke ze kennen: Gebruik wat je team het beste kent, zodat je testdesign gradeert, niet syntax. Of gebruik Playwright — het is de derde optie die aanstellingsgesprekken sinds 2024 wint omdat het eerlijk is over wat het doet.

Het assessmentpatroon dat werkt

De frameworkkeuze maakt minder uit dan hoe ze het gebruiken.

Geef ze een spec ("Test de checkout flow") en laat ze kiezen. Hun keuze toont contextbewustzijn. Hun implementatie toont discipline.

Score op deze:

• Identificeren ze de juiste scope? (wat testen, wat overslaan)
• Schrijven ze selectors die UI-veranderingen overleven?
• Hanteren ze waits expliciet of vertrouwen ze op impliciete magic?
• Hebben ze setup/teardown logic, of is elke test broze en geïsoleerd?
• Kunnen ze artikuleren waarom ze deze aanpak in dit framework kozen?

Een kandidaat die 3 robuuste tests in Selenium schrijft, is sterker dan een die 10 broze tests in Cypress schrijft, zelfs als Cypress je standaard is. De discipline maakt meer uit dan het tool.

Tegenposition: Het gaat helemaal om mindset testen

Sommige teams stellen dat het framework helemaal niet uitmaakt — dat goede QA engineers elk framework in een week leren, en aannemen zich op teststrategie zou focussen, niet syntax.

Dit klopt deels. Een sterke probleemoplosser wisselt snel van framework. Maar frameworkkennis toont wel denken: hoe ze async hanteren, hoe ze code structureren, of ze frameworkconstraints eerder hebben meegemaakt. Dat is het patroon dat je wilt zien.

De juiste aanpak: Filter kandidaten niet op framework. Maar beoordeel wel hoe ze binnen een framework denken, en vraag waarom ze deze aanpak kozen.

Waar je op let bij een testautomatisering assessment

Als je een formeel assessment gebruikt, zoek platforms die:

• Kandidaten hun framework laten kiezen (Selenium, Cypress, Playwright, WebDriver, etc.)
• Op testcoverage en codekwaliteit gradeer, niet alleen pass/fail
• De code vastleggen die ze schrijven, zodat je hun structuur en comments kunt beoordelen
• Op uitvoeringstijd en flakiness rapporteren, niet alleen of tests draaide

Het framework is een voertuig. Het echte signal is of ze het goed besturen.