Команда три недели разрабатывает функцию поиска по категориям. Владелец продукта ожидает удобный интерфейс с кликабельными ссылками на категории. Разработчики создают строку поиска, где нужно вручную вводить категорию. Обе стороны считают, что сделали правильно — но результат не совпадает с ожиданиями.
Разберёмся, как критерии приёмки помогают договориться на берегу — и почему без них команда рискует потратить недели на функцию, которая никому не нужна.
Что такое критерии приёмки
Критерии приёмки (Acceptance Criteria) — это список конкретных условий, которым должна соответствовать пользовательская история, чтобы её считали выполненной. Это проверяемые утверждения, которые описывают результат, а не процесс реализации.
По сути, это ответ на вопрос: «Как мы поймём, что задача решена правильно?» Команда и владелец продукта заранее фиксируют договорённости — что именно должно работать и как.
Важно не путать критерии приёмки с пользовательскими историями. User Story описывает потребность пользователя и контекст («зачем нужна функция»), а Acceptance Criteria — конкретные требования к функционалу («что именно должно работать»).
Например, для истории «Как клиент, я хочу искать товары по категориям, чтобы быстро находить нужное» критериями будут:
- категории отображаются списком на главной странице;
- клик по категории показывает товары этой категории;
- пустые категории не отображаются.
Зачем нужны критерии приёмки
Помочь всем понять задачу одинаково. Разработчик, тестировщик и владелец продукта часто видят одну и ту же историю по-разному. Критерии фиксируют, о чём договорились, — и снимают разночтения до начала работы.
Дать основу для тестирования. Каждый критерий — это готовый тест-кейс. QA-инженер точно знает, что проверять, а команда понимает, когда функцию можно считать готовой.
Помочь точнее оценить сроки. Когда понятно, что именно нужно сделать, разработчик может дать реалистичную оценку. Без критериев команда часто недооценивает задачу — или обнаруживает скрытые требования уже в процессе.
Задать границы задачи. Команда понимает, где остановиться, и не добавляет лишний функционал, который изначально не обсуждали.
Напомнить про ошибки. Критерии описывают не только успешный сценарий, но и то, как система должна реагировать на проблемы: неверный ввод, отсутствие данных, сбой сети.
Характеристики хороших критериев приёмки
Чтобы критерии работали, они должны быть:
Ясные и лаконичные. Формулировка понятна всем без дополнительных пояснений — без жаргона и двусмысленностей.
Проверяемые. Каждый критерий можно превратить в тест. Если проверить объективно нельзя — значит, сформулировано плохо.
Хочешь разобраться, что тебе даст Продуктовый подход?
Выбери, что ближе твоему запросу — и получи 🎁 подарок
Например, формулировка «Интерфейс должен быть удобным» — непроверяемая. А «Пользователь может найти нужный товар за 3 клика» — проверяемая.
С фокусом на результате. Описывайте, что должен делать функционал, а не как его реализовать. Так разработчики сами выберут оптимальное решение.
Например, лучше написать «Система отправляет email-уведомление» вместо «Система использует SMTP-сервер для отправки писем».
Измеримые. Используйте конкретные параметры: числа, размеры, форматы, временные рамки. Это убирает субъективность в оценке.
Независимые. Каждый критерий проверяется отдельно. Это ускоряет поиск проблем и позволяет тестировать функционал по частям.
Примеры критериев приёмки
Рассмотрим, как правильно формулировать критерии для разных пользовательских историй.
Поиск товаров
User Story: «Как покупатель, я хочу искать товары по названию, чтобы быстро находить нужное».
Критерии приёмки:
- поле поиска расположено в шапке сайта на всех страницах;
- поиск запускается при нажатии Enter или клике на кнопку «Найти»;
- система ищет совпадения в названиях товаров (минимум 2 символа);
- результаты отображаются списком с фото, названием и ценой;
- если совпадений нет, показывается сообщение «Ничего не найдено»;
- поиск игнорирует регистр букв.
Редактирование профиля
User Story: «Как зарегистрированный пользователь, я хочу редактировать данные своего аккаунта, чтобы профиль оставался актуальным».
Критерии приёмки:
- пользователь может изменить: имя, email, телефон, фото профиля;
- изменения сохраняются только после нажатия кнопки «Сохранить»;
- при попытке ввести уже занятый email показывается ошибка;
- после сохранения появляется уведомление «Данные обновлены»;
- кнопка «Отменить» возвращает исходные значения полей.
Генерация отчёта
User Story: «Как администратор, я хочу генерировать отчёты о действиях пользователей, чтобы отслеживать активность».
Критерии приёмки:
- администратор может выбрать период: день, неделя, месяц или произвольный диапазон;
- отчёт формируется не дольше 10 секунд для данных за месяц;
- отчёт экспортируется в форматах CSV и PDF;
- в отчёте отображаются: дата, действие, пользователь, IP-адрес;
- при отсутствии данных за период показывается сообщение «Нет активности».
Форматы описания критериев приёмки
Есть два основных подхода к оформлению критериев.
Свод правил (Rule-Oriented)
Простой список требований, которым должна соответствовать функция. Подходит для несложных историй с чёткими условиями:
- условие 1;
- условие 2;
- условие 3.
Этот формат работает хорошо, когда команда слаженная и всем достаточно перечня правил. Список может включать требования к функциональности, производительности, безопасности.
Сценарно-ориентированный (Scenario-Oriented)
Описание поведения системы через сценарии использования. Часто применяется формат Given-When-Then (Дано-Когда-Тогда):
- Given (Дано) — начальное состояние;
- When (Когда) — действие пользователя;
- Then (Тогда) — ожидаемый результат.
Например, для функции входа в систему:
Сценарий: Успешный вход
- Given: Пользователь зарегистрирован и находится на странице входа.
- When: Вводит корректный email и пароль, нажимает «Войти».
- Then: Система перенаправляет на главную страницу и показывает имя пользователя.
Сценарий: Неверный пароль
- Given: Пользователь находится на странице входа.
- When: Вводит корректный email, но неверный пароль.
- Then: Система показывает ошибку «Неверный пароль» и не пускает в систему.
Этот формат удобен для описания сложного поведения и часто используется в автоматизированном тестировании (BDD — Behaviour-Driven Development).
Как писать критерии приёмки: пошаговая инструкция
Процесс создания качественных критериев состоит из нескольких этапов.
Шаг 1. Связать с пользовательской историей
Каждый набор критериев относится к конкретной User Story. Перед написанием убедитесь, что история сформулирована чётко и понятна всем участникам.
Шаг 2. Задать правильные вопросы
Обсудите с командой и владельцем продукта:
- Что должно произойти в успешном сценарии?
- Что может пойти не так?
- Какие граничные случаи нужно учесть?
- Какие данные используются?
- Есть ли требования к производительности или безопасности?
Шаг 3. Описать позитивные и негативные сценарии
Критерии должны покрывать как успешное выполнение действий, так и обработку ошибок. Команды часто забывают про негативные сценарии — и пользователи сталкиваются с непонятными сбоями.
Шаг 4. Использовать конкретные параметры
Вместо «быстро» напишите «не дольше 3 секунд». Вместо «удобно» — «за 2 клика». Измеримость делает критерии объективными.
Шаг 5. Проверить на независимость
Убедитесь, что каждый критерий можно тестировать отдельно. Если для проверки одного критерия нужно сначала выполнить другой — возможно, их стоит объединить или переформулировать.
Шаг 6. Согласовать с командой
Критерии приёмки — результат командной работы. Владелец продукта, разработчики и тестировщики должны прийти к единому пониманию до начала работы.
Кто пишет критерии приёмки
Создание критериев — командная ответственность, но роли распределяются по-разному.
Владелец продукта обычно инициирует составление критериев, потому что именно он понимает бизнес-ценность и ожидания пользователей. Он определяет, что должно быть сделано.
Аналитик часто берёт на себя фиксацию критериев в формализованном виде, задаёт уточняющие вопросы и следит за полнотой описания.
Разработчики дополняют критерии техническими деталями, обращают внимание на граничные случаи и оценивают реализуемость требований.
Тестировщики проверяют, можно ли на основе критериев создать тест-кейсы, и добавляют негативные сценарии.
На практике критерии часто дорабатываются на груминг-сессиях (Product Backlog Refinement) — регулярных встречах команды для обсуждения и уточнения задач из бэклога.
Типичные ошибки при составлении критериев приёмки
Даже опытные команды допускают ошибки, которые снижают эффективность критериев.
Слишком общие формулировки. «Система должна работать быстро» или «Интерфейс должен быть удобным» — это не критерии, а пожелания. Проверить их невозможно. Формулируйте конкретно: «Страница загружается не дольше 2 секунд» или «Пользователь находит нужную функцию за 3 клика».
Описание технической реализации. Критерии отвечают на вопрос «что», а не «как». Фраза «Использовать Redis для кеширования» — это уже решение разработчика, а не требование к результату. Правильная формулировка: «Повторный запрос данных выполняется быстрее первого».
Зависимые критерии. Когда для проверки одного критерия нужно сначала выполнить другой, тестирование усложняется. Старайтесь делать критерии независимыми или явно указывайте зависимости.
Забытые негативные сценарии. Система должна корректно обрабатывать ошибки: неверный ввод, отсутствие интернета, недостаточные права доступа. Если об этом не написать в критериях — разработчик может просто не учесть эти случаи.
Что в итоге
Критерии приёмки связывают ожидания заказчика с тем, что делает команда. Они помогают договориться заранее, дают основу для тестирования и снижают риск переделок.
Хорошие критерии — ясные, проверяемые, измеримые и независимые. Они описывают результат, а не процесс, и покрывают как позитивные, так и негативные сценарии.
Создание критериев — командная работа: владелец продукта определяет, что нужно, разработчики оценивают, как это сделать, а тестировщики проверяют, можно ли это протестировать. Совместное обсуждение до начала разработки экономит время и сокращает количество переделок.
Внедрить практику создания качественных критериев приёмки непросто — нужно учитывать опыт команды, особенности проектов и корпоративную культуру. Компания Neogenda помогает командам внедрять Agile-практики и обучает владельцев продуктов работе с требованиями. Среди клиентов — Сбер, Ростелеком, банки и IT-компании.
Начните трансформацию с бесплатной консультации от практиков Neogenda — это первый шаг к тому, чтобы создавать продукты, которые решают реальные задачи пользователей.
