Acceptance criteria: что писать и как проверять

Зачем нужны acceptance criteria

Acceptance criteria (AC) — условия, при которых задача считается выполненной. Без них работа отдаётся в духе «вроде готово», а тест проходит в духе «вроде работает». Это не работа, это лотерея.

С AC появляется чёткая граница: если все условия выполнены — готово, если нет — нет. Тестировщик не выдумывает сценарии из головы, разработчик не доделывает фичу неделю в своей трактовке, продакт не получает «не то, что просил».

AC пишут до того, как разработчик берёт задачу. Не после. Если AC пишутся постфактум — это уже не AC, это инструкция уборщице.

Цена плохих AC обычно проявляется на двух этапах. Первое — при разработке: разработчик трактует задачу по-своему, и через 3 дня вы получаете не то, что обсуждали. Второе — при QA: тестировщик не знает, что проверять, и пропускает баги в прод. Хорошо написанные AC закрывают оба риска и экономят дни на каждой задаче.

Формат Given-When-Then

Самый строгий формат, пришёл из BDD.

Given [исходное состояние]
When  [действие пользователя]
Then  [ожидаемый результат]

Пример для фичи «вход через Telegram»:

Given пользователь не залогинен и видит экран входа
When  он нажимает на кнопку «Войти через Telegram»
Then  открывается окно подтверждения Telegram
And   после подтверждения пользователь возвращается в приложение залогиненным

Given пользователь залогинен через Telegram
When  он переходит в профиль
Then  отображается ник из Telegram и аватарка

Плюс формата: каждый сценарий — отдельный тест-кейс. Минус: для простых задач — оверкилл.

Используй G-W-T для:

• Сценариев с условиями (если X, то Y; если Z, то W).
• Многошаговых пользовательских флоу.
• Фич с пограничными случаями.

Хорошее правило: если на одну задачу выходит больше 6–8 G-W-T-блоков, задачу стоит разбить. Большая простыня сценариев плохо читается и плохо тестируется.

Формат checklist

Простой список условий. Подходит, когда сценариев немного и они линейные.

Пример для «карточка стрика в профиле»:

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

Главное — каждое условие проверяемо отдельно: «да или нет». Если не проверяется — переписывай.

Хорошее правило для checklist — формулировать условия в третьем лице и в результате, а не в действии. Плохо: «реализовать обновление чисел». Хорошо: «числа обновляются в течение 60 секунд после события». Первая формулировка — про процесс разработки, вторая — про проверяемое поведение продукта.

AC vs Definition of Done

Часто путают.

Acceptance criteria — условия для конкретной задачи. Меняются от задачи к задаче.

Definition of Done (DoD) — общие условия, при которых любая задача в команде считается готовой. Зафиксированы один раз для всей команды.

Типичный DoD:

• Код прошёл код-ревью.
• Покрыт тестами.
• Прошёл QA.
• Документация обновлена.
• Аналитика логирует события.
• Релиз-нот написан.

Когда команда говорит «фича готова», она имеет в виду: AC + DoD. Без любого — не готово.

Что	AC	DoD
Уровень	Задача	Команда
Меняется	Каждую задачу	Раз в полгода
Кто пишет	Продакт + команда	Команда совместно
Пример	«При клике появляется модалка»	«Код прошёл ревью»

Примеры по типам задач

Новая фича. Сценарии и edge-cases.

- Пользователь видит кнопку Х на экране Y
- При клике открывается модалка Z
- В модалке три обязательных поля
- При попытке отправить пустую форму показывается валидация
- При успешной отправке появляется тост «Сохранено»
- Аналитика: событие feature_x_submit логируется с параметром source

Исправление бага. Условие, при котором баг считается закрытым.

- На iOS Safari при клике на «Купить» переход на оплату работает
- Воспроизводимость в Chrome/Firefox/Safari подтверждена QA
- Регресс-тест добавлен в автотесты

Технический рефакторинг. Не функциональные требования, а нефункциональные.

- Все вызовы старого API мигрированы на новый
- Старый API удалён из кода
- Тесты проходят
- Время загрузки страницы X не выросло (бенчмарк до/после)

Аналитическая задача. Метрики и дашборд.

- В дашборде Y добавлен график «Конверсия в платёж по неделям»
- Данные обновляются раз в сутки
- Сегментация: новые/старые, мобильные/десктоп
- Описание метрики и формула расчёта добавлены в Notion

Платёжный флоу. Здесь AC обязательно подробные.

- При успешной оплате пользователь видит экран «Оплата прошла»
- На email приходит чек в течение 5 минут
- При двойном нажатии на «Оплатить» списание происходит один раз
- При ошибке сети показывается сообщение и предлагается повторить
- При тайм-ауте оплаты статус заказа переводится в «ожидает», пользователь получает уведомление
- В случае возврата средств статус подписки обновляется в течение 1 часа

Когда AC писать особенно тщательно

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

• Платёжные сценарии. Любая ошибка в деньгах стоит дорого. Прописывай все edge-cases: двойной клик, ошибка сети, тайм-аут.
• Доступы и права. Кто что видит, кто что меняет — каждая роль отдельно.
• Уведомления. Кому, в каких условиях, как часто, как отписаться.
• Юридические сценарии. Согласия, удаление данных, экспорт.

В этих случаях AC становится спецификацией — нормально, что разрастается до страницы.

Дополнительно — AC по аналитике. Если в задаче не прописано, какое событие логировать, с какими параметрами и куда — после релиза вы не сможете оценить эффект. Хороший AC по аналитике называет имя события, обязательные параметры, точку триггера в коде, систему назначения (PostHog, Amplitude, внутренний DWH). Без этого продакт через месяц обнаруживает, что фича выкачена, а данных нет.

Чек-лист хорошего AC

Перед тем как отдать задачу в работу, прогоняем по списку:

• Условия проверяемы отдельно — на каждое можно ответить «да или нет».
• Покрыты positive и negative сценарии (не только «как должно работать», но и «что если ввели неправильно»).
• Указаны граничные случаи (пустая форма, ошибка сети, медленный интернет, мобильное и десктоп).
• Прописаны требования к аналитике (события, параметры, дашборд).
• Указаны требования к доступам и правам, если они разные для ролей.
• Нет реализационных деталей («использовать React Query») — только поведение продукта.
• Размер задачи адекватен (3–8 AC обычно нормально, 15+ — пора разбивать).
• Команда подтвердила, что AC понятны, на груминге не осталось вопросов.

Частые ошибки

• AC формальные. «Фича работает» — не AC.
• AC после разработки. Уже поздно, разработчик сделал по своему пониманию.
• Смешение AC и DoD. AC — про задачу, DoD — про команду.
• Нет negative-сценариев. Что если поле пустое, что если сеть отвалилась — это тоже AC.
• AC = техническое задание. AC — про результат, не про реализацию. «Использовать React Query для запросов» — не AC.
• AC длиной в простыню. Если 20 условий — задача слишком большая, разбивай.
• Игнор аналитики в AC. «Логировать событие X» должно быть в AC, иначе про события забудут.
• AC, которые меняются молча. Любое изменение фиксируется в задаче, иначе на ретро будет «но мы же договаривались».

Связанные темы

• Как писать user story
• Как вести беклог продукта
• Как оценить эффект фичи
• Как запустить эксперимент с нуля

FAQ

Кто пишет AC — продакт или команда?

Первый драфт — продакт. На груминге команда дополняет техническими условиями. Финальная версия — совместная.

Сколько AC должно быть на одну задачу?

Обычно 3–8. Меньше — недоопределили. Больше — задача слишком большая.

Можно ли использовать оба формата сразу?

Да. Основные сценарии в Given-When-Then, нефункциональные условия в checklist под ними.

Что если AC изменились в процессе?

Фиксируешь изменение в задаче и обсуждаешь с командой. Молчаливое изменение AC — основная причина «но мы же договаривались».

Нужны ли AC для багов?

Да. Минимум — условие «баг не воспроизводится» и регресс-тест добавлен.

Что делать, если разработка не читает AC?

Это вопрос процесса. Пройдитесь по AC на груминге вслух, попросите команду подтвердить. Если AC игнорируются регулярно — это сигнал, что задачи заходят в спринт без груминга.

Где хранить AC — в задаче или в отдельной спеке?

В задаче. Если AC живут в отдельном документе, они теряются. Большие фичи — отдельный PRD, но даже тогда в задаче пишутся ссылки и краткие AC.

Должны ли AC быть на английском?

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

---

Тренируйте продуктовые кейсы — откройте Карьерник с 2500+ вопросами для собеса.