Критерии приёмки в техническом задании нужно формулировать так, чтобы заказчик и исполнитель могли независимо проверить один и тот же результат и получить одинаковый вывод: требование выполнено или не выполнено. Для этого каждый критерий должен описывать объект проверки, исходные условия, действие, ожидаемый результат и способ фиксации результата.
Что считать критерием приёмки
Критерий приёмки — это проверяемое условие, на основании которого принимается отдельная функция, этап работ или весь результат проекта. Он не должен описывать намерение, качество «в целом» или субъективное впечатление.
Плохая формулировка:
Система должна работать быстро, корректно и быть удобной для пользователей.
Такая запись не определяет, что считать быстрой работой, какие действия проверять, какие ошибки допустимы и кто оценивает удобство. На её основании нельзя составить однозначный акт приёмки.
Проверяемая формулировка:
«После отправки формы регистрации пользователь получает сообщение об успешном создании учётной записи. Введённый адрес электронной почты появляется в карточке пользователя в административной панели. При повторной регистрации с тем же адресом система отклоняет запрос и выводит сообщение “Пользователь с таким адресом уже зарегистрирован”».
Шаг 1. Разделите требования и критерии проверки
Не смешивайте описание функции с процедурой её приёмки. В ТЗ удобно использовать два связанных блока:
- Функциональное требование — что должна делать система или что должен содержать результат работ.
- Критерий приёмки — как подтвердить, что требование реализовано.
Пример:
| Элемент | Формулировка |
|---|---|
| Требование | Пользователь может восстановить пароль по адресу электронной почты. |
| Критерий приёмки | При отправке формы с зарегистрированным адресом система показывает подтверждение отправки. На указанный адрес поступает письмо со ссылкой восстановления. После перехода по действующей ссылке пользователь может задать новый пароль и войти с ним. |
Если одному требованию соответствует несколько сценариев, оформляйте их отдельными критериями. Не объединяйте успешный сценарий, ошибки ввода, ограничения доступа и граничные условия в один длинный абзац.
Шаг 2. Используйте единую структуру критерия
Для большинства задач подходит структура «Дано — Когда — Тогда». Она позволяет отделить подготовку проверки от действия и ожидаемого результата.
- Дано — состояние системы, права пользователя, исходные данные и необходимые настройки.
- Когда — конкретное действие проверяющего.
- Тогда — наблюдаемый результат.
Пример:
Дано: пользователь авторизован с ролью «Редактор», а документ находится в статусе «Черновик».
Когда: пользователь нажимает кнопку «Отправить на согласование».
Тогда: статус документа меняется на «На согласовании», редактирование содержимого блокируется, а в журнале событий появляется запись с датой, временем и идентификатором пользователя.
Структуру можно оформить таблицей, нумерованным сценарием или отдельными подпунктами. Главное — применять один формат по всему документу.
Шаг 3. Опишите точные исходные условия
Результат проверки зависит от состояния системы. Поэтому нельзя ограничиваться фразами «открыть страницу» или «ввести данные». Укажите всё, что влияет на поведение:
- роль и права пользователя;
- статус объекта;
- наличие или отсутствие связанных записей;
- тип и формат входных данных;
- обязательные настройки;
- используемую тестовую среду, если она отличается от рабочей;
- предварительно выполненные действия.
Плохой вариант: «При удалении заказа появляется предупреждение».
Уточнённый вариант: «Если пользователь с ролью “Менеджер” открывает заказ в статусе “Новый” и нажимает “Удалить”, система показывает диалог подтверждения с номером заказа и кнопками “Удалить” и “Отмена”».
Если критерий действует только при определённом условии, запишите это условие прямо. Не полагайтесь на подразумеваемый контекст соседних разделов.
Шаг 4. Замените оценочные слова измеримыми условиями
Слова «быстро», «удобно», «качественно», «стабильно», «современно», «понятно», «корректно» и «без ошибок» нельзя использовать как самостоятельные критерии. Они допустимы только вместе с измеримым определением.
| Двусмысленно | Проверяемо |
|---|---|
| Страница загружается быстро | Нужно указать измеряемый показатель, условия замера, допустимое значение и инструмент фиксации. Если эти параметры не согласованы, требование следует пометить как требующее уточнения. |
| Форма понятна пользователю | У каждого обязательного поля есть подпись; при незаполненном обязательном поле отправка блокируется; рядом с полем выводится текст ошибки. |
| Система корректно обрабатывает файл | После загрузки файла допустимого формата создаётся запись с исходным именем, размером и датой загрузки; файл доступен для скачивания из карточки записи. |
| Отчёт формируется без ошибок | При выбранном периоде отчёт содержит заданные столбцы; итоговая строка рассчитывается по явно указанному правилу; при отсутствии данных отображается предусмотренное сообщение. |
Не придумывайте числовые ограничения самостоятельно. Если заказчик не определил допустимое время ответа, размер файла, точность расчёта или число одновременных пользователей, зафиксируйте это как открытый вопрос, а не подставляйте произвольное значение.
Шаг 5. Укажите наблюдаемый результат
Критерий должен описывать то, что можно увидеть, получить из системы или подтвердить документом. Формулировка «данные обрабатываются» недостаточна, потому что не указывает внешний результат.
Используйте наблюдаемые признаки:
- изменился статус объекта;
- появилась запись в интерфейсе;
- создан файл с заданными полями;
- отправлено уведомление;
- доступ разрешён или запрещён;
- отображён конкретный текст ошибки;
- значение сохранено и остаётся после повторного открытия;
- событие зарегистрировано в предусмотренном журнале.
Для каждого результата укажите место проверки. Например, запись может проверяться в карточке объекта, журнале операций, выгруженном отчёте или полученном уведомлении.
Шаг 6. Зафиксируйте входные данные и ожидаемые значения
Если результат зависит от расчёта, преобразования или проверки формата, добавьте контрольный пример. Он должен содержать входные данные, правило обработки и ожидаемый итог.
Пример критерия для расчёта:
- В заказе создана одна позиция с количеством 3 и ценой 500 рублей за единицу.
- Скидка, налог и стоимость доставки отсутствуют.
- После сохранения заказа значение поля «Итого» равно 1500 рублей.
- После повторного открытия заказа значение не изменяется.
Контрольный пример не заменяет общее правило. Если система должна обрабатывать разные значения, в ТЗ следует отдельно описать формулу, округление, валюту, обработку пустых значений и недопустимых данных.
Шаг 7. Добавьте негативные и граничные сценарии
Приёмка только по успешному сценарию не подтверждает обработку ошибок. Для значимых функций добавьте отдельные критерии для следующих ситуаций:
- обязательное поле не заполнено;
- введён недопустимый формат;
- пользователь не имеет нужных прав;
- объект уже удалён или изменён;
- передан пустой набор данных;
- значение находится на допустимой границе;
- значение превышает согласованный предел;
- повторно отправлен тот же запрос;
- недоступна зависимая система.
Пример:
«Если пользователь без права удаления открывает карточку договора, кнопка “Удалить” не отображается. Прямая попытка выполнить операцию через предусмотренный интерфейс обмена отклоняется. Договор остаётся доступным, его статус и содержимое не изменяются».
Не задавайте ожидаемый текст системной ошибки, если он ещё не согласован. В таком случае укажите необходимый смысл сообщения и зафиксируйте текст как отдельный элемент согласования.
Шаг 8. Определите доказательство выполнения
В критерии или в общем разделе приёмки укажите, чем подтверждается результат. Возможные доказательства зависят от предмета ТЗ:
- запись в протоколе приёмочных испытаний;
- скриншот экрана с видимыми данными;
- сформированный файл;
- запись в журнале событий;
- полученное письмо или уведомление;
- результат выполнения согласованного тестового сценария;
- подписанный акт проверки документа или оборудования.
Скриншот не всегда достаточен. Он подтверждает внешний вид в конкретный момент, но не доказывает сохранение данных, корректность расчёта или работу разграничения доступа. Для таких случаев нужны дополнительные действия проверки.
Шаг 9. Свяжите критерии с требованиями
Присвойте требованиям и критериям уникальные идентификаторы. Это упрощает согласование, тестирование и оформление замечаний.
| ID требования | Требование | ID критерия | Критерий приёмки |
|---|---|---|---|
| FR-12 | Редактор может отправить документ на согласование. | AC-12.1 | Документ в статусе «Черновик» переводится в статус «На согласовании» после подтверждения действия. |
| FR-12 | Редактор может отправить документ на согласование. | AC-12.2 | После отправки редактирование содержимого недоступно редактору. |
| FR-12 | Редактор может отправить документ на согласование. | AC-12.3 | В журнале событий фиксируются документ, действие, дата, время и пользователь. |
Один критерий должен проверять ограниченное число связанных результатов. Если в нём одновременно описаны интерфейс, расчёт, уведомление, права доступа и журналирование, его лучше разделить.
Шаг 10. Установите правила принятия решения
В ТЗ должен быть отдельный раздел, который отвечает на вопросы:
- кто проводит проверку;
- на какой среде выполняется приёмка;
- какие данные используются;
- как оформляется результат;
- что считается замечанием;
- какие отклонения блокируют приёмку;
- как проводится повторная проверка после исправления;
- может ли этап быть принят частично.
Пример формулировки:
«Критерий считается выполненным, если фактический результат совпадает с ожидаемым результатом во всех перечисленных шагах. Невыполненный шаг фиксируется в протоколе с идентификатором критерия, описанием фактического результата и приложенными доказательствами. После исправления повторно проверяется исходный критерий и связанные с ним сценарии».
Не используйте фразу «работы принимаются при отсутствии замечаний» без классификации замечаний. Незначительное отличие подписи кнопки и потеря данных имеют разное влияние на возможность эксплуатации.
Готовый шаблон критерия приёмки
| Поле | Что указать |
|---|---|
| ID | Уникальный номер критерия. |
| Связанное требование | ID требования или раздел ТЗ. |
| Цель проверки | Какой результат подтверждается. |
| Предусловия | Роль, состояние системы, настройки и подготовленные данные. |
| Тестовые данные | Конкретные допустимые и недопустимые значения. |
| Действия | Последовательность шагов проверяющего. |
| Ожидаемый результат | Наблюдаемое состояние после каждого значимого шага. |
| Доказательство | Протокол, файл, запись журнала, уведомление или иной подтверждающий материал. |
| Статус | Выполнен, не выполнен или заблокирован с указанием причины. |
Пример заполненного критерия
ID: AC-24.2.
Связанное требование: FR-24 «Экспорт списка заявок».
Предусловия: пользователь авторизован с правом просмотра заявок; в списке есть записи за выбранный период.
Тестовые данные: период задаётся двумя согласованными датами; в контрольном наборе заранее известны номера заявок, входящих в период.
Действия: пользователь задаёт период, применяет фильтр и запускает экспорт.
Ожидаемый результат: система формирует файл предусмотренного формата; файл открывается штатным средством просмотра; в нём присутствуют только заявки из отфильтрованного списка; состав и порядок столбцов соответствуют приложению к ТЗ.
Доказательство: экспортированный файл и запись результата в протоколе приёмки.
Типичные ошибки формулировок
- Скрытое сравнение: «новая версия работает не хуже старой» без перечня сравниваемых функций и показателей.
- Неопределённый субъект: «пользователь получает доступ» без указания роли и условий предоставления доступа.
- Неизвестный объект: «данные сохраняются» без перечисления полей и места хранения результата.
- Составное требование: один критерий проверяет несколько независимых функций.
- Отсутствие отрицательного результата: описан только успешный ввод, но не указано поведение при ошибке.
- Ссылка на устное согласование: ожидаемое поведение отсутствует в ТЗ и приложениях.
- Проверка реализации вместо результата: критерий требует конкретного внутреннего способа разработки, хотя для приёмки важен наблюдаемый результат.
- Непроверяемая абсолютность: «система никогда не теряет данные» без условий, границ и процедуры проверки.
Итоговый чек-лист
- У каждого критерия есть уникальный идентификатор и ссылка на требование.
- Указаны точные предусловия, роль пользователя и исходное состояние.
- Действия описаны в воспроизводимой последовательности.
- Ожидаемый результат можно наблюдать или подтвердить документом.
- Оценочные слова заменены измеримыми признаками.
- Числовые пределы не придуманы, а согласованы или вынесены в открытые вопросы.
- Для расчётов приведены контрольные входные данные и ожидаемые значения.
- Добавлены негативные и граничные сценарии.
- Определено, где и чем фиксируется результат проверки.
- Установлено, кто принимает работу и как оформляются отклонения.
- Каждый критерий даёт однозначный ответ: выполнен, не выполнен или заблокирован по указанной причине.