processcareer

Code review глазами QA: что искать когда не разработчик

QA не обязан разбираться в коде на уровне senior-разраба. Но участие в code review — мощный навык. Ты видишь то, что разработчики пропускают: тест-сценарии, граничные случаи, регрессионные риски. Гайд как QA может быть полезен на ревью.

Что ищет QA на ревью (что не ищут разработчики)

1. Untested scenarios

Разраб написал новую функцию обработки строки. Юзер вводит:

  • Пустую строку?
  • Только пробелы?
  • Очень длинную (100k+ символов)?
  • Спецсимволы (emoji, RTL)?
  • Null/undefined?

Если в PR нет тестов на эти кейсы — QA задаёт вопрос: «А что произойдёт если…?». Часто разраб говорит «упадёт», добавляет проверку.

2. Regression risk

Изменили модуль X. Связан ли он с модулем Y? QA знает архитектуру с точки зрения «откуда что приходит». Может указать: «А ты подумал что наш cron-сервис тоже пользуется этим API?»

3. Observable behavior

«Я нажму кнопку — что увижу?» Разработчик думает кодом. QA думает поведением. На UI-ревью:

  • Loading state есть?
  • Error message понятен?
  • Disabled-состояние кнопки во время загрузки?
  • Что после успеха — toast, redirect, ничего?

4. Accessibility

<div onClick={handle}>Submit</div> вместо <button>. QA смотрит — экран-ридер не прочитает, клавиатурная навигация сломана. Указываешь.

5. Logging для триаджа багов

Когда в проде что-то сломается — что ты будешь смотреть? Если в коде нет логов вокруг важной операции — QA подсказывает «добавь log message с параметрами, потом будет проще разбираться».

Что НЕ обязан делать QA

  • Корректность алгоритма: O(n²) vs O(n log n) — это к разработчикам.
  • Архитектура классов / patterns: тоже devs.
  • Безопасность на уровне SQL injection в ORM: спорно — если знаешь, говори, если нет — security review отдельно.
  • Стиль кода: это linter’ы.

Practical tips

✅ Запроси review на каждый PR команды. В большинстве систем (GitHub, Bitbucket) можно подписаться на все PR-events.

✅ Не пиши «add test». Пиши «А что если юзер передаст пустую строку? Я не вижу теста — добавишь?» — конкретно, разраб понимает что делать.

✅ Не блокируй PR если у тебя нет write-доступа к code review process. Оставь комментарий-вопрос, дальше команда решит.

✅ Не делай review всего огромного PR. Если 50 файлов — попроси разбить, или review только critical-paths.

✅ Спрашивай вместо утверждай. «Не уверен — корректно ли это работает в часовом поясе UTC-12?» лучше чем «Тут баг».

Где QA сильно полезен

  • PR на bugfix: проверь — добавили ли регрессионный тест? Если нет — фикс может откатиться через 6 месяцев.
  • PR на новую фичу: review acceptance criteria — все ли покрыты?
  • PR на performance fix: попроси benchmark до и после.
  • PR на security fix: посмотри — все ли similar спotsы пропатчены, или только один?

Когда QA не нужен

  • Cosmetic CSS изменения.
  • Refactor без изменения логики.
  • Зависимостные обновления (Renovate-PR’ы) если нет breaking changes.

Что делать прямо сейчас

✅ Подпишись на PR-нотификации в своей команде.

✅ Возьми один открытый PR — оставь хотя бы один вопрос про test-сценарий.

✅ Через месяц — проанализируй: какие из твоих комментариев привели к улучшению. Это твоя ценность.

Подробнее: Atlassian — Code review best practices, GitHub — Reviewing PRs.