Критерии приёмки: от требования к проверке, «Дано/Когда/Тогда» и когда он не нужен

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

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

От требования к проверке

Хороший способ написать критерий — представить, что проверять будет человек, который не читал ничего, кроме этого критерия. Что ему подготовить, что сделать и на что посмотреть?

Требование
  Покупатель может вернуть товар в течение 14 дней после доставки.

Пересказ, а не критерий
  Возврат доступен 14 дней.

Критерии
  1. Заказ доставлен 14 дней назад → кнопка «Вернуть товар» доступна
  2. Заказ доставлен 15 дней назад → кнопки нет, в заказе указан срок,
     до которого был возможен возврат
  3. Заказ ещё не доставлен → кнопки нет
  4. Отсчёт идёт от даты доставки в часовом поясе покупателя

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

Границы и отрицательные случаи

Большинство споров на приёмке — о том, чего в критериях нет. Хорошие критерии почти всегда содержат три вида строк:

• основной случай — то, ради чего задача делается;
• границу — последнее значение, при котором ещё работает, и первое, при котором уже нет (14 и 15 дней);
• отрицательный случай — когда функция не должна срабатывать и что тогда видит пользователь.

Если в списке только строки первого вида, это описание удачного пути. Остальное решит разработчик, а тестировщик проверит по своему представлению. Где искать недостающие случаи — в разборе сценариев и исключений: каждое исключение сценария становится как минимум одним критерием.

Given/When/Then — и когда он не нужен

Формат «Дано / Когда / Тогда» хорош тем, что заставляет назвать исходное состояние. Именно его в критериях обычно и пропускают: «кнопка доступна» — при каком заказе, у какого пользователя?

Дано    заказ доставлен 15 дней назад
Когда   покупатель открывает заказ
Тогда   кнопки «Вернуть товар» нет
  и     видна строка «Возврат был возможен до 03.10»

Но формат — не цель. Он неудобен в трёх случаях, и там лучше другие формы:

Таблица примеров для расчёта выглядит так — и каждую строку можно проверить, не задав автору ни одного вопроса:

Сумма возврата
  цена   скидка          возвращено ранее   к возврату
  1000   нет             0                  1000
  1000   10 % на заказ   0                  900
  1000   комплект BR-12  0                  по правилу BR-12
  1000   нет             400                600

Критерии, тест-кейсы и Definition of Done

Три вещи, которые часто смешивают:

• Критерии приёмки — что должно быть верно про эту задачу. Пишет аналитик, согласует владелец продукта.
• Тест-кейсы — как именно это проверить: шаги, данные, окружение. Пишет тестировщик из критериев.
• Definition of Done — общие условия для любой задачи: код проверен, тесты прошли, документация обновлена.

Если критерии содержат шаги («открыть страницу, нажать кнопку, ввести…»), это тест-кейс, написанный аналитиком, и он устареет с первым изменением интерфейса. Если в критериях «покрыто тестами» — это строка Definition of Done, а не этой задачи.

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

Сколько критериев достаточно

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

Признак, что критерии не работают: на приёмке тестировщик спрашивает аналитика, «а как должно быть», — и аналитик отвечает не цитатой, а по памяти.

Проверка за десять минут

Возьмите критерии задачи, которая скоро пойдёт в тестирование. Для каждого ответьте: какое исходное состояние нужно, что сделать и что именно увидеть. Где ответа нет — критерий надо дописать. Затем посчитайте строки-границы и отрицательные случаи. Если их ноль — дописать тоже.

Что дальше

У любого критерия есть часть «Дано» — исходное состояние. Заказ, доставленный 15 дней назад, на тестовом стенде сам не появится. Кто и как готовит такие данные — и почему с ними всё работает на стенде и ломается на проде, — в следующем разборе.