Beste QA-test voor test automatisering ingenieurs: Je beoordeling bouwen

Wat 'best' betekent voor QA-beoordelingen

Er is geen enkele QA-test die voor elke werving werkt. Maar er is een patroon dat werkt: een gelaagde beoordeling die testdenken van codeersnelheid scheidt, oordeel van kennis, en architectuur van syntaxis.

De beste QA-test is niet de moeilijkste. Het is degene die onthult of de kandidaat een testsuite drie jaar lang zal onderhouden zonder uit te branden.

De ideale beoordelingsstructuur

Deel 1: Testcasusontwerp (geschreven, 30–45 minuten)

Dit is niet onderhandelbaar. Het is het eerste filter.

Geef kandidaten een realistische functiespec—niet 'test login' (te vaag), niet 'schrijf 100 testcases' (te veel). Iets in het midden: 'Hier is een functie om gebruikersgegevens uit CSV bulksgewijs te importeren. Schrijf 8–12 testcases die je aan je team zou voorstellen.'

Wat je beoordeelt:

• Dekking: Identificeren zij grensgevallen (leeg bestand, 100k rijen, speciale tekens)?
• Helderheid: Kan iemand anders deze tests zonder hen te bellen uitvoeren?
• Oordeel: Prioriteren zij kritieke casus of behandelen zij alles gelijk?
• Realisme: Erkennen zij beperkingen (gegevensopstelling, omgeving)?

Gebruik een rubric: dekking 25%, helderheid 25%, oordeel 25%, haalbaarheid 25%. Het is niet perfect objectief, maar het is consistent.

Tijd om te beoordelen: 10–15 minuten per kandidaat. Op schaal kun je scoring templaten.

Deel 2: Automatiseringscode (take-home, 2–3 uur)

Als zij deel 1 halen, stuur hen een take-home. 'Hier is een sandbox-app. Kies 4–5 van de testcases die je net hebt ontworpen en automatiseer ze. Gebruik welk framework je kent.'

Wat je beoordeelt:

• Codecwaliteit: Leesbaar, onderhoudbaar, niet overmatig slim?
• Framework vlotheid: Geldige syntaxis, juiste asserts, slimme waits?
• Robuustheid: Overleefd deze test een kleine UI-wijziging, of is het broos?
• Architectuur: Gebruiken zij page objects, gegevensopstelling, teardown?

Niet beoordelen op snelheid. Een kandidaat die 2 solide tests in 2,5 uur schrijft is sterker dan één die 8 snelle en smerige tests in dezelfde tijd schrijft.

Wat te negeren: Of zij Selenium of Cypress kozen, of zij een specifieke bibliotheek gebruikten. Dit zijn voorkeuren. De testkwaliteit is wat telt.

Tijd om te beoordelen: 15–20 minuten. Zoek naar: selectors die niet zullen breken, waits die zin hebben, asserts die gedrag testen (niet zomaar DOM-staat), en code die menselijk leesbaar is.

Deel 3: Live procesinterview (60 minuten)

Dit is waar oordeel glinsters. Bereid 2–3 scenario's voor:

Scenario 1: 'Je regressiesuite is 3 uur lang. Het team wil het inkorten naar 1 uur om sneller inzet te deblokkeren. Wat is je plan?'

Scenario 2: 'Een kritieke productiebug werd gemist door je testsuite. Het is een raceconditie die 1 op 100 keer gebeurt. Loop me door je onderzoek.'

Scenario 3: 'Een functie lanceert in 2 weken. Testen is niet klaar. Verzenden zonder volledige dekking zal ons blootstellen aan gegevensverliesrisico. Wat stel je voor?'

Geen van deze heeft juiste antwoorden. Je luistert naar:

• Stellen zij helderstellingsvragen (teamgrootte, gebruikerseffect, begroting)?
• Kunnen zij afwegingen artikuleren zonder terughoudendheid?
• Denken zij als ingenieurs (risico, ROI, onderhoud) of zomaar als testers (dekking)?
• Zijn zij eerlijk over beperkingen?

Tijd: 20 minuten voor vragen, 10 minuten voor hun redenering, 30 minuten voor vervolgvragen en hun vragen voor jou.

Deel 4 (optioneel): Codebeoordeling oefening (30–45 minuten)

Als je QA-rol testcode beoordeling omvat, voeg dit toe.

Zorg voor een testsuite met 3–5 problemen: een broos selector, ontbrekende foutafhandeling, een over-beweerdde test, een opstelling/teardown raceconditie. Vraag hen problemen te identificeren en fixes voor te stellen.

Wat je beoordeelt:

• Kunnen zij code lezen en kritiseren?
• Begrijpen zij foutmodi?
• Zijn hun suggesties praktisch of theoretisch?

Dit is alleen nodig als je team werkelijk testcode beoordeelt. Velen doen dat niet.

Totale investering in tijd

• Deel 1 (geschreven): 45 min kandidaattijd, 10–15 min beoordeling
• Deel 2 (take-home): 2–3 uur kandidaattijd, 15–20 min beoordeling
• Deel 3 (live interview): 1 uur kandidaattijd, 30 min interview, 10 min aantekeningen
• Deel 4 (optioneel): 30–45 min kandidaattijd, 10 min beoordeling

Totaal: 4–5 uur kandidaattijd, 1,5–2 uur recruiter/interviewer-tijd per kandidaat. Dat is redelijk voor een senior werving.

Screening voor deze beoordeling

Stuur de take-home niet naar iedereen. Gebruik deel 1 (het geschreven testcasusontwerp) als screener.

Als zij in 45 minuten geen coherente testcasus kunnen ontwerpen, zullen zij geen solide automatiseringscode schrijven. Spaar de 3-uur take-home voor kandidaten die de geschreven ronde halen.

Ruwe slaagpercentage: Streef naar 40–60% van geschreven inzendingen die naar take-home gaan. Als het veel hoger is, je rubric is te soepel. Als het lager is, je spec is misschien onduidelijk.

Beoordelingskalibratie

Voordat je aanneemt, kalibreer je team op wat 'goed' eruit ziet.

Voer de beoordeling uit op 2–3 bekende goede werving van je team. Hoe zien hun testcasus eruit? Wat is hun codecwaliteit? Gebruik dat als referentiestandaard.

Voer dan 2–3 bekende slechte werving uit (mensen die niet werkten). Wat was zwak aan hun inzendingen? Dat negatieve gebied telt ook.

Je probeert niet perfect objectief te zijn. Je probeert consistent te zijn.

Wanneer onderdelen over te slaan

Werving voor een handmatige QA-rol (verkenning, niet automatisering): Sla deel 2 en deel 4 over. Focus op deel 1 (testdenken) en deel 3 (oordeel).

Werving een mid-level ingenieur wiens portfolio geverifieerd is: Je kunt deel 1 (testontwerp) overslaan en direct naar deel 2 (code) en deel 3 (interview) gaan. Maar alleen als je hun werkelijke code al hebt gezien.

Werving op schaal, vroeg stadium: Begin met zojuist deel 1 + deel 3 (sla de take-home over). Het is sneller. Zodra je proces stabiel is, voeg deel 2 toe voor slotrondes.

Waarom deze structuur beter is dan alternatieven

Beter dan leetcode-achtige problemen: Die testen codeersnelheid onder druk, niet testdenken of architectuur.

Beter dan enkel live coderingsinterview: Je kunt iemands vermogen om tests te ontwerpen of code in een 60-minuten live sessie te onderhouden niet beoordelen.

Beter dan zojuist portfoliobeoordeling: Portfolio's zijn gekureerd. Een beoordeling laat je hun huidige vaardigheid zien, niet hun beste werk van drie jaar geleden.

De structuur werkt omdat zij signaal scheidt. Testontwerp verschilt van codecwaliteit verschilt van oordeel. Je hebt alle drie nodig.

Tegenbeschouwing: Misschien huur je verkeerd

Sommige teams stellen dat je sterke ingenieurs moet aannemen die testen kunnen oppikken, niet specialisten die alleen testen kennen.

Dat klopt als je ingenieurs sterk genoeg zijn. Maar sterke ingenieurs ingehuurd om 'ook QA te doen' doen dat vaak niet. QA wordt een taak die zij verafschuwen. Je eindigt met niet-onderhouden tests en uitgebrande ingenieurs.

Huur mensen die deze discipline kozen. De beoordeling helpt je hen te vinden.