Какие методы ревью требований вы использовали
Что проверяют
Работали ли вы с ревью требований как с процессом или только отправляли документ «на согласование» и ждали, пока все промолчат. Интервьюер хочет услышать, чем методы отличаются по формальности и что конкретно вы искали в требованиях. Следом обычно просят пример: что нашли на ревью и во что обошлось бы, если бы не нашли.
Как отвечать
Постройте ответ от лёгких методов к формальным и к каждому привяжите свой случай:
- вычитка коллегой (peer review): другой аналитик читает спецификацию и оставляет комментарии в Confluence или в пулреквесте, если требования живут в Git. Дёшево, подходит для каждой задачи;
- walkthrough: автор ведёт команду по документу вслух. Цель в общем понимании, а не в поиске всех дефектов, хорошо работает на сложных бизнес-процессах;
- инспекция: формальный метод с ролями (модератор, автор, рецензенты, секретарь), подготовкой по чек-листу и протоколом дефектов. Дорого, оправдано для критичных областей вроде платежей и интеграций;
- ревью по чек-листу: критерии качества из ISO/IEC/IEEE 29148 (однозначность, полнота, непротиворечивость, проверяемость, реализуемость, трассируемость), для пользовательских историй ещё INVEST;
- ревью через тест-дизайн: тестировщик пишет проверки или критерии приёмки до разработки. Если требование нельзя проверить, оно дефектно;
- ревью с разработкой и заказчиком: груминг, «три амиго», показ прототипа, где заказчик видит результат раньше кода.
Дальше расскажите, как фиксировали замечания, кто решал спорные и измеряли ли эффект: сколько дефектов требований поймали на ревью и сколько доехало до тестирования. Цифры берите только свои. Если формальных инспекций у вас не было, так и скажите и объясните, почему на ваших задачах хватало вычитки и груминга.
Где спотыкаются
Перечисляют методы из учебника без единого примера. Вопрос задан в прошедшем времени, от вас ждут опыт.
Сводят ревью к проверке орфографии и оформления. Ценность в поиске неоднозначностей, пропущенных сценариев и противоречий со смежными системами.
Не говорят, кто участвует. Ревью силами одних аналитиков не ловит нереализуемое и непроверяемое, для этого нужны разработчик и тестировщик.