Проверяемая спецификация поведения — Примеры

Пример 1 — От пожелания к проверяемому требованию

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

Система должна надёжно обрабатывать большие загрузки.
(большие = больше собственного лимита браузера; ненадёжно = обрывается
 в мобильных сетях и приходится начинать заново)

Решение

REQ-UPLOAD-07
Когда пользователь загружает файл больше 100 МБ (триггер, условие),
система должна возобновить загрузку после обрыва сети с последнего
подтверждённого фрагмента, не прося пользователя действовать (отклик).

Критерий приёмки
- Загрузка на 150 МБ, прерванная после 40 МБ, возобновляется с
  фрагмента 40 и завершается без нового выбора файла.
- Загрузка, прерванная дважды, всё равно завершается.
- Загрузка на 90 МБ ниже порога; возобновление не требуется.

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

Пример 2 — Одно требование на предложение, со случаем сбоя

Требование к форме написано одним длинным предложением с тремя «и», и в нём «следует» стоит там, где есть юридическая обязанность. Разбейте его, выберите каждую модальность осознанно и напишите поведение при сбое, а не только счастливый путь.

Система должна проверять форму и отправлять пользователю письмо,
если она неверна, и быть безопасной, и отвечать быстро.

Решение

REQ-FORM-01  Когда пользователь отправляет форму, система должна
             отклонить её в течение 200 мс, если поле email не
             является корректным адресом, и показать «Введите
             корректный адрес электронной почты».
REQ-FORM-02  Когда отправка отклонена, система не должна отправлять
             никакого письма на введённый адрес.
REQ-FORM-03  Система должна хранить отправленные данные зашифрованными
             при хранении алгоритмом AES-256.
REQ-FORM-04  Пока сервис форм недоступен, система может поставить
             отправку в очередь и повторять попытку 15 минут.

Теперь каждое предложение называет одного субъекта действия, одно условие и один отклик, а случай отклонённой отправки записан, а не оставлен разработке. Модальности делают реальную работу: «должна» обозначает обязанности, «может» — необязательную очередь. Частая ошибка — оставить «безопасной» и «быстро» прилагательными: они звучат как требования и никогда не могут не выполниться.