QA-beoordelingsresultaten interpreteren: Testgegevens lezen als een ingenieur

De metrieken-val

Wanneer u een QA-beoordeling uitvoert, krijgt u gegevens. Geschreven regels code. Testgevallen per uur. Aantal asserties. Dekkingspercentage. Valse-positiefrequentie. Uw instinct is om voor deze metrieken te optimaliseren.

Dat is een val.

Metrieken zijn outputs, geen signalen. Een kandidaat die in 90 minuten tests met hoge dekking schrijft, kan goed zijn in sneltesten. Een kandidaat die in 2,5 uur 3 solide tests schrijft, kan beter zijn in het bouwen van onderhoudbare code. Ruwe metrieken vertellen u niet welke.

U moet het patroon achter de metrieken lezen.

Wat u in testcaseontwerp moet meten

Als u een geschreven testcaseverzending beoordeelt, tel niet alleen cases. Beoordeel op deze criteria:

1. Dekkingsdiepte (niet breedte)

Een kandidaat die 5 testgevallen schrijft, elk met 3–4 goed beredeneerde stappen en duidelijke asserties, is sterker dan iemand die 20 vage cases schrijft.

Zoek naar:

• Testen zij happy path, foutengevallen, grensgevallen en toestandsovergangen?
• Richten zij zich op gedrag of implementatiedetails?
• Erkennen zij beperkingen ("ervan uitgaande dat de database 100k gebruikers heeft, testen we met 50k")?

Rood vlaggetje: "Test of de knop bestaat." Dat is geen testcase. Het is een stap in een test.

Goed signaal: "Test dat bulkimport bestandsindeling valideert voordat verwerking plaatsvindt. Geef een CSV met ongeldige headers en controleer of het foutbericht de gebruiker helpt dit op te lossen."

2. Oordeel in prioritering

Markeren zij tests als kritiek, hoog, laag? Onderscheiden zij tussen "dingen die kunnen breken" en "dingen die we willen verifiëren"?

Een kandidaat die 12 cases schrijft, markeert 3–4 als kritiek en legt uit waarom, toont oordeel. Een kandidaat met 12 gelijke-prioriteit-cases overschat belang of denkt er niet over na.

Waar u op moet letten: "Deze test is hoge prioriteit omdat deze betaalbewerkingen raakt." of "Dit is lage prioriteit omdat het een cosmetische validatie is."

3. Omgevingsbewustzijn

Vermelden zij setup? Vragen zij naar gegevens? Overwegen zij voorwaarden?

Zwak: "Test de exportfunctie."

Sterk: "Ervan uitgaande dat de gebruiker 500 records te exporteren heeft, controleer of de CSV alle rijen met correcte veldtoewijzing bevat. Opmerking: We hebben productieachtige gegevens of een seedscript nodig voor dit."

Wat u in automatiseringscode moet meten

Wanneer u code ontvangt, kijk niet alleen naar slagen of mislukken. Voer het uit, lees het en beoordeel op:

1. Selector-robuustheid

Hoe goed houden hun selectors het vol wanneer de UI verandert?

Fragiele selector:

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

Dit breekt bij elke layoutwijziging. Ze zijn nieuw voor automatisering of nemen snelkoppelingen.

Robuuste selector:

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

Dit test toegankelijkheid en blijft stabiel door refactors heen.

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

2. Wachtstrategie

Gebruiken zij expliciete waits, impliciete waits of (ergste scenario) niets?

Geen waits:

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

Impliciete waits (OK, niet ideaal):

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 krijgen zij flaky tests in productie.

Score: Geen waits = -3. Alleen impliciete = -1. Expliciete = 0.

3. Assertiekwaliteit

Testen zij gedrag of alleen DOM?

Zwakke asserties:

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

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

Sterke asserties:

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: Asserties die echt gedrag testen = +2. Asserties die alleen UI testen = 0. Ontbrekende asserties = -2.

4. Codestructuur en onderhoudbaarheid

Is de code DRY? Gebruiken zij page objects, fixtures of helperfuncties?

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 more lines for a single 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 onderhoudbaarder. Als login verandert, verhelpt u één plaats, niet drie.

Score: Aanzienlijke herhaling of magische getallen = -2. Redelijke structuur = 0. Sterke DRY met helpers = +1.

5. Dekking versus over-assertie

Hebben zij de juiste scope getest of alles?

Een test die 15 dingen controleert is fragiel. Het mislukt als iets verandert, waardoor debuggen moeilijk wordt. Een test die 2–3 belangrijke gedragingen controleert is gericht.

Tel asserties per test. Als het gemiddelde >4 is, over-testen zij. Als <1, testen zij niet genoeg.

Wat u in live-interviews moet meten

Dit is moeilijker om te kwantificeren, maar luister naar deze punten:

1. Helderheid van denken

Wanneer u vraagt "Uw regressiesuite is 3 uur, maak het 1 uur," springen zij naar oplossingen of stellen zij eerst vragen?

Slecht: "Voer minder tests uit."

Goed: "Hoe vaak implementeren we? Wat is de traagste test? Wat zijn onze meest kritieke functies?" Zij vernauwen het probleem voordat zij oplossingen voorstellen.

Score: Stellen zij 2–3 verhelderingsvragen voordat zij oplossingen voorstellen? Zo ja, +2 op oordeel.

2. Formulering van trade-offs

Kunnen zij uitleggen wat wordt opgeofferd?

Slecht: "We slaan de langzamere tests gewoon over."

Goed: "Als we ons concentreren op de kritieke gebruikersreizen - inloggen, kopen, exporteren - verkorten we de tijd van 3 uur naar 45 minuten. We offeren dekking op randgevallen en interne tools op. Het risico is dat we zeldzame bugs missen. Acceptabel als we monitoring en een snelle hotfixprocedure hebben."

De tweede toont aan 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 praktijkervaring

Verwijzen zij naar echte situaties of theoretische kennis?

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

Uit praktijkervaring: "Bij mijn vorige bedrijf hadden we 50 UI-tests die 4 uur duurden. We beperkten deze tot 15 kritieke tests - 20 minuten - en incidenten stegen niet omdat onze stagingomgeving goed was. Dus zou ik je adviseren hier in te investeren."

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

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

Wat u moet negeren

• Geschreven regels code: Meer code ≠ beter ingenieur. Beknopte code die werkt is sterker.
• Snelheid van uitvoering: Een langzame test die betrouwbaar is, is beter dan een snelle test die flaky is.
• Geavanceerde patronen: Als zij een geavanceerd designpatroon gebruiken maar het is niet nodig, dat is over-engineering, niet vaardigheid.
• Taalkeuze: Het maakt niet uit of zij Python of JavaScript voor testutilities gebruiken. Het gaat om leesbaarheid.

Alles samenbrengen: een scoringskader

Maak een eenvoudige rubric:

Beoordeel elke kandidaat op elke categorie. Een 3 over alle categorieën is een sterke werknemer. Een mix van 2en en 3en is prima (iedereen heeft zwaktes). Een 1 ergens is een rood vlaggetje.

Tel uw scores op. Obsedeer niet over het getal. Gebruik het om kandidaten consistent te vergelijken.

Het patroon waar u naar zoekt

Het beste QA-beoordelingsresultaat ziet er als volgt uit:

• Sterk testcaseontwerp (helder denken)
• Redelijke codekwaliteit (praktische ervaring)
• Goed oordeel in het interview (besluitvormingsvermogen)
• Één ding waarin zij uitzonderlijk goed zijn (misschien selectors, misschien frameworkkennis, misschien procesdenken)

Die persoon zal leren, groeien en testsuites jarenlang onderhouden. Dat is de sterke werknemer die u zoekt.