Были ли у вас критерии приемки требований и как они соотносятся с реальностью
Что проверяют
Работали ли вы с критериями приёмки на практике и готовы ли честно говорить о разрыве между написанным и сделанным. Следом обычно просят показать пример критерия и рассказать случай, когда фича прошла все критерии, а пользователям не подошла.
Как отвечать
Опирайтесь на свой проект, с конкретикой. Сначала коротко про форму:
- Given/When/Then: сценарный формат из BDD, легко превращается в автотест. «Дано: в корзине товары на 2900 ₽, порог бесплатной доставки 3000 ₽. Когда: пользователь добавляет товар за 200 ₽. Тогда: доставка становится бесплатной»;
- чек-лист правил: список проверяемых утверждений, подходит для валидаций и отчётов;
- отличие от Definition of Done: DoD общий для всех задач (код-ревью, тесты, документация), а критерии приёмки свои у каждой истории.
Хороший критерий проверяется однозначно: «страница открывается быстро» им не является, «p95 загрузки меньше 2 секунд» является.
Потом про реальность, это главная часть вопроса. Типичные расхождения, которые стоит узнать в своём опыте:
- покрыт только счастливый путь: ошибки, пустые состояния и права доступа всплыли на тестировании;
- забыты нефункциональные требования: производительность, объём данных, логирование;
- бизнес поменял решение: критерии устарели, а их не обновили.
Расскажите, что вы изменили в процессе: обсуждение критериев втроём с разработчиком и тестировщиком до начала работы, примеры на реальных данных, пересмотр при изменении требований. Примеры и цифры нужны свои. Если критериев в команде не было или их писали формально, так и скажите и объясните, что сделали бы иначе.
Где спотыкаются
Рассказывают идеальную историю: «критерии помогли сдать в срок, клиент доволен». Вопрос прямо просит про расхождение с реальностью, и отсутствие проблем выглядит как отсутствие опыта.
Пишут критерии про интерфейс, а не про поведение: «синяя кнопка справа» вместо правила, которое нужно проверить.
Путают критерии приёмки с DoD или подставляют SMART, который придуман для постановки целей, а не для проверки функциональности.