Как писать критерии приёмки в Jira: практические примеры

«Клиенты могут менять настройки уведомлений» звучит ясно до начала разработки. Сохраняется ли изменение сразу? Что при ошибке? Останется ли выбор завтра? Какие письма затронуты?

Критерии превращают открытые вопросы в согласованные наблюдаемые результаты. Заказывающие, создающие и проверяющие изменение получают общие ожидания.

Мы разработаем критерии вымышленного портала, улучшим размытые требования и добавим список в Definition of Done & AC. Специальный формат не нужен: достаточно ясных условий и результатов.

Что такое критерии приёмки?

Это условия принятия конкретной работы, сосредоточенные на её ожидаемом результате. Atlassian отличает их от Definition of Done — общего стандарта качества завершённой работы. См. руководство Atlassian.

В примере «Сохранённый выбор остаётся после нового входа» — критерий приёмки. «Реализация проверена» относится к общей Definition of Done.

Различие делает списки полезными. Критерии объясняют, выполняет ли функция договорённость; Definition of Done — соответствует ли работа общему стандарту команды.

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

Начните с одного клиентского результата

Вымышленная задача называется «Дать клиентам управление еженедельной сводкой». Цель — позволить вошедшему клиенту выбирать её получение, не меняя важные сообщения аккаунта.

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

Эти детали придуманы для примера. Определите реальное поведение самостоятельно, не копируя их как требования продукта.

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

Теперь критерии могут сосредоточиться на подтверждающих эту функцию результатах.

Сначала опишите обычный путь

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

Например: «Если вошедший клиент отключает сводки и успешно сохраняет, повторное открытие настроек показывает их отключёнными». Проверяющий создаёт состояние, действует и смотрит результат.

Это полезнее «Настройки сохраняются правильно». Фраза уточняет параметр, момент применения и способ проверки.

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

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

Добавьте ошибки и границы

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

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

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

Избегайте «Все крайние случаи учтены». Назовите важные случаи: что может сломаться, что должно остаться неизменным и что произойдёт позже?

Если ожидаемый итог не согласован, зафиксируйте открытое решение до далёкого продвижения реализации. Безответный вопрос не становится полезным критерием от размещения в списке.

Подробный пример списка критериев

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

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

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

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

Уточните размытые критерии перед добавлением

Короткая проверка текста предотвращает поздние споры. Спросите, могут ли два человека по-разному понять успех каждого пункта.

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

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

Занесите критерии в Power Pack

Откройте карточку Definition of Done & AC в задаче. Выберите Acceptance Criteria. Список отделён от Definition of Done, поэтому проверьте вкладку перед вводом.

Введите название и нажмите Add или Enter. Сохраняйте краткость без потери ожидаемого итога. Обширный контекст размещайте в описании Jira или связанной документации.

Для нескольких пунктов выберите Bulk Import и вставьте Markdown-список. Скопируйте примеры, поставив дефис и пробел перед каждым. Markdown-флажки также поддерживаются.

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

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

Проверяйте результат перед отметкой

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

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

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

Power Pack отслеживает список, не запускает тесты и не определяет проверяющего автоматически. Именную или датированную проверку фиксируйте явно своим процессом.

Используйте счётчики, не принимая их за доказательства

Каждая вкладка показывает завершённое и общее количество. Ready for Release требует непустых обоих списков и завершения всех пунктов. Иначе отображается In Verification.

Это сводка введённого состояния. Она не устанавливает полноту поведения или достоверность доказательств, не принуждает переходы Jira и не блокирует слияния.

Все восемь критериев уведомлений могут быть завершены, а инструкция поддержки — ещё нет в Definition of Done. Функциональные результаты прошли, но общее соглашение содержит открытый пункт.

Начните с ближайшей задачи. Запишите клиентский итог, согласуйте условия и результаты, добавьте критерии рядом с Definition of Done в Power Pack. Проверьте список с разработкой и тестированием. Выгода — меньше предположений за поначалу очевидной фразой.

• Atlassian — Что такое критерии приёмки?