Интерпретация результатов оценки QA: чтение данных тестирования как инженер

Ловушка метрик

Когда вы запускаете оценку QA, вы получаете данные. Строк кода написано. Тестовые случаи в час. Количество assertions. Процент покрытия. False positive rate. Ваш инстинкт это оптимизировать для этих метрик.

Это ловушка.

Метрики это outputs, не signals. Кандидат который пишет high-coverage тесты в 90 минут может быть хороший в speed-testing. Кандидат который пишет 3 solids теста в 2.5 часа может быть лучший в построении maintainable кода. Сырые метрики не говорят вам какой.

Вам нужно читать паттерн за метриками.

Что измерять в design тестовых случаев

Если вы оцениваете письменный тестовый случай submission, не просто считайте cases. Оцените на это:

1. Глубина покрытия (не ширина)

Кандидат который пишет 5 тестовых случаев, каждый с 3–4 well-reasoned шагов и чёткие assertions, сильнее чем тот кто пишет 20 расплывчатых cases.

Ищите:

• Тестируют ли они happy path, error case, boundary case и state transitions?
• Они фокусированы на behaviour или implementation детали?
• Они признают constraints («предполагая DB имеет 100k пользователей, мы тестируем с 50k»)?

Красный флаг: «Тест что кнопка существует.» Это не тестовый case. Это шаг в тесте.

Хороший сигнал: «Тест что bulk import валидирует file format перед обработкой. Предоставить CSV с невалидными headers и проверить error message guides пользователя чтобы исправить это.»

2. Суждение в приоритизации

Они маркируют тесты как critical, high, low? Они различают между «вещи которые могут break» и «вещи которые мы хотим верифицировать»?

Кандидат который пишет 12 cases, маркирует 3–4 как critical и объясняет почему showing суждение. Кандидат с 12 equal-priority cases либо оценивает неправильно важность или не думает об этом.

Что ищите: «Этот тест high priority потому что он touches payment processing.» или «Это low priority потому что это cosmetic валидация.»

3. Environmental awareness

Они mention setup? Они спрашивают об данных? Они consider prerequisites?

Слабый: «Тест export функцию.»

Сильный: «Предполагая пользователь имеет 500 records экспортировать, verify CSV содержит все rows с correct field mapping. Заметка: нам будут нужны production-like данные или seed скрипт для этого.»

Что измерять в automation кода

Когда вы получаете код, не просто смотрите pass/fail. Запустите это, читайте это и оцените на:

1. Robustness selector

Как хорошо их selectors выдерживать когда UI изменяется?

Brittle selector:

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

Это breaks на любом layout изменении. Они либо новичок в automation либо режут углы.

Robust selector:

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

Это тестирует accessibility и stays стабильный через refactors.

Оценка: могут ли их selectors выдержать minor UI изменения? Если нет, это -2 на 10-point шкалу.

2. Wait strategy

Они используют explicit waits, implicit waits или (худший) ничего?

No waits:

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

Implicit waits (OK, не отлично):

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

Explicit waits (лучший):

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

Если они используют explicit waits, они понимают async. Если нет, они будут иметь flaky тесты в production.

Оценка: No waits = -3. Implicit only = -1. Explicit = 0.

3. Assertion quality

Они assert behaviour или просто DOM?

Слабые assertions:

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

Это тестирует что message появилось, не что operation succeeded.

Сильные assertions:

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

Это тестирует обе message И underlying state.

Оценка: Assertions что тест real behaviour = +2. Assertions что тест только UI = 0. Missing assertions = -2.

4. Code structure и maintainability

Это DRY код? Они используют page objects, fixtures или helper функции?

No structure:

test("import csv", async () => {
  await page.goto(...);
  await page.fill('#email', '[email protected]');
  await page.fill('#password', 'password');
  await page.click('#login');
  // ... 40 больше строк для один test
});

Structured:

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');
});

Вторая намного более maintainable. Если login изменяется, вы исправляете одно место, не три.

Оценка: Significant дублирование или magic числа = -2. Reasonable structure = 0. Сильный DRY с helpers = +1.

5. Coverage vs. over-assertion

Они тестировали right scope или тестировали everything?

Тест что asserts 15 вещи хрупкий. Это fails если любой один thing изменяется, делая это сложный debug. Тест что asserts 2–3 ключевые behaviours focused.

Считайте assertions за тест. Если average больше 4, они над-asserting. Если <1, они не достаточно тестируют.

Что измерять в live интервью

Это harder чтобы квантифицировать, но слушайте за это:

1. Clarity мышления

Когда вы спрашиваете «ваш regression suite это 3 часа, сокращайте до 1 часа,» они jump к solutions или спрашивают first?

Плохой: «Запустите fewer тестов.»

Хороший: «Как часто мы развёртываем? Какой slowest тест? Какие наши most-critical функции?» Они сужают проблему перед предложением fixes.

Оценка: Они спрашивают 2–3 уточняющих вопросов перед предложением решений? Если да, +2 на суждение.

2. Trade-off articulation

Они могут объяснить что sacrificed?

Плохой: «Мы просто пропустим slower тесты.»

Хороший: «Если мы фокусируем на critical user journeys—login, purchase, export—мы режим время от 3 часов до 45 минут. Мы sacrifice покрытие на edge cases и internal tools. Риск что мы miss редкие bugs. Приемлемо если мы имеем monitoring и quick hotfix процесс.»

Второй shows они понимают cost всех choice.

Оценка: Они могут articulate что could break от их trade-off? +3 на суждение.

3. Evidence опыта

Они reference реальные ситуации или theoretical знание?

Theoretical: «В идеальном мире, мы бы имели comprehensive тест покрытие.»

От experience: «На моя last компания, мы имели 50 UI тестов что take 4 часа. Мы режим их до 15 critical тестов—20 минут—и incidents не увеличивались потому что наш staging environment был хороший. Поэтому я бы suggest инвестировать в это здесь.»

Реальный опыт more значим чем theory. Не потому что theory плохой, но потому что это shows что worked в practice.

Оценка: Они reference реальную ситуацию от их background? +2.

Что игнорировать

• Строк кода написано: больше код ≠ лучший инженер. Concise код что работает сильнее.
• Speed выполнения: медленный тест что reliable лучше чем fast тест что flaky.
• Fancy паттерны: если они используют sophisticated design паттерн, но это не needed, это over-engineering, не skill.
• Language preference: это не имеет значения если они используют Python или JavaScript для test утилиты. Что имеет значение это readability.

Собирание это: Scoring фреймворк

Создайте simple рубрику:

Оцените каждый кандидат на каждый category. 3 по всем категориям это сильный найм. Микс 2s и 3s это нормально (все имеют слабости). 1 where-то это красный флаг.

Итого ваши оценки. Не obsess над числом. Используйте это чтобы compare кандидатов consistently.

Паттерн вы ищете

Лучший результат оценки QA выглядит как это:

• Сильный design тестовых case (чёткое мышление)
• Decent качество кода (hands-on опыт)
• Хороший суждение на интервью (decision-making способность)
• Одна вещь они exceptional на (может быть selectors, может быть framework знание, может быть process мышление)

Этот человек будет учиться, расти и maintain тестовые suite на годы. Это найм.