QA Tester Voorbeeldvragen: Wat te vragen in technische interviews

Waarom standaard QA-vragen niet werken bij werving

De meeste QA-interviewvragen vallen in twee vallen: ze zijn óf zo generiek ("Wat is het verschil tussen testen en QA?") dat iedereen die een certificeringsexamen haalt ze kan beantwoorden, óf zo specifiek voor jouw tech stack dat ze frameworkkennis testen in plaats van denkvaardigheden. Kandidaten die testterminologie uit hun hoofd kennen, klinken competent. Degenen die werkelijk software breken en processen verbeteren, zijn onzichtbaar.

Goede QA-vragen meten teststrategie, niet terminologie. Ze onthullen wat kandidaten werkelijk doen als ze geen testplan hebben om te volgen. Gestructureerde QA- en testautomatiseringsassessments sluiten beide hiaten door kandidaten te beoordelen op realistische gebreken-opsporing in plaats van woordenschatkennis.

Voorbeeldvraag #1: Het bug report-scenario

"Je test een e-commerce checkout-flow. De betaalgeway accepteert soms dubbele transacties—dezelfde orderID, dezelfde bedrag, binnen 5 seconden. Het gebeurt ruwweg 1 op de 50 keer. Loop me door hoe je dit zou onderzoeken en documenteren."

Wat je meet:

• Stellen ze verduidelijkingsvragen (welke betaalmethode? welke browser? netwerkvoorwaarden)?
• Onderscheiden ze tussen bugreprodutie, hoofdoorzaak en scope (zit het in hun code of in die van de gateway)?
• Kunnen ze een testcase articuleren die het opnieuw vangt?
• Zouden ze escaleren of zelf eerst proberen het te reproduceren?

Dit onthult of ze denken als ingenieurs (hoofdoorzaak, scope, preventie) of alleen als rapporteurs (symptoom, screenshot, ticket).

Voorbeeldvraag #2: De automatiseringsafweging

"Je hebt een testsuite die end-to-end in 2 uur draait. Je team voert het eenmaal per dag uit. Een teamgenoot stelt voor om de UI-flow voor afbeeldingoverdrachten te automatiseren—ongeveer 40 regels Selenium en 15 minuten onderhoud per kwartaal. Doe je het? Loop me door je redenering."

Wat je meet:

• Denken ze over ROI (kosten van automatisering versus kosten van handmatig hertesten)?
• Weten ze wanneer automatisering overhead is, niet efficiëntie?
• Kunnen ze de onderhoudsbelasting eerlijk inschatten?
• Beschouwen ze fragiliteit en foutalarmen?

Kandidaten die zeggen "ja, automatiseer alles" of "nee, UI-tests zijn wankel" missen het punt. Het juiste antwoord is meestal "het hangt ervan af wat het vangt en hoe vaak het breekt."

Voorbeeldvraag #3: De testontwerp-uitdaging

"We bouwen een feature die gebruikersgegevens naar CSV exporteert. Het bestand kan 10 tot 100.000 rijen hebben. Wat zou je testen? Wat zou je niet testen en waarom?"

Wat je meet:

• Kunnen ze prioriteren (CSV-indeling, rangetallen edge cases, speciale tekens) versus ruis (doet de knopkleur ertoe)?
• Weten ze wat het waard is om te automatiseren versus ter plekke in te checken?
• Kunnen ze risico articuleren (gegevenslekking, opmaakbeschadiging) versus voorkeur?

Goede QA-ingenieurs zijn genadeloos over scope. Ze testen niet alles; ze testen wat het bedrijf zou kunnen schaden.

Voorbeeldvraag #4: Het regressierisico

"Je team heeft zojuist de databasequery's op de gebruikersprofielpagina herstructureerd. Er waren geen schemawijzigingen, alleen codeopschoning. Wat is je teststrategie? Wat is je vertrouwensniveau?"

Wat je meet:

• Willen ze de volledige regressiesuite uitvoeren of kritisch nadenken?
• Kunnen ze identificeren wat kon breken (N+1 queries, verkeerde gegevensbinding)?
• Begrijpen ze het verschil tussen "code is veranderd" en "risico is veranderd"?

Dit scheidt analisten van ingenieurs. Ingenieurs vragen "wat is veranderd en wat is belangrijk?" Analisten voeren de volledige suite uit, ongeacht.

Voorbeeldvraag #5: De cross-browser vraag (met een twist)

"Je test een nieuw UI-component op Chrome, Firefox en Safari. Het rendert correct overal. Test je het op IE11? Op mobiele Chrome? Op Chromium-gebaseerde browsers zoals Edge? Maak de afwegingsbeslissing."

Wat je meet:

• Kennen ze hun gebruikersbestand (niet alle producten hebben IE11-ondersteuning nodig)?
• Kunnen ze browserdekking inschatten versus testkosten?
• Kennen ze het verschil tussen echte browsers en nepbijdrage?

Dit is waar mening belangrijk is. "We ondersteunen IE11 niet, dus nee" is sterker dan "we zouden alles moeten testen."

Voorbeeldvraag #6: De live coding-interview (kort)

"Schrijf een testcase in welk framework je het beste kent. Ik geef je een simpele functie: validateEmail(email). Geef waar terug als het een geldig e-mailadres is, onwaar anders. Schrijf de test—schrijf niet de functie."

Wat je meet:

• Kunnen ze nadenken over edge cases (lege string, geen @, meerdere @'s, spaties)?
• Schrijven ze tests die leesbaar zijn of cryptisch?
• Kennen ze hun testframework (assertions, setup/teardown)?
• Testen ze gedrag of implementatie?

Dit is een live coding-interview dat 10 minuten duurt en taalvloeiendheid, teststructuur en denken blootlegt.

Het patroon dat werkt

Al deze zes vragen hebben dezelfde structuur: presenteer een echte (of realistische) situatie, vraag de kandidaat er doorheen te redeneren, en luister naar oordeel, niet naar sleutelwoordherinnering. De antwoorden zijn niet goed of fout. Ze zijn onthullend.

De interviews die je onthouden, zijn die waarin een kandidaat jou een verduidelijkingsvraag stelt die je doet pauzeren. Dat is het signaal. Dat is de aanstelling.

Wanneer je geschreven assessments gebruikt

Niet elke QA-aanstelling heeft een opgenomen live coding-interview nodig. Een take-home testcasetaak kan net zo onthullend zijn: "Hier is een feature-specificatie. Schrijf 10-15 testcases die je jouw team zou voorstellen. Leg uit waarom je ze prioriteert." Stel vervolgens vervolgvragen in de volgende ronde over hun redenering. Dit combineert artefactenkwaliteit met verbale verdediging.

Voor schaalvergroting van werving helpen assessment-platforms die testcasedekking, assertiekwaliteit en edge-case-denken kunnen beoordelen, live-ronden efficiënter te maken.

Tegenovergestelde overweging

Sommige teams geven de voorkeur aan gedraggebaseerde interviews zonder testterminologie: "Vertel me over een bug die je vond die je verraste" of "Loop me door de laatste keer dat je tegen een deadline in ging omdat testen niet klaar was." Dit werkt ook, vooral als je mensen aanstelt die eigenaar zijn van kwaliteit in plaats van mensen die testers zijn.

De vragen zijn minder belangrijk dan de filosofie: je meet denken, niet geheugen. Alles ander volgt daaruit.