Что такое критерии приёмки? Как писать условия, с которыми согласны все

Критерии приёмки - это условия, которым работа должна отвечать, прежде чем кто-нибудь назовёт её законченной. Их пишут до начала работы, пишет тот, кто её заказывает, и согласовывает с теми, кто будет её делать и проверять.

Их задача - передвинуть спор во времени. Без них вопрос “это готово?” решается после работы и решается тем, кто настаивает громче. С ними он был решён заранее, людьми, которые были спокойны.

Чем они не являются

Не описание функции. “Пользователь может отфильтровать отчёт” - это пересказ. Критерий говорит, что должно быть верно: какие фильтры, что происходит, когда ни один не подошёл, в каком состоянии всё окажется после перезагрузки.

Не дизайн. Критерии описывают результат, а не раскладку. “Выпадающий список справа сверху” решает за того, кто лучше всех способен выбрать решение, и отнимает у него этот выбор.

Не тест-кейсы. Критерий - это условие, а тест-кейс - процедура проверки одного условия. На одном критерии обычно висит несколько тест-кейсов, и пишут их позже, и не обязательно тот же человек.

Два формата, которыми пользуются

Список - более простой из двух, и для большинства задач его достаточно.

Готово, когда:
- Вошедший пользователь видит только свои заказы
- Заказ без позиций всё равно отображается, с суммой 0,00
- Список загружается не дольше двух секунд для аккаунта с 10 000 заказов
- Сортировка по дате сохраняется при переходе между страницами

Дано, когда, тогда - формальнее, и лишняя церемония окупается там, где поведение зависит от состояния.

Дано: клиент с истёкшей картой
Когда он отправляет форму оплаты
Тогда платёж отклоняется
И поля карты сохраняют введённые значения
И сообщение говорит, какое поле нужно исправить

Ценность - в дано. Большинство недопониманий живёт в начальном состоянии - пробный аккаунт, истёкший токен, пустой список - а не в действии, и формат заставляет кого-то это состояние назвать.

Ни один из форматов не лучше. По умолчанию берите список и тянитесь за дано-когда-тогда там, где одно и то же действие должно вести себя по-разному в зависимости от ситуации.

Что отличает хороший критерий от плохого

Проверка простая: могут ли два человека разойтись во мнении, выполнен он или нет.

Слабо

Страница должна загружаться быстро и показывать релевантные результаты

Лучше

Первая страница результатов появляется не дольше чем за две секунды для аккаунта с 10 000 заказов и показывает только заказы этого аккаунта

Четыре привычки дают большую часть слабых:

• Прилагательные вместо порогов. Быстро, интуитивно, надёжно, удобно. Ничего из этого нельзя проверить; обо всём можно спорить.
• Только счастливый путь. Критерии, которые описывают, что происходит, когда всё работает, оставляют каждый сбой на чьё-то усмотрение в четыре часа дня в день релиза.
• Решения. “Добавить окно подтверждения” вместо “пользователь не может удалить счёт без подтверждения”.
• Всё сразу. История с девятнадцатью критериями - это несколько историй, и она две недели будет наполовину сделанной.

Кто их пишет и когда

Черновик пишет тот, кто заказывает работу, и их согласуют до того, как кто-нибудь начнёт. Это та часть, которую команды пропускают, и именно пропуск превращает двухдневную задачу в неделю уточнений.

Это не обязано быть тяжело. Разработчик, который читает черновик и спрашивает “а что должно быть, если заказов у него ещё нет?”, - это и есть весь процесс в работе: сейчас вопрос дешёвый, а после написанного кода дорогой.

Записывайте их там, где живёт работа, а не в сообщении в чате. Критерии, которые существуют только в чьей-то памяти о встрече, порождают ровно тот спор, который должны были предотвратить.

Где они в итоге и оказываются важны

Два места, и ради них всё это и делается.

Приёмка. Тем, кто проводит приёмочное тестирование, нужно то, относительно чего принимать. Без критериев это превращается в опрос мнений о программе, за которую уже заплачено.

Разбор ошибок. Самый утомительный спор в разработке - дефект это или запрос на изменение, и решается он тем, о чём договорились. Дефект - это поведение, которое противоречит критерию; всё остальное - новый запрос, каким бы разумным он ни был. Команды без записанных критериев ведут этот спор раз в релиз, вечно.

Поэтому же в сообщении о дефекте должно быть сказано не только что произошло, но и что ожидалось, - это та же фраза, что и критерий, которому оно противоречит.

Руководство по отчётам об ошибках покрывает остальное, что такому сообщению нужно, а в его шаблоне есть строка для ожидаемого поведения.

Коротко

Условия, записанные до работы, согласованные теми, кто её заказал, и теми, кто будет её делать, достаточно конкретные, чтобы два человека не могли разойтись во мнении, выполнены они или нет. Списка обычно достаточно; дано-когда-тогда - когда исход решает начальное состояние. Покрывайте то, что происходит при сбоях, а не только то, что происходит, когда всё работает.