QA-tester voorbeeldvragen: wat vragen tijdens technische interviews
Waarom standaard QA-vragen aanstellingsfalen
De meeste QA-interviewvragen vallen in twee valkuilen: zij zijn óf zo generiek ("Wat is het verschil tussen testen en QA?") dat iedereen die een certificaatexamen heeft gehaald kan antwoorden, óf zo specifiek voor je tech-stack dat ze frameworkkennis testen in plaats van denken. De kandidaten die testterminologie onthouden klinken competent. De degenen die werkelijk software breken en processen repareren zijn onzichtbaar.
Goeide QA-vragen meten teststrategie, niet terminologie. Ze onthullen wat kandidaten werkelijk doen wanneer ze geen testplan volgen.
Voorbeeldvraag #1: Het bug-rapport-scenario
"Je test een e-commerce checkout flow. De betalingsgateway accepteert soms dubbele transacties — dezelfde order ID, dezelfde bedrag, binnen 5 seconden. Het gebeurt ruwweg 1 op 50 keer. Stap je door hoe je dit zou onderzoeken en documenteren."
Wat je meet:
- Stellen ze ophelderingsvragen (welke betalingsmethode? welke browser? netwerkvoorwaarden)?
- Onderscheiden ze tussen bug reproductie, root oorzaak en scope (zit het in hun code of in de gateway)?
- Kunnen ze een testcase artikuleren die het opnieuw vangt?
- Zouden ze escaleren of het eerst zelf reproduceren?
Dit onthult of ze als engineers denken (root oorzaak, scope, preventie) of gewoon als reporters (symptoom, screenshot, ticket).
Voorbeeldvraag #2: De automationtrade-off
"Je hebt een testreeks die 2 uur eind-tot-eind loopt. Je team voert het eenmaal per dag uit. Een teamgenoot stelt voor het UI-flow voor afbeelding uploads te automatiseren — ongeveer 40 regels Selenium en 15 minuten onderhoud per kwartaal. Doe je het? Stap me door je redenering."
Wat je meet:
- Denken ze na over ROI (kosten om te automatiseren versus kosten voor handmatig opnieuw testen)?
- Weten ze wanneer automatisering overhead is, niet efficiëntie?
- Kunnen ze onderhoudslas eerlijk schatten?
- Houden ze rekening met fragiliteit en false positives?
Kandidaten die zeggen "ja, automatiseer alles" of "nee, UI tests zijn flaky" missen het punt. Het juiste antwoord is meestal "het hangt af van wat het vangt en hoe vaak het breekt."
Voorbeeldvraag #3: De testdesign-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 prioritering (CSV-formaat, rijtelkaantwallen, speciale karakters) versus ruis (doet knopkleur ertoe)?
- Weten ze wat waard is om te automatiseren versus puntcontroles?
- Kunnen ze risico (gegevenslekking, formatteringcorruptie) versus voorkeur artikuleren?
Goeide QA-ingenieurs zijn meedogenloos over scope. Ze testen niet alles; ze testen wat het bedrijf kan kwetsen.
Voorbeeldvraag #4: Het regressierisico
"Je team refactorde net de databasequeries op de gebruikersprofielpagina. Er waren geen schema-wijzigingen, gewoon code opschoon. Wat is je teststrategie? Wat is je vertrouwensniveau?"
Wat je meet:
- Willen ze de volledige regressietest-suite uitvoeren of denken kritisch?
- Kunnen ze identificeren wat kon breken (N+1 queries, verkeerde gegevensbinding)?
- Begrijpen ze het verschil tussen "code veranderde" en "risico veranderde"?
Dit scheidt analisten van ingenieurs. Ingenieurs vragen "wat veranderde en wat zaken?" Analisten voeren de volledige suite uit onafhankelijk.
Voorbeeldvraag #5: De cross-browser vraag (met twist)
"Je test een nieuw UI-component op Chrome, Firefox en Safari. Het geeft correct weer overal. Test je het op IE11? Op mobiel Chrome? Op Chromium-gebaseerde browsers zoals Edge? Maak de trade-off aanroep."
Wat je meet:
- Weten ze hun gebruikersbasis (niet alle producten hebben IE11 ondersteuning nodig)?
- Kunnen ze browserabdecking tegen testkosten schatten?
- Weten ze het verschil tussen echte browsers en nep-dekking?
Dit is waar mening zaken. "We ondersteunen IE11 niet, dus nee" is sterker dan "we moeten alles testen."
Voorbeeldvraag #6: Het live codeerprogramma (kort)
"Schrijf een testcase in wat framework je het best kent. Ik geef je een eenvoudige functie: validateEmail(email). Return true als het een geldige e-mail is, false 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?
- Weten ze hun testframework (assertions, setup/teardown)?
- Testen ze gedrag of implementatie?
Dit is een live coderingsprogramma dat 10 minuten duurt en taal vloeiendheid, teststructuur en denken oppervlakt.
Het patroon dat werkt
Al zes van deze vragen hebben dezelfde structuur: presenteer een echte (of realistische) situatie, vraag de kandidaat erover na te denken, en luister naar oordeelsvermogen, niet trefwoordterugbellen. De antwoorden zijn niet juist of fout. Ze zijn onthullend.
De interviews die je onthoud zijn degenen waar een kandidaat je een ophelderingsvraag stelt die je pauzeert. Dat is het signaal. Dat is de aanstelling.
Wanneer je schrijft assessments gebruikt in plaats daarvan
Niet elke QA-aanstelling heeft een opgenomen live coderingsprogramma nodig. Een take-home testcase-toewijzing kan even onthullend zijn: "Hier is een feature-spec. Schrijf 10-15 testcases die je zou voorstellen aan je team. Leg je prioriteit uit." Vraag dan vervolgvragen in de volgende ronde over hun redenering. Dit combineert artifact-kwaliteit met verbale verdediging.
Voor schaal-aanstellingen, assessmentplatforms die testgevalkwaliteit, assertionkwaliteit en edge-case-denken kunnen graderen maken live-rondes efficiënter.
Tegen-overweging
Sommige teams geven voorkeur aan gedraag-eerste interviews zonder testterminologie helemaal: "Vertel me over een bug die je vond die je verraste" of "Stap me door de laatste keer je tegenspraak maakte op deadline omdat testen niet klaar was." Dit werkt ook, vooral als je mensen aanstelt die kwaliteit bezitten in plaats van mensen die zijn testers.
De vragen zaken minder dan de filosofie: je meet denken, niet geheugen. Alles volgt daarna.