QA-beoordelingsresultaten interpreteren: testgegevens als een ingenieur lezen

De metrieken-val

Wanneer je een QA-beoordeling uitvoert, krijg je gegevens. Coderegels geschreven. Testgevallen per uur. Aantal assertions. Dekking percentage. Onwaar-positiefsnelheid. Je instinct is deze metriek te optimaliseren.

Dat is een val.

Metriek zijn outputs, geen signalen. Een kandidaat die testdekking in 90 minuten schrijft, kan goed zijn in snelheid. Een kandidaat die 3 solide testen in 2,5 uur schrijft, kan beter zijn in onderhoudbare code. Ruwe metriek vertellen je niet welke.

Je moet het patroon achter de metriek lezen.

Wat te meten in testcase-ontwerp

Als je een schriftelijke testcase-inzending beoordeelt, tel niet alleen gevallen. Beoordeel op dit:

1. Dekkingsdiepte (niet breedte)

Een kandidaat die 5 testgevallen schrijft, elk met 3-4 goed beredeneerdestappen en duidelijke assertions, is sterker dan iemand die 20 vage gevallen schrijft.

Kijk naar:

• Testen zij happy path, foutgeval, grenscase en status-overgangen?
• Richten zij zich op gedrag of implementatiedetails?
• Erkennen zij beperkingen ("ervan uitgaande dat DB 100k gebruikers heeft, testen we met 50k")?

Rode vlag: "Test dat de knop bestaat." Dat is geen testcase. Het's een stap in een test.

Goed signaal: "Test dat bulkimport bestandsindeling valideert vóór verwerking. Geef een CSV met ongeldige headers en controleer of het foutbericht de gebruiker begeleidt om deze op te lossen."

2. Oordeel in prioritering

Labelen zij testen als kritiek, hoog, laag? Onderscheiden zij tussen "dingen die kapot kunnen gaan" en "dingen die we willen verifiëren"?

Een kandidaat die 12 gevallen schrijft, 3-4 als kritiek markeert en uitlegt waarom toont oordeel. Een kandidaat met 12 gelijk-prioriteit gevallen over- of onderschat belang of denkt er niet aan.

Waar op te letten: "Deze test is hoge prioriteit omdat deze betalingsverwerking aanraakt." of "Dit is lage prioriteit omdat het cosmetische validatie is."

3. Omgevingsbewustzijn

Noemen zij setup? Vragen zij naar gegevens? Overwegen zij vereisten?

Zwak: "Test de exportfunctie."

Sterk: "Ervan uitgaande dat de gebruiker 500 records heeft om te exporteren, controleer of de CSV alle rijen bevat met correcte veldtoewijzing. Opmerking: We hebben productie-achtige gegevens of een seed-script nodig."

Wat te meten in automatiseringscode

Wanneer je code ontvangt, kijk niet alleen naar pass/fail. Voer uit, lees en beoordeel op:

1. Selectorrobuustheid

Hoe goed houden hun selectors stand als de UI verandert?

Breekbare selector:

driver.findElement(By.cssSelector("body > div > div > div > button")).click();

Dit breekt bij elke lay-outwijziging. Zij zijn nieuw in automatisering of snijden hoeken af.

Robuuste selector:

driver.findElement(By.cssSelector("[aria-label='Import CSV']")).click();

Dit test toegankelijkheid en blijft stabiel door refactors.

Score: Kunnen hun selectors kleine UI-wijzigingen overleven? Zo niet, dan -2 op een 10-puntsschaal.

2. Wacht-strategie

Gebruiken zij expliciete waits, impliciete waits, of (ergstig) geen?

Geen waits:

driver.findElement(By.id("submit")).click();
driver.findElement(By.id("success-message")).getText(); // Race condition

Impliciete waits (OK, niet geweldig):

driver.manage().setTimeouts({implicit: 10000});

Expliciete waits (beste):

WebDriverWait(driver, 10).until(EC.presence_of_element_located((By.id, "success-message")));

Als zij expliciete waits gebruiken, begrijpen zij async. Zo niet, dan hebben zij flaky-testen in productie.

Score: Geen waits = -3. Alleen impliciet = -1. Expliciet = 0.

3. Assertion-kwaliteit

Testen zij gedrag of gewoon DOM?

Zwakke assertions:

assert(screen.getByText("Success"));

Dit test of een bericht verscheen, niet of de bewerking slaagde.

Sterke assertions:

expect(await screen.findByText("5 rows imported successfully")).toBeInTheDocument();
expect(await screen.findByDisplayValue("import_status = completed")).toBeInTheDocument();

Dit test zowel het bericht ALS de onderliggende status.

Score: Assertions die echt gedrag testen = +2. Assertions die alleen UI testen = 0. Ontbrekende assertions = -2.

4. Codestructuur en onderhoudbaarheid

Is de code DRY? Gebruiken zij page objects, fixtures of helper-functies?

Geen structuur:

test("import csv", async () => {
  await page.goto(...);
  await page.fill('#email', '[email protected]');
  await page.fill('#password', 'password');
  await page.click('#login');
  // ... 40 meer regels voor één test
});

Gestructureerd:

const page = new ImportPage();
test("import csv with invalid headers", async () => {
  await page.login();
  await page.uploadCsv('invalid.csv');
  await page.expectError('Invalid CSV format');
});

De tweede is veel beter onderhoudbaar. Als aanmelding verandert, fix je één plaats, niet drie.

Score: Aanzienlijke duplicatie of magiënummers = -2. Redelijke structuur = 0. Sterke DRY met helpers = +1.

5. Dekking vs. over-assertion

Testen zij de juiste scope of alles?

Een test die 15 dingen asserts is fragiel. Het faalt als iets verandert, waardoor debuggen moeilijk wordt. Een test die 2-3 kerngedragingen asserts is gericht.

Tel assertions per test. Als gemiddelde >4, over-asserieren zij. Als <1, testen zij niet genoeg.

Wat te meten in live-interviews

Dit is moeilijker te kwantificeren, maar luister naar dit:

1. Helderheid van denken

Wanneer je "Je regressietest is 3 uur, snij naar 1 uur" vraagt, springen zij naar oplossingen of stellen zij eerst vragen?

Slecht: "Voer minder testen uit."

Goed: "Hoe vaak starten we? Wat is de traagste test? Wat zijn onze meest kritieke functies?" Zij vernauwen het probleem vóór het voorstellen van fixes.

Score: Stellen zij 2-3 verduidelijkingsvragen vóór het voorstellen van oplossingen? Zo ja, +2 op oordeel.

2. Articulatie van trade-offs

Kunnen zij uitleggen wat wordt opgeofferd?

Slecht: "We overslaan gewoon de langzamere testen."

Goed: "Als we ons richten op kritieke gebruikerstrajecten—aanmelden, aankoop, exporteren—snijden we de tijd van 3 uur naar 45 minuten. We offeren dekking op edge cases en interne tools op. Het risico is dat we zeldzame bugs missen. Acceptabel als we monitoring hebben en een snel hotfix-proces."

De tweede toont dat zij de kosten van elke keuze begrijpen.

Score: Kunnen zij articuleren wat kan breken door hun trade-off? +3 op oordeel.

3. Bewijs van ervaring

Verwijzen zij naar echte situaties of theoretische kennis?

Theoretisch: "In een ideale wereld zouden we uitgebreide testdekking hebben."

Uit ervaring: "In mijn vorige bedrijf hadden we 50 UI-testen die 4 uur duurden. We sneden ze terug naar 15 kritieke testen—20 minuten—en incidenten stegen niet omdat onze staging-omgeving goed was. Dus zou ik suggereren dat hier te investeren."

Echte ervaring is waardevoller dan theorie. Niet omdat theorie slecht is, maar omdat het toont wat in de praktijk werkte.

Score: Verwijzen zij naar een echte situatie uit hun achtergrond? +2.

Wat te negeren

• Coderegels geschreven: Meer code ≠ betere ingenieur. Beknopte code die werkt is sterker.
• Snelheid van uitvoering: Een trage test die betrouwbaar is beter dan een snelle test die flaky is.
• Fancy patronen: Als zij een geavanceerd ontwerppatroon gebruiken maar het's niet nodig, dat's over-engineered, geen vaardigheid.
• Taalvoorkeur: Het maakt niet uit of zij Python of JavaScript gebruiken voor test-utilities. Wat telt is leesbaarheid.

Dit alles samenvattend: een beoordelingsraamwerk

Maak een eenvoudige rubrik:

Beoordeel elke kandidaat op elke categorie. Een 3 over alle categorieën is een sterke aanwerving. Een mix van 2s en 3s is fijn (iedereen heeft zwaktes). Een 1 ergens is een rode vlag.

Tel je scores op. Obsesseer niet over het getal. Gebruik het om kandidaten consistent te vergelijken.

Het patroon dat je zoekt

Het beste QA-beoordelingsresultaat ziet er zo uit:

• Sterk testcase-ontwerp (helder denken)
• Redelijke codekwaliteit (praktische ervaring)
• Goed oordeel in interview (besluitvormingsvermogen)
• Één ding waar zij uitzonderlijk in zijn (misschien selectors, misschien frameworkkennis, misschien procesdenken)

Die persoon leert, groeit en onderhoudt testsuites jarenlang. Dat's de aanwerving.