Нужно ли делать ревью тесткейсов
Что проверяют
Считаете ли вы тесткейс таким же рабочим артефактом, как код, и умеете ли организовать ревью так, чтобы оно не превратилось в ритуал. Ответ «да, это полезно» без процесса и критериев не засчитывается.
Как отвечать
Начните с того, что именно ловит ревью, иначе это общие слова. Оно находит расхождение с требованием, когда проверяется не то; пропущенные негативные и граничные случаи; неоднозначные шаги вроде «проверить, что всё работает», по которым второй инженер не воспроизведёт сценарий; дублирование с существующим набором; неверные предусловия и тестовые данные.
Дальше опишите формат, соразмерный цене ошибки. Новые кейсы на критичной функциональности смотрят разработчик фичи и аналитик, они быстрее всех заметят неверное ожидание. Мелкие правки идут в общем потоке, без отдельной церемонии. Кейсы хранятся в системе управления тестами или в репозитории рядом с кодом, ревью асинхронное, комментариями, и у него есть заранее известные критерии: есть ссылка на требование, сформулирован ожидаемый результат, кейс не зависит от предыдущих, понятно, ручной он или кандидат в автотесты.
Сильное дополнение: ревьюить стоит не только новые кейсы. Набор растёт, часть сценариев годами не находит дефектов и просто съедает время регресса, поэтому периодический пересмотр и выбраковка так же полезны, как проверка новых.
Где спотыкаются
Превращают ревью в общее совещание по всему набору. Час времени команды на десяток кейсов никто не выдерживает дважды, и практика тихо отмирает, а вывод делают такой, что ревью не работает.
Второе: обсуждают формулировки и оформление вместо покрытия. Причёсанный кейс, проверяющий не то требование, вреднее неряшливого, но верного.
Третье: не доводят до конца. Комментарии оставлены, кейсы не поправлены, решения нигде не зафиксированы, и через месяц те же замечания всплывают заново.