Как организован процесс ревью тестов

Что проверяют

Есть ли у вас реальный процесс, а не формальное «посмотрел, апрув»: что вы проверяете в тестах, кто участвует и как ревью встроено в поток задач. Следом часто спрашивают, как вы разрешаете спор с автором и что делаете с нестабильными автотестами.

Как отвечать

Вопрос про ваш опыт, поэтому опирайтесь на свою команду и свои цифры: сколько тестов проходило ревью, сколько оно занимало. Каркас удобно разделить на две части.

Ревью тест-кейсов в TMS (TestIT, Allure TestOps, TestRail, Zephyr или Xray в Jira):

• статусы: кейс создаётся черновиком, уходит на ревью и только после одобрения становится актуальным и попадает в прогоны;
• покрытие: кейсы привязаны к требованиям, есть негативные сценарии и граничные значения, а не только позитивный путь;
• качество кейса: одна проверка на кейс, понятные предусловия и тестовые данные, однозначный ожидаемый результат, который другой человек проверит без автора;
• кто смотрит: второй QA, по спорным местам аналитик.

Ревью автотестов идёт как обычное код-ревью в merge request, ревьюеров назначает CODEOWNERS:

• стабильность: локаторы через data-testid, никаких sleep, явные ожидания. Новый тест прогоняют несколько раз, в Playwright для этого есть --repeat-each;
• независимость: тест сам создаёт и убирает свои данные и не зависит от порядка запуска;
• проверки: осмысленные ассерты с понятным сообщением, а не единственная проверка статуса ответа;
• зелёный CI: пока пайплайн не прошёл, ревью не начинают.

Если отдельного процесса у вас не было, так и скажите и расскажите, как бы вы его ввели: с чек-листа и договорённости о сроке ревью.

Где спотыкаются

Проверяют оформление и пропускают содержание. Кейс аккуратно заполнен, но негативных сценариев в наборе нет.

Не ставят срок на ревью. Тесты неделю лежат в очереди, и команда начинает обходить процесс.

Одобряют автотест, не запустив его. Нестабильный тест уходит в общий прогон, и через месяц к его падениям все привыкают.