Как оформить критерии приёмки в техническом задании на разработку

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

Что должно быть зафиксировано до написания критериев

Сначала определите объект приёмки. Это может быть отдельная функция, пользовательский сценарий, API, интеграция, отчёт, интерфейс, миграция данных или весь релиз. Ошибка — писать один общий критерий вроде «система работает согласно ТЗ»: такой текст не определяет способ проверки и не позволяет локализовать несоответствие.

Для каждого объекта приёмки желательно иметь:

• идентификатор или ссылку на требование;
• описание требуемого поведения;
• условия, необходимые для проверки;
• тестовые данные или правила их подготовки;
• ожидаемый результат;
• допустимые отклонения, если они предусмотрены;
• способ фиксации результата проверки.

Если часть этих сведений определяется другими разделами ТЗ, критерий может ссылаться на них. При этом ссылка должна вести к конкретному разделу, требованию или идентификатору, а не к документу в целом.

Шаг 1. Свяжите критерий с конкретным требованием

Критерий приёмки не должен существовать отдельно от требования. Удобно присваивать требованиям идентификаторы, например FR-01 для функциональных требований, NFR-01 для нефункциональных или использовать единую сквозную нумерацию.

Например, исходное требование:

FR-12. Авторизованный пользователь может изменить адрес электронной почты в профиле.

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

Шаг 2. Укажите исходные условия

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

Плохая формулировка:

«Пользователь может изменить email».

Проверяемая формулировка:

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

Условия следует включать только тогда, когда они влияют на результат. Не стоит превращать каждый критерий в полное описание инфраструктуры тестирования.

Шаг 3. Опишите одно проверяемое действие

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

Разделите такой сценарий, например, на следующие критерии:

• заказ создаётся после отправки корректно заполненной формы;
• после подтверждённой оплаты заказ получает предусмотренный требованиями статус;
• после наступления заданного события формируется уведомление;
• созданный заказ доступен пользователю с соответствующими правами в административном интерфейсе.

Так при отказе одного компонента будет понятно, какой именно критерий не выполнен.

Шаг 4. Зафиксируйте наблюдаемый результат

Ожидаемый результат должен быть доступен для проверки. Формулировки «корректно», «удобно», «быстро», «качественно» или «нормально отображается» сами по себе непроверяемы.

Вместо:

«После сохранения система корректно обновляет профиль»

лучше написать:

«После сохранения допустимого нового адреса электронной почты значение в поле профиля заменяется на введённое значение и сохраняется после повторного открытия страницы профиля».

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

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

Шаг 5. Замените оценочные слова измеримыми условиями

Если требование относится к производительности, объёму, точности или ограничениям, необходимо заранее определить величину и условия её измерения. Например, фраза «страница должна загружаться быстро» не задаёт границу между принятым и непринятым результатом.

Структура измеримого критерия может выглядеть так:

«При условиях X операция Y должна завершаться не более чем за Z, измерение выполняется способом M».

Значения X, Z и M должны исходить из требований проекта. Не следует назначать их произвольно только ради формальной измеримости. Если заказчик ещё не определил допустимое время или нагрузку, это нужно отметить как незакрытое требование и согласовать до приёмки.

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

Шаг 6. Опишите негативные сценарии, влияющие на приёмку

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

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

1. Допустимое значение сохраняется.
2. Значение, не соответствующее установленным правилам формата, не сохраняется, а пользователь получает предусмотренное сообщение об ошибке.
3. Пользователь без требуемой авторизации не получает доступ к операции изменения данных.

Не следует придумывать текст сообщений, HTTP-коды или механизм проверки формата, если они не заданы требованиями. Критерии должны конкретизировать уже согласованное поведение, а не незаметно расширять объём разработки.

Шаг 7. Уберите неоднозначные зависимости

Формулировка должна позволять подготовить проверку без догадок. Обратите внимание на слова «при необходимости», «обычно», «желательно», «по возможности», «и так далее», «соответствующий» и «правильный». Если из текста нельзя определить конкретное условие, такое слово следует заменить ссылкой на правило или явным описанием.

Например:

«Администратор при необходимости получает уведомление»

не определяет момент отправки. Если правило существует, его нужно назвать:

«При переходе заявки в статус, указанный в требовании FR-24, пользователю с ролью администратора формируется уведомление».

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

Шаг 8. Выберите единый формат записи

Для небольшого ТЗ достаточно нумерованного списка. Для проекта с десятками требований удобнее таблица, в которой сохраняется трассировка между требованиями и проверками.

Пример заполнения без привязки к конкретному проекту:

Шаг 9. Отделите критерии приёмки от процедуры приёмки

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

Эти сведения можно разместить в отдельном разделе ТЗ или приложении. Например, там могут быть определены:

• состав передаваемой версии;
• требования к тестовой среде и данным;
• ответственные стороны;
• форма протокола проверки;
• правило фиксации дефектов и повторной проверки;
• порядок оформления итогового результата приёмки.

Такое разделение не даёт смешивать функциональное требование с организационными условиями договора или проекта.

Шаг 10. Проведите проверку критериев до утверждения ТЗ

Полезный способ редакционной проверки — попытаться мысленно выполнить каждый критерий буквально по документу. Если для проверки приходится задавать дополнительный вопрос автору ТЗ, вероятно, в критерии или связанном требовании отсутствует существенное условие.

Для каждого критерия последовательно проверьте:

1. Понятно ли, к какому требованию он относится?
2. Определено ли исходное состояние, если оно влияет на результат?
3. Понятно ли выполняемое действие или событие?
4. Есть ли наблюдаемый ожидаемый результат?
5. Можно ли однозначно определить соответствие?
6. Указаны ли числовые пределы там, где без них результат остаётся субъективным?
7. Не появилось ли внутри критерия новое требование, которого нет в согласованном объёме работ?
8. Не зафиксирована ли внутренняя реализация вместо внешнего результата без необходимости?

Практический шаблон критерия

Для большинства функциональных требований можно использовать следующую конструкцию:

ID критерия: AC-XX.Y

Связанное требование: идентификатор требования.

Предусловия: состояние системы, роль пользователя и необходимые данные.

Действие: одно конкретное действие пользователя или событие системы.

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

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

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

Шаблон не требует заполнять каждое поле формально. Например, для простого интерфейсного поведения отдельное поле ограничений может быть не нужно. Важнее, чтобы совокупность полей исключала существенные догадки при проверке.

Типичные ошибки

• «Функция должна работать корректно». Нет определения требуемого результата.
• «Интерфейс должен быть удобным». Нет проверяемого признака удобства.
• «Ответ должен приходить быстро». Не определён допустимый предел и условия измерения.
• «Все ошибки должны обрабатываться». Не определено, какие ситуации относятся к обязательным сценариям и какое поведение ожидается.
• Один критерий на большой бизнес-процесс. Невозможно однозначно указать место несоответствия.
• Критерий содержит новую функцию. Объём работ расширяется через раздел приёмки вместо изменения требований.
• Критерий задаёт внутреннюю архитектуру. Реализация ограничивается без необходимости, хотя предметом приёмки является результат.

Итоговый чек-лист

• Каждый существенный критерий связан с конкретным требованием.
• Критерий описывает проверяемый результат, а не субъективную оценку.
• Для важных исходных состояний указаны предусловия.
• Одному критерию соответствует одно понятное действие или событие.
• Числовые ограничения указаны только там, где они согласованы требованиями.
• Для существенных ошибочных сценариев определено ожидаемое поведение.
• В тексте нет неопределённых слов, от которых зависит решение о приёмке.
• Критерии не добавляют скрытые функции и необоснованные технические ограничения.
• Организационная процедура приёмки отделена от критериев соответствия.
• По каждому критерию можно получить однозначный результат «соответствует» или «не соответствует» без дополнительных договорённостей.

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