Критерии приемки задачи: как описать проверяемый результат

#COURSE##INNER#

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

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

Чем критерий приемки отличается от описания задачи

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

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

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

Как перейти от пожелания к проверяемым условиям

Сначала назовите пользователя, его действие и полезный результат. Затем уточните исходное состояние: авторизован ли пользователь, какие данные у него есть, какие поля обязательны. После этого опишите успешный исход и те исключения, которые действительно входят в задачу.

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

Удобно пользоваться формой «при таком исходном состоянии, когда происходит действие, ожидается такой результат». Она помогает обнаружить пропуски, но не является обязательным шаблоном. Для простой задачи подойдет короткий список условий. Важнее, чтобы участники одинаково понимали каждое из них.

Учебный пример: заявка на консультацию по курсу

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

Ситуация	Критерий приемки	Как проверить
Обязательные данные заполнены по согласованным правилам	После успешной отправки создано обращение с выбранным курсом; посетителю показано подтверждение	Отправить учебную заявку и сопоставить данные формы и обращения
Имя не заполнено	Заявка не отправляется; рядом с полем объяснено, что нужно указать имя	Оставить поле пустым и проверить сообщение и отсутствие обращения
Телефон не соответствует согласованному формату	Заявка не отправляется; пользователь видит сообщение об ошибке телефона	Подставить примеры из согласованного списка допустимых и недопустимых значений
Сервер вернул ошибку сохранения	Сообщение об успешной отправке не показывается; введенные данные остаются доступны для повторной попытки	В учебной среде воспроизвести ошибку и проверить состояние формы

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

Как согласовать критерии и не превратить их в бесконечный список

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

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

Еще одна частая ошибка — подмена результата способом реализации. Название библиотеки само по себе не объясняет, что сможет сделать пользователь. Техническое ограничение можно зафиксировать отдельно, если оно действительно обязательно; критерий приемки при этом должен оставаться понятным как условие проверки результата.

Как закрепить навык на практике

Возьмите небольшую функцию — поиск по каталогу, запись на встречу или загрузку файла. Сформулируйте потребность, напишите проверяемые условия и попросите другого человека составить по ним проверки. Если ему приходится угадывать результат, вернитесь к формулировке. Хорошая учебная работа заканчивается согласованным набором условий и примеров, а не только списком терминов.

Для дальнейшего обучения можно рассмотреть программу Школы прикладного бизнес-анализа «От процессов к продуктам: Product Ownership и Agile-практики для бизнес-аналитика»: в доступном описании программы указаны критерии приемки и работа с пользовательскими историями. Эта тема также названа в программе IBS «Основы методологии Agile для разработки ПО». Перед записью уточните, предусмотрены ли самостоятельные задания и разбор ваших формулировок.